Package Details: julia-git 0.6.0.dev.r33116.ge4b5233-1

Git Clone URL: https://aur.archlinux.org/julia-git.git (read-only)
Package Base: julia-git
Description: High-level, high-performance, dynamic programming language
Upstream URL: http://julialang.org
Licenses: MIT
Conflicts: julia
Provides: julia
Submitter: mihi
Maintainer: TrialnError
Last Packager: TrialnError
Votes: 50
Popularity: 0.013012
First Submitted: 2012-02-22 08:57
Last Updated: 2016-08-13 19:28

Latest Comments

Deathaluz commented on 2016-08-10 23:17

I was able to install the package after installing several missing packages, which were causing building errors.
I actually used the sugestion given by the wiki: makepkg -sri

TrialnError commented on 2016-08-10 08:14

And again, 2015 pcre2 got included in the deps line.
How did you get/update the PKGBUILD?
What was the _exact_ command you used to build the package with makepkg? (at least -s would be needed)

Deathaluz commented on 2016-08-10 03:57

Tried to intall the package with plain makepkg as sugested, but got the exact same error as @haawda:

make[1]: pcre2-config: Command not found
make[1]: *** No rule to make target '/include/pcre2.h', needed by 'pcre_h.jl'. Stop.

TrialnError commented on 2016-06-26 17:42

Built yesterday from master and it worked. So maybe temporary issues upstream.
pcre2 was added as a dep 2015-06-03 and it's using the same Make flag (USE_SYSTEM_PCRE)

haawda commented on 2016-06-24 20:28

==> Starting build()...
make: Entering directory '/home/haawda/paketierung/not_maintained_by_me/julia-git/src/julia'
make[1]: Entering directory '/home/haawda/paketierung/not_maintained_by_me/julia-git/src/julia/deps'
make[1]: Leaving directory '/home/haawda/paketierung/not_maintained_by_me/julia-git/src/julia/deps'
make[1]: Entering directory '/home/haawda/paketierung/not_maintained_by_me/julia-git/src/julia/src'
make[1]: Entering directory '/home/haawda/paketierung/not_maintained_by_me/julia-git/src/julia/src'
make[1]: Entering directory '/home/haawda/paketierung/not_maintained_by_me/julia-git/src/julia/base'
make[1]: pcre2-config: Command not found
make[1]: *** No rule to make target '/include/pcre2.h', needed by 'pcre_h.jl'. Stop.
make[1]: Leaving directory '/home/haawda/paketierung/not_maintained_by_me/julia-git/src/julia/base'
make: *** [Makefile:84: julia-base] Error 2
make: *** Waiting for unfinished jobs....
make[1]: Leaving directory '/home/haawda/paketierung/not_maintained_by_me/julia-git/src/julia/src'
make[1]: Leaving directory '/home/haawda/paketierung/not_maintained_by_me/julia-git/src/julia/src'
make: Leaving directory '/home/haawda/paketierung/not_maintained_by_me/julia-git/src/julia'
==> ERROR: A failure occurred in build().

seems to need pcre2 (again?).

TrialnError commented on 2016-04-16 12:25

SideburnEtic: Cannot reproduce. Latest build (ref 30508) worked without any issue for me.

If using an AUR manager like yaourt please test before reporting if it also happens with plain makepkg.
If not, something is at fault with the helper.

Additionally, since this an git build, test if the build still fails after upstream committed some more stuff. Most of the time, if something is awry with the build process, it will be fixed relatively fast.

SideburnEtic commented on 2016-04-06 06:13

I'd like to report a missing make target error, which also happens when building julia-git.

make[1]: *** No rule to make target '/tmp/yaourt-tmp-USER/aur-julia-git-docs/repl.o', needed by '/tmp/yaourt-tmp-USER/aur-julia-git-docs/src/julia/usr/bin/julia'. Stop.

TrialnError commented on 2015-11-08 14:05

Building with makepkg works.
Please take a look into the build directory and look if the doc/_build directory exists.
If so check what happens if you change the cd path to $srcdir/_pkgbase/doc/_build

TrialnError commented on 2015-11-08 13:08

Noted. I will look at it. (And it worked for me on a fresh build (at least yesterday))

gabor_bernat commented on 2015-11-08 08:32

It's broken now:

‘examples/wordcount.jl’ -> ‘/tmp/bernat/yaourt-tmp-bernat/aur-julia-git-docs/pkg/julia-git-docs/usr/share/doc/julia/examples/wordcount.jl’
removed ‘/tmp/bernat/yaourt-tmp-bernat/aur-julia-git-docs/pkg/julia-git-docs/usr/share/doc/julia/man/julia.1’
removed directory: ‘/tmp/bernat/yaourt-tmp-bernat/aur-julia-git-docs/pkg/julia-git-docs/usr/share/doc/julia/man/’
/tmp/bernat/yaourt-tmp-bernat/aur-julia-git-docs/./PKGBUILD: line 102: cd: doc/_build: No such file or directory
==> ERROR: A failure occurred in package_julia-git-docs().
Aborting...
==> ERROR: Makepkg was unable to build julia-git.

TrialnError commented on 2015-09-20 20:08

@JuliaDoc: If not installed the build process will download it (and the remaining stuff like the sphinx themes).
I will include it in the commented makedepends with the texlive packages + additional changes (html pages are generated everytime).

TrialnError commented on 2015-09-20 19:36

Another possible problem to look at. I currently have the impression that stuff is compiled in build() and then again in package().
Did someone else notice it or have some more insight?

TrialnError commented on 2015-09-20 18:28

haawda: Yeah, I noticed it too, after removing the rev counter this problem occurs. But nonetheless this problem also occurs with the old rev counter. So I would like to find another solution. Maybe your proposed change will do that.

And thanks for the note about JuliaDoc. Will look at it. Doc part needs a overhaul since it was built by default in the makeprocess. And now an extra tool?

haawda commented on 2015-09-20 16:38

Creating the documentation needs juliadoc, I provided a PKGBUILD for that.

The pkgver function does not do a good job. The way you do it does not guarentee that newer commits generate higher pkgvers. I suggest the following:

pkgver() {
cd $_pkgbase

# use the version from VERSION file
ver=`git show makepkg:VERSION | sed 's/-/./g'`
# strip the last tag name from the HEAD description
printf "%s.r%s.g%s" $(echo $ver) "$(git rev-list --count HEAD)" "$(git rev-parse --short HEAD)"
}

TrialnError commented on 2015-06-03 17:54

@yuyichao:
Does it replace pcre (ver 8.x)?
Because the README.md still says pcre>=8.31, which looks like it still can be used?


Edit: Ok, looking at the PR it replaces. Will upload change soon

TrialnError commented on 2015-06-03 17:51

@yuyichao:
Does it replace pcre (ver 8.x)?
Because the README.md still says pcre>=8.31, which looks like it still can be used?

yuyichao commented on 2015-06-02 13:44

With LLVM 3.6.1, openblas-lapack-git and the julia git master (which has a recent fix for new suitsparse version) all the julia test suite should pass on ArchLinux.

yuyichao commented on 2015-06-02 13:39

@big_gie You need openblas to get the test pass.

yuyichao commented on 2015-06-02 13:39

Please update the dependency on pcre to pcre2 (in AUR). The version dependency is bumped ~yesterday.

TrialnError commented on 2015-05-28 01:50

I added the AUR packages openlibm and openspecfun to deps. Both projects from the JuliaLang Team (so no issue like with libuv) and deps that don't need to be compiled everytime you want to build julia from git

TrialnError commented on 2015-04-14 23:04

They check for system patchelf now.
Not sure if this could be an optdepend

big_gie commented on 2015-03-17 15:29

Anybody tried to run the included test suite? It fails here (both 0.3.6 and 0.4.0.dev.3863.g2a4fd44). It seems to be a problem with blas...

julia> Base.runtests()
exception on 4: ERROR: LoadError: ccall: could not find function cblas_cdotc_sub in library libblas
in dotc at ./linalg/blas.jl:121
in dotc at ./linalg/blas.jl:154
in Ac_mul_B at ./linalg/matmul.jl:63
in anonymous at ./no file:10
in runtests at /usr/share/julia/test/testdefs.jl:78
in anonymous at ./multi.jl:833
in run_work_thunk at ./multi.jl:584
in anonymous at ./multi.jl:833
while loading linalg3.jl, in expression starting on line 4
From worker 5: * linalg4 in 21.39 seconds
From worker 2: * linalg1 in 37.86 seconds
From worker 3: * linalg2 in 41.57 seconds
ERROR: LoadError: LoadError: ccall: could not find function cblas_cdotc_sub in library libblas
in anonymous at ./task.jl:1379
while loading linalg3.jl, in expression starting on line 4
while loading /usr/share/julia/test/runtests.jl, in expression starting on line 3

From worker 4: * linalg3 ERROR: A test has failed. Please submit a bug report (https://github.com/JuliaLang/julia/issues)
including error messages above and the output of versioninfo():
Julia Version 0.4.0-dev+3863
Commit 2a4fd44 (2015-03-17 14:45 UTC)
Platform Info:
System: Linux (x86_64-unknown-linux-gnu)
CPU: Intel(R) Core(TM) i7-4770 CPU @ 3.40GHz
WORD_SIZE: 64
BLAS: libblas
LAPACK: liblapack
LIBM: libm
LLVM: libLLVM-3.6.0

in error at ./error.jl:19
in runtests at ./interactiveutil.jl:399
in runtests at ./interactiveutil.jl:388

TrialnError commented on 2015-03-12 01:47

All right. Building with llvm<3.6 is working again and now I see why haawda mentioned python2-sphinx. They added the build of the docs to the make call

TrialnError commented on 2015-03-05 15:12

Current issue: https://github.com/JuliaLang/julia/issues/10376
Although there exists a PR it doesn't seem to be right solution to fix this.
So for now, I set a versioned dep for llvm until this is solved.

Currently it only builds with llvm 3.6 which isn't in the repos yet, but if someone wants to update he can do that

TrialnError commented on 2015-03-03 19:06

@myles: Thanks for the notes.
Normally the first warning indicates there was a remaining src directory. Or something that makepkg interpreted as such (since it failed). Shouldn't be a problem with the PKGBuild
The second thing.. Well. I need to check that once julia builds again. Currently compiling is failing.
What do you use for making packages from the AUR? An AUR wrapper like yaourt, simple makepkg?

@haawda: If you want to generate the docs via the PKGBuild, yes. Else not, as far as I'm aware. See the commented makedepends line.
Or did I miss something?

haawda commented on 2015-02-22 13:24

python2-sphinx is needed as build-dependency.

myles commented on 2015-02-18 13:06

Thanks for maintaining this package. I encountered two problems:
The first was:

==> WARNING: Using existing $srcdir/ tree
==> Starting build()...
make: *** julia: No such file or directory. Stop.
==> ERROR: A failure occurred in build().
Aborting...

May be there was an existing source tree, I don't remember trying to install it before. Re-trying worked around the issue and everything went fine until right at the end:

error: 'MYBUILDDIR/src/julia-git/julia-git-docs-0.4.0.dev.3400.g01a2fc8-1-x86_64.pkg.tar.xz': could not find or read package

Because the package is named according to the arch=('any') on line 114:

$ ls MYBUILDDIR/src/julia-git/julia-git-docs*
MYBUILDDIR/src/julia-git/julia-git-docs-0.4.0.dev.3400.g01a2fc8-1-any.pkg.tar.xz
MYBUILDDIR/src/julia-git/julia-git-docs-0.4.0.dev.3400.g01a2fc8-1-any.pkg.tar.xz.sig

TrialnError commented on 2015-02-02 12:09

Took a look at blas, lapack and suitespars PKGBuilds.
Blas didn't changes if I see it correctly, but USE_SUITESPARS can be set to 1 again. The repo package builds .so files and not .a files anymore, so julia build process shouldn't complain about that

TrialnError commented on 2015-02-02 11:56

@Snow: Back in 2013 there was a problem if this option wasn't set. Maybe this has changed in the meantime so it could be removed.

If you want to read about why it was introduced look at the comments on this page from 2013-06-29 to 2013-07-04

Edit: In short. blas from extra wasn't built with INTERFACE64=1

TrialnError commented on 2015-02-02 11:53

@Snow: Back in 2013 there was a problem if this option wasn't set. Maybe this has changed in the meantime so it could be removed.

If you want to read about why it was introduced look at the comments on this page from 2013-06-29 to 2013-07-04

Snow commented on 2015-01-31 03:13

I feel confused about a make flag. Why USE_BLAS64 is set to 0?
If the arch is x86_64, the BLAS on the system is also x86_64.
Setting it to BLAS64 might cause conflict in matrix computation, I guess.

TrialnError commented on 2014-12-23 11:12

Thanks for the solution alyst. I will include it. It was really misleading.

alyst commented on 2014-12-17 09:09

The version of the package is a bit misleading, as currently it is actually julia 0.4 development. I've modified the version extraction so that it takes the version from the HEAD's VERSION file (they seem to keep it up-to-date, for the stable releases and RCs as well). Here's the snippet:

pkgver() {
cd $_pkgbase

# use the version from VERSION file
ver=`git show master:VERSION | sed 's/-/./g'`
# strip the last tag name from the HEAD description
rev=`git describe --tags | sed 's/^.\+-\([0-9]\+-g[0-9a-f]\+\)$/\1/;s/-/./g'`
echo $ver.$rev
}

TrialnError commented on 2014-11-21 22:46

PKGBuild update incoming.
They include libgit2, which requires some changes

Using libgit2 from the repo will add libgit2 to deps.
Building it with julia will require cmake in makedeps.

Initially I will add the cmake dep until I can confirm (or someone else) that it works with libgit2 from repo (hopefully, since this step will lower compilation time)

sivapvarma commented on 2014-11-12 16:15

I want to get the opinion of people on the generic linux julia nightly. I think one advantage is that you dont need to build every time you update.

TrialnError commented on 2014-10-27 16:42

@haawda: Even if not building the doc. The source files were located there.
If that is now failing maybe this stuff moved somewhere else. Will check that.


Edit: The location changed. From /usr/share/julia/doc to /usr/share/doc/julia

TrialnError commented on 2014-10-27 16:19

@haawda: Even if not building the doc. The source files were located there.
If that is now failing maybe this stuff moved somewhere else. Will check that

haawda commented on 2014-10-25 15:38

"rm -r $pkgdir/usr/share/julia/doc" fails, because you have disabled building docs.

TrialnError commented on 2014-09-24 09:16

Built the package in a clean chroot with this PKGBuild and it was successfully. So dunno what happened. Maybe you added the option to built julia with clang.


But an update will follow. They included a desktop file and a icon, so a call to refresh the icon cache will be necessary (or nicer)

TrialnError commented on 2014-09-23 11:47

Shouldn't be as it defaulted in the past to gcc for building. Clang could be used as an alternative compiler but it was necessary to set a flag.
But I'm looking at the source

(And please more descriptive: "This fails to build" and "Manually building from source" is somewhat misleading. Even if a PKGBuild is used it builds from source. What changed when you build with the PKGBuild and without (aka which flags weren't there etc))

Edit: Nope. Shouldn't be necessary. Opt-In compiler.
And it shouldn't be the case that some extra/llvm files landed in the extra/clang package.
But asap I will try this myself

TrialnError commented on 2014-09-23 11:33

Shouldn't be as it defaulted in the past to gcc for building. Clang could be used as an alternative compiler but it was necessary to set a flag.
But I'm looking into at the source

(And please more descriptive: "This fails to build" and "Manually building from source" is somewhat misleading. Even if a PKGBuild is used it builds from source. What changed when you build with the PKGBuild and without (aka which flags weren't there etc))

PythonNut commented on 2014-09-22 00:58

This fails to build unless "clang" is installed.

(Manually building from source works fine without clang)

Is clang a dependency?

PythonNut commented on 2014-09-22 00:57

This fails to build unless "clang" is installed, while directly cloning and building the master from source does not.

TrialnError commented on 2014-09-16 12:28

@PythonNut:

Theoretically yes, but it's not necessary to add that. Every user has a /etc/makepkg.conf. In there it's possible to set how many cores should be used. That's the way it should be done. And not everyone will use every core for compiling.
Adding the -j param into the PKGBuild just make sense if a project cannot be compiled on more than one core (example webkitgtk) and it's necessary to override the makepkg.conf setting.

PythonNut commented on 2014-09-14 21:53

Would adding support for multithreaded building make sense?

The Julia git repo says
"name -j N"
Should make the build parallel on N cores.

So
"make -j $(grep --count processor /proc/cpuinfo)"
Should make the build parallel on all cores.

TrialnError commented on 2014-09-05 23:57

Didn't follow upstream closely. So what is the status with llvm?
llvm3.5 is in [staging] and this was the next version they want to support. Is the change to 3.5 done?

xyproto commented on 2014-08-24 21:07

Splitting out the documentation for the official julia package has already been reported and I'm planning to do so. https://bugs.archlinux.org/task/41194

TrialnError commented on 2014-07-11 23:19

Now this PKGBuild is a splitpackage. One for julia and one for the documentation. Since the doc needs to be built too (Sourcefiles in a finished package isn't pretty, so I removed them completly for julia package).
The Doc is available in a lot of formats. I decided to add 4 of them to the PKGBuild (pdf, info, man and html files)

Building the doc source introduces some makedepends, but no real depends. But they're in case of the texlive packages everything else but small. And one package is just on AUR.
So the doc package build is disabled by default. It will be created, but it's empty.

If someone wants the doc he just needs to remove the # before the second makedepends line, the make calls and before the lines in the julia-doc package function.

The best would be, if the repo julia package could provide the generated docs.
Or I could upload the package I created if someone can name an uploader that allows binaries and isn't crappy.

csousa commented on 2014-05-05 23:18

@pwl Just before I read your comment, I've filled a bug report at Community Julia package about that same issue [https://bugs.archlinux.org/task/40231] making the same suggestion of yours.

pwl commented on 2014-05-05 14:40

There is a bug[1] (or just incompatibility) that prevents julia profiler to work with llvm 3.4. With llvm 3.3 the profiler works just fine, but the build time is significantly increased as julia has to build llvm 3.3 from scratch each time it is installed. So I suggest setting USE_SYSTEM_LLVM=0 if you want to avoid this (and possibly other) bugs in future.

[1] https://github.com/JuliaLang/julia/issues/6275

csousa commented on 2014-04-10 17:55

Although not heavily tested, Julia seems to be working ok with USE_SYSTEM_LLVM=1 (LLVM 3.4).

TrialnError commented on 2014-04-08 05:57

Thanks for the info. Will upload an updated PKGBuild asap (which can take a few hours, as I'm not at home and not having an arch system at hand)

alyst commented on 2014-04-06 13:19

There are a few changes in julia/master:
1) it looks like they've fixed the incompatibility with LLVM 3.4, so the system one could be used once again (although I hadn't done extensive testing)
2) they have dropped out the support for system Rmath, now there's only Rmath-julia (and its building is turned on as of yesterday)
3) readline is no longer needed since now julia has her own implementation of REPL

Here [1] you can find the updated PKGBUILD.

[1] http://pastebin.com/QgHu789N

JoiDegn commented on 2014-03-23 12:16

The PKGBUILD in its current form installs julia version 0.3.0-prerelease+2146.

devmotion commented on 2014-03-14 04:41

I managed to build julia 0.2.1 with this PKGBUILD: https://gist.github.com/devmotion/9542152
I used the following patches: https://gist.github.com/devmotion/9542181 https://gist.github.com/devmotion/9542168

devmotion commented on 2014-03-14 03:11

I managed to build julia 0.2.1 with this PKGBUILD: http://pastebin.com/ZzuEXgFc
I used the following patch for readline: http://pastebin.com/MgyQfaSq (I'm sorry, pastebin apparently removed the trailing newline).

DiegoAscanio commented on 2014-03-13 03:03

TrialnError, one strange thing, is that my build only worked when I checked out the entire repo and then pointed it to v0.2.1 tag.

When i checked out directly this tag, the build broke

So, it's not so stable as I suposed it was...

Thanks for the sugestion!

TrialnError commented on 2014-03-09 18:48

You mean stable in the case you build a pointed release without the need to checkout the whole repo? (Or directly checkout just the tag not HEAD)
In any case, put it up somewhere (directly on AUR, or another paste service) so someone can test it

DiegoAscanio commented on 2014-03-08 20:59

Hey everyone!

I managed to build julia 0.2.1 (stable release, according to JuliaLang git page), based on this PKGBUILD, on readline 6.3 and on JuliaLang git source (i checked out a clone of the repo, to 0.2.1 tag. Also, I modified ui/repl-readline.c to fits readline 6.3)

Does anyone wants to test it? It would really help me to build a PKGBUILD to the stable version of the language, according to Julia Developpers...

Ps:

Thanks to Mihi and TrialnError, for making it possible!

Sorry for the poor english folks! Regards from Brazil!

wallnuss commented on 2014-03-02 02:30

Also I it seems that using llvm 3.4 works fine now.

wallnuss commented on 2014-03-01 15:45

Build breaks with readline = 6.3

https://github.com/JuliaLang/julia/issues/6000

TrialnError commented on 2014-02-09 16:01

@csousa
Those segmentation faults were fixed[0]. So could you please test if it works good enough with llvm 3.4?
____
[0]https://github.com/JuliaLang/julia/commit/5c1b5ad24e745ec785c2bd32d036977fbd79b5e9

TrialnError commented on 2014-02-08 16:26

Thanks for the info alyst. It seems they pushed some commits today which alters the makefile and Make.inc[0]. PREFIX got renamed to prefix

For the patchelf thing you must not do anything. It is just a fail while building. Normally no need to add it as a external package.
And as they're tampering with the makefile problems can occur

Edit: SYSCONFDIR seems to be lowercase too. Maybe DESTDIR will also change soon

____
[0] https://github.com/JuliaLang/julia/commit/30ba746f0dfd731d91f554c0e50e92c84c9ff451

TrialnError commented on 2014-02-08 16:21

Thanks for the info alyst. It seems they pushed some commits today which alters the makefile and Make.inc[0]. PREFIX got renamed to prefix

For the patchelf thing you must not do anything. It is just a fail while building. Normally no need to add it as a external package.
And as they're tampering with the makefile problems can occur

____
[0] https://github.com/JuliaLang/julia/commit/30ba746f0dfd731d91f554c0e50e92c84c9ff451

alyst commented on 2014-02-08 15:26

I've got problems with the current PKGBUILD and julia-git head. I think the installation prefix has to be lowercase. The corrected PKGBUILD is here: http://pastebin.com/xbjynmuU

alyst commented on 2014-02-08 14:24

It failed building for me with:

# Update RPATH entries of Julia if ERROR: paths must be absolute paths, they must start with a forward slash! != ../lib/julia
for julia in /tmp/yaourt-tmp-xxx/aur-julia-git/pkg/julia-gitjulia-8608690a96/bin/julia-* ; do \
patchelf --set-rpath '$ORIGIN/ERROR: paths must be absolute paths, they must start with a forward slash!:$ORIGIN/ERROR: paths must be absolute paths, they must start with a forward slash!' $julia; \
done
/bin/sh: line 1: patchelf: command not found
/bin/sh: line 1: patchelf: command not found
/bin/sh: line 1: patchelf: command not found
/bin/sh: line 1: patchelf: command not found

Should patchelf (I've found one in AUR) be included into makedeps?

TrialnError commented on 2014-02-07 18:06

Thanks for the note csousa.
I agree it may be the best to set USE_SYSTEM_LLVM=0, since they skip the support for 3.4.
So, with the next PKGBuild update the compilation time will skyrocket


@atomicules: For me not, as I do not use R ;) But the note onto the patched library is another thing. I will take a look at the links and if it's the best julia shall build the lib itself

And some other changes will come (I noticed notes about missing gtar and some USE_SYSTEM calls were changed)

csousa commented on 2014-02-06 04:24

Hi,

The PKGBUILD sets make to USE_SYSTEM_LLVM=1, and current version of LLVM in Arch is 3.4.

Since Julia has some issues with LLVM 3.4, some segmentation faults and other errors can occur. Please see: https://groups.google.com/forum/#!topic/julia-users/5zjoL6nMHyE and https://github.com/JuliaLang/julia/issues/5696 .

I've tried to downgrade Arch LLVM to 3.3 (using https://wiki.archlinux.org/index.php/Arch_Rollback_Machine) and that fixes the issues.

I didn't try compiling Julia with USE_SYSTEM_LLVM=0 as it was taking too much time, but I suppose that this will be the only option to the PKGBUILD since setting it to be dependent on LLVM 3.3 may be worst for the users.

Best,
Cristóvão D. Sousa

atomicules commented on 2014-02-01 13:33

Would it not make more sense to remove the dependency on librmath? That package conflicts with R. Since Julia is targeting the same kind of user base it is likely users will want to have both installed.

Also Julia uses a patched patched version of the Rmath library and recommend that their patched version is used (See [1] [2]). The AUR librmath package is a straight build from the R release.

[1]: https://github.com/JuliaLang/julia/blob/master/DISTRIBUTING.md#notes-on-rmath
[2]: https://groups.google.com/d/topic/julia-dev/WQ-Duwlo6gg/discussion

Anyway, since I had R installed, I changed the PKGBUILD file and removed the dependency on librmath and then set USE_SYSTEM_RMATH to 0. All built fine.

TrialnError commented on 2013-12-27 18:20

The best case indeed. So shall it be removed and cause no longer problems

csousa commented on 2013-12-27 16:48

Indeed, the patch is no longer needed. http://pastebin.com/mKcw2kmN

csousa commented on 2013-12-27 16:48

Indeed, the patch is no longer needed.

http://pastebin.com/mKcw2kmN

csousa commented on 2013-12-27 16:19

It may be that the patch is no longer needed: https://github.com/JuliaLang/julia/commit/0ee592e8d2bf59517f6f57e82094740df7cf245f

gammel.holte commented on 2013-12-26 23:42

Any fix to this issue?

LowGravitas commented on 2013-12-25 19:39

I've got the patch faiing again, can't figure out how to fix it.

patching file Makefile
Hunk #1 FAILED at 176.
1 out of 1 hunk FAILED -- saving rejects to file Makefile.rej

TrialnError commented on 2013-12-22 21:32

Failing again epitron ;) On 11.12.2013 it still worked ;P

Thanks for covering it videan42. I will upload a new package

snowball commented on 2013-12-22 21:10

Thanks videan42, your patch worked for me.

videan42 commented on 2013-12-21 18:29

I made an updated patch for the Makefile here.
https://gist.github.com/videan42/8072963

Just replace the current patch with this one and update the MD5 in the PKGBUILD.
MD5: d0e9320a8abd7383cdd0f89cec22e789

epitron commented on 2013-12-19 10:31

The Makefile patch is still failing:

==> Starting prepare()...
patching file Makefile
Hunk #1 FAILED at 160.
1 out of 1 hunk FAILED -- saving rejects to file Makefile.rej
==> ERROR: A failure occurred in prepare(). Aborting...

TrialnError commented on 2013-12-06 01:06

Thanks for the note and I will upload the new version soon

TrialnError commented on 2013-12-06 01:05

Thanks for the note and will upload the new version soon

k8n commented on 2013-12-01 00:02

The Makefile patch fails to apply on recent julia repo checkout.

TrialnError commented on 2013-11-27 18:58

And on another note. Don't flag this package because of upstream releases. Yes, they released 0.2, but this is the git PKGBUILD. As long as it builds, everything is ok. Else I need to submit a new pkgbuild after every comment ;)

Will test again with 0.2 if it's possible to build. Previously this wasn't supported and didn't work

TrialnError commented on 2013-11-27 18:47

@mokasin: The r package is suffice, as it includes those libs. I added librmath, because I don't need the complete r stuff
Just change librmath to r

TrialnError commented on 2013-11-27 18:44

@mokasin: The r package is suffice, as it includes those libs. I added librmath, because I don't need the complete r stuff

mokasin commented on 2013-11-25 21:26

Is there any reason why librmath is exclusivly needed? Or would the r package also suffice? Because librmath conflicts with r.

TrialnError commented on 2013-10-31 01:20

I introduced a patch file with this update. It was in my opinion necessary. Although the SYSCONFDIR var was added I needed to write in package() SYSCONFDIR=$pkgdir/etc which resulted into following warning "WARNING: Package contains reference to $pkgdir" in the final package.
So I decided to introduce DESTDIR so I could split it. And it looks more sane now.
And static libs are added back to the package

In the previous update I removed some of the makedeps as they're part of base and base-devel.

maxbaroi commented on 2013-10-16 17:05

@gh02t

I was having a similar problem. I kept receiving a connection timed out error from github. My problem was the PKGBUILD was fetching from github over the git:// protocol and the firewall I was behind was blocking that port.

It worked fine when I fetched over the https protocol. I don't know how to mess around with the PKGBUILD file to correct this sort of problem. So instead I used a kludge by changing my git settings.

$ git config --global url."https://".insteadOf git://
will configure git to use the https protocol whenever asked to use the git protocol. I don't think it's particularly good solution, but it works and should solve similar problems for other packages.

gh02t commented on 2013-08-06 23:16

It seems to be something particular to my system. I've been talking with the devs on Github. Julia builds fine for me on a different system. I'll post back here if we ever figure out what's going on.

TrialnError commented on 2013-08-06 23:11

I had no problems yesterday to built the package.
Did you have the old src/ directory in place?

TrialnError commented on 2013-08-06 23:11

I had no problems yesterday to built the package.
Did you have the old src/ directory in place?

gh02t commented on 2013-07-31 21:17

Hmm... I'm seeing the exact same error as this guy http://comments.gmane.org/gmane.comp.lang.julia.devel/11000 . The poster mentions that the issue was fixed, but it doesn't seem that way to me.

TrialnError commented on 2013-07-04 19:08

I had previously an extra entry, which shouldn't be necessary. As on x686 systems it defaults to USE_BLAS64=0

What did I change?
eijnuhs suggested two ways to handle that. I will add a third one.

But as for this PKGBuild I think it's the easiest way to disable the use of the 64bit libs of blas. As this works with blas from [extra] too, I didn't change the dep. So it's not necessary to install openblas from AUR.

What are the other ways? If you really need the capabilities and benefits that come with 64bit.

Stick to point 2 made by eijnuhs:
"2) Edit openblas PKGBUILD from AUR to include 8byte integer support
With 2), under build(), just add INTERFACE64=1 to make to compile with 8byte integer support."

or use ABS and change the blas package to activate the 8byte support:
Get lapack from abs and add a prepare() function which changes the following: https://www.gnu.org/software/octave/doc/interpreter/Compiling-Octave-with-64_002dbit-Indexing.html (see point blas and lapack)
Maybe it's possible to add those as cmake-flags, but I don't know cmake that well.

TrialnError commented on 2013-07-04 18:36

Please disregard the previous comment. It seems I tend to overcomplicate things :D

TrialnError commented on 2013-07-04 18:10

I will go with the disabling of the 64bit libs for the time being
But I dunno if my construct works. Could someone test it, please?

http://pastie.org/8110519

snowball commented on 2013-07-04 06:06

TrialnError, I can confirm the issue fhs mentioned on x86_64 as well, using blas from extra.

Anonymous comment on 2013-07-03 18:40

Hi again, here's an update.
I force an reinstall of openblas with 64 bit integer support.
This remedies the problem.

So any user can either
1) Install openblas from AUR but set USE_BLAS64=0 in Julia
2) Edit openblas PKGBUILD from AUR to include 8byte integer support
With 2), under build(), just add INTERFACE64=1 to make to compile with 8byte integer support.

Anonymous comment on 2013-07-03 16:43

I have the same issue too
$ julia
ERROR: OpenBLAS was not built with 64bit integer support.
You're seeing this error because Julia was built with USE_BLAS64=1
Please rebuild Julia with USE_BLAS64=0
Quitting.

I use Blas from extra. openBlas is not installed

TrialnError commented on 2013-07-02 20:44

Right. In that case I need other x86 users that can confirm your problem

fhs commented on 2013-07-01 18:04

TrialnError, I forgot to mention, I'm using 64-bit archlinux. It looks like you're using 32-bit archlinux ("i686-pc-linux-gnu").

TrialnError commented on 2013-07-01 17:55

fhs: I cannot reproduce your issue (blas from extra), freshly build

$ julia
_
_ _ _(_)_ | A fresh approach to technical computing
(_) | (_) (_) | Documentation: http://docs.julialang.org
_ _ _| |_ __ _ | Type "help()" to list help topics
| | | | | | |/ _` | |
| | |_| | | | (_| | | Version 0.2.0-2330.ra5405554
_/ |\__'_|_|_|\__'_| | Commit a540555445 2013-07-01 18:42:01
|__/ | i686-pc-linux-gnu

julia>


fhs commented on 2013-06-29 04:48

julia gave me this error:

$ julia
ERROR: OpenBLAS was not built with 64bit integer support.
You're seeing this error because Julia was built with USE_BLAS64=1
Please rebuild Julia with USE_BLAS64=0
Quitting.

It works after I rebuild julia with USE_BLAS64=0. I'm using AUR openblas. I haven't verified if it works with the blas package in Extra but I was getting the same error when using that package before I decided to replace it with openblas.

TrialnError commented on 2013-06-16 23:09

As a sidenote

https://github.com/JuliaLang/julia/issues/3418

The building will fail at the moment with the system llvm3.3. Let julia build it's own version, or wait if it will be fixed upstream

TrialnError commented on 2013-06-16 22:25

Yes, they're writing that. But if Julia compiles it's own librmath, than it should be also the standalone library. So it should work with that

Anonymous comment on 2013-06-13 15:01

The question is whether this works. On R's website ( http://www.cran.r-project.org/doc/manuals/R-admin.html#The-standalone-Rmath-library ) it explicitly says the the standalone library differs from what R uses internally.

TrialnError commented on 2013-06-10 15:13

As I wrote earlier. Open a bug/feature report on the tracker for R and ask if it's possible to add 'provides=librmath' to the PKGBuild. Or if they can make a split-build.

I have no problems on that part, and I'm not using R, so I don't want to install it. But if is a depency available from the repos I will add that and not let build Julia it's own version.

Anonymous comment on 2013-06-08 10:36

About the librmath dependency: I think most people interested in using julia will have R installed on their machine as well, so it would be better to either have julia build it's own librmath library, or somehow avoid a conflict between R and the stand-alone librmath if librmath is provided as a separate package.

In any case, thanks for providing the build!

TrialnError commented on 2013-05-06 21:36

@JakeDust
Thanks for the report. I already added mpfr yesterday and now I realise I forgot to add the package to the deps >.>
I put it as a member of base (which it isn't)

@essenceoffoo
Or it could be asked on the bug-tracker if it's possible to add a specific provides entry to r

JakeDust commented on 2013-05-06 17:52

There is another dependency now, mpfr, since the new BigFloat type was merged (https://github.com/JuliaLang/julia/pull/2814).

essenceoffoo commented on 2013-05-06 16:42

@begin{quote}
The gain is minimal, but I added the librmath package to AUR. As it can be used by others to and since it's explicit possible to build only the libs.
If there are people which have R installed. Please change 'librmath' to 'r'.
@end{quote}

That's easy to do when I'm manually building a package. But my AUR package manager (packer) first wants to install librmath and then julia because julia depends on it. So I don't have a change to edit the PKGBUILD in the process.

I think the best solution would be to add librmath to the optdepends and maybe also R to the optdepends.

Thanks for making this package available :)

TrialnError commented on 2013-04-21 21:31

The gain is minimal, but I added the librmath package to AUR. As it can be used by others to and since it's explicit possible to build only the libs.
If there are people which have R installed. Please change 'librmath' to 'r'.

If there are issues, or reasons to revert the changes I made, so tell me :)

TrialnError commented on 2013-04-21 20:15

Although I added the libuv-git package to AUR, this Build doesn't rely on it (yet). As it fails

And git will most likely move from buildep to dep, as they rely on git for their package management (for Julia packages like Winston)
And I'm not sure what to do with Rmath. The libRmath.so is provided by extra/r. Additionally 50mb to install. There shall exist a standalone lib-archive, so should that be added to AUR, or simply pull it via julia like before?

TrialnError commented on 2013-04-21 19:22

Few changes incoming.
A few USE_SYSTEM variables got added (for example libuv)
So at the moment I'm trying to bring a libuv-git package which will be a dependency.
That way it could be possible to bring the "stable releases" for julia to AUR

TrialnError commented on 2013-04-06 00:20

Jeah, that's right. I prefer system libs. But in case of libm I missed the fact, that it exists in glibc :D

So.. I want to avoid the epoch number (No real reason *cough*)
In a few days I will upload a PKGBuild with the new version string. If no one modifies locally the pkgver than should there no problems with further update informations.

Archetyp commented on 2013-04-02 11:08

No, I also don't know about the differences, but basically they should provide the same mathematical functions. But ATM I am not going to check that :D

So do what you feel is the best. I believe going with libm does no harm and from a brief look I also did not find any statistics of openlibm being better optimized. I asked as I was curious about your reason of changing the libm in favor of openlibm, especially because from what I saw you preferred installed system stuff where possible :D
(Personally, unless somebody comes with an serious issue or a reason why openlibm is better, I'd stick with what's already installed :D).

TrialnError commented on 2013-03-29 19:23

Right.. Didn't thought about -Qo

But I'm still somewhat in doubt.
Julia links specially to it's own version (openlibm)

Project summary: A high quality independent libm implementation when one is not sure of the system libm.
And until now I don't know if they provide the same, or if there are differences, that can break everything. Do you know more about it?

Building went fine though. And Extras are compiled into libopenlibm-extras.so.
No issues with simple testcases

Hrm.. I will change it.

Archetyp commented on 2013-03-29 19:16

You are right about the libuv, I just had the impression that the sentence "If you already have one or more of these packages installed on your system, it is possible to pass USE_SYSTEM_...=1 to make to prevent Julia from compiling duplicates of these libraries." includes also libuv as it is in the list. But apparently not :D

About the libm:
$ pacman -Qo /lib/libm.so
/lib/libm.so is owned by glibc 2.17-3

So this should be fine :)

Archetyp commented on 2013-03-29 19:16

You are right about the libuv, I just had the impression that the sentence "If you already have one or more of these packages installed on your system, it is possible to pass USE_SYSTEM_...=1 to make to prevent Julia from compiling duplicates of these libraries." includes also libuv as it is in the list. But apparently not :D

About the libm:
$ pacman -Qo /lib/libm.so
/lib/libm.so is owned by glibc 2.17-3

So this should be fine :)

Archetyp commented on 2013-03-29 14:30

You are right about the libuv, I just had the impression that the sentence "If you already have one or more of these packages installed on your system, it is possible to pass USE_SYSTEM_...=1 to make to prevent Julia from compiling duplicates of these libraries." includes also libuv as it is in the list. But apparently not :D

About the libm:
$ pacman -Qo /lib/libm.so
/lib/libm.so is owned by glibc 2.17-3

So this should be fine :)

TrialnError commented on 2013-03-28 01:45

Looked at libuv. The biggest argument against adding it, is the fact, that the package installs a specific version. As long as julia pulls from master and not a specific tag/version it could be better, that libuv is also pulled from master

Edit: And if there would exist an USE_SYSTEM_LIBUV Flag

TrialnError commented on 2013-03-28 01:43

Looked at libuv. The biggest argument against adding it, is the fact, that the package installs a specific version. As long as julia pulls from master and not a specific tag/version it could be better, that libuv is also pulled from master

Would change that, if someone is adding a libuv-git PKGBuild

TrialnError commented on 2013-03-28 01:16

Duh, right *cough* I tend to forget adding or removing deps, thanks

Last time I checked, libuv didn't exist in AUR.. Nice
But I'll wait. Julia forked it, so it's necessary to look if the commits are somewhat the same. So long, I won't add it

As for libm. It was recently added to julia as a dep and they point to one of their repos (openlibm)
pacman -Ss libm
cower -s libm
didn't provide me a package named libm, so I assumed it's not in the repos or on AUR. I would appreciate it, if you can point me to a package ;)

Archetyp commented on 2013-03-26 13:38

Probably suitesparse should now be removed from the deps array. And, for consistency, would not be better to add libuv to deps as we have that package in AUR already?:D
Also, why the change of USE_SYSTEM_LIBM so we don't use the system one anymore?:D

About the provides, I would not add them as they all sit in /usr/lib/julia so they won't conflict if you install those packages normally :D

TrialnError commented on 2013-03-25 17:58

Little update. Removed some USE_System lines (nginx and lighthttp were dropped) and changed suitesparse to 0, so Julia will create it's own version.

Concerning suitesparse this mail says enough: https://mailman.archlinux.org/pipermail/arch-dev-public/2013-March/024561.html

Not sure if I should add a few things to provide (suitesparse, libm, libuv)


If someone is testing Pacman 4.1rc1 and need a PKGBuild. You will find one there: https://github.com/Narrat/aur-julia-lang/blob/master/PKGBUILD

TrialnError commented on 2013-03-20 13:02

No, I stumbled on it too. (Although it worked before)

But one correction. The script didn't search them locally. If you invoked the pkgbuild via makepkg and you had changed the the 1 to 0, the build process itself made again those .so files. So it's just necessary to change the 1 to 0 :)
And still right, that it is easily fixed. But I have a problem with that. I have suitesparse installed via octave and now I've got this package and julia provides suitesparse too. Not clean. Until I get an answer the 1 will remain.

And as it is easily fixed everyone can do it (at least if they read our comments), therefore I'll wait at the moment

Archetyp commented on 2013-03-20 12:18

@TrialnError
That script changed it into .so files, though it copied them into the build directory, so he did not find them. Therefore I concluded that setting it to 0 would force him to search for them locally (which he did).
I also thought that setting USE_SYSTEM_SUITESPARSE to 0 as you suggest may help, but that would mean I installed the suitsparse uselessly, so I took the longer way :D

So I was wondering whether I am the only one missing the .so libraries (because quite some people already use it and nobody complained about it) or also others have that problem. In the latter case the easiest way would be to fix the PKGBUILD by either generating the .so libraries or setting USE_SYSTEM_SUITESPARSE to 0. (And, on the contrary, I think that until the answer the 1 should be changed :D)

TrialnError commented on 2013-03-19 18:49

@Archetyp:

Just change those USE_SYSTEM_SUITESPARSE to 0. You don't need to fiddle with the extra script. Those scripts will be invoked if you change the 1 to 0.


And I asked if it's possible to change suitesparse officially to shared libs package. Until the answer the 1 shouldn't be changed

TrialnError commented on 2013-03-19 02:04

@Archetype:
After running that script, why did you change USE_SYSTEM_SUITESPARSE=1 into 0. You changed it with that script into .so files, so that line should still be 1. Didn't throw it errors like: "Existing in the filesystem"?

Also, checked the suitesparse package and it seems that is truly statically build. Maybe the maintainer should be contacted and asked to change it into shared.
IIRC shared is the preferred way.

in my opinion using the script is semi-optimal. Because it's highly possible, that uninstalling suitesparse might now fail, because you altered the files on top of pacman. But I didn't look at the script and I don't know what it's doing.

Maybe it copies them to another location und it's necessary to change the line. But at first glance it doesn't make much sense and could cause problems

Archetyp commented on 2013-03-17 17:24

mihi, I just tried to compile but got following error:

LoadError("sysimg.jl",159,LoadError("linalg.jl",157,LoadError("linalg/umfpack.jl",47,ErrorException("error compiling anonymous: could not load module libumfpack: libumfpack: cannot open shared object file: No such file or directory"))))

For me the solution was as mentioned in docs: "SuiteSparse [...] is typically only installed as a static library, while USE_SYSTEM_SUITESPARSE=1 requires that it is a shared library. Running the script contrib/repackage_system_suitesparse4.make will copy your static system SuiteSparse installation into the shared library format required by Julia."
Running that script and then compiling with USE_SYSTEM_SUITESPARSE=0 did the trick for me. So I am wondering whether I'm the only one seeing this :D

mihi commented on 2013-03-09 12:39

@burntsushi, I can't verify the problem. Works fine for me.

burntsushi commented on 2013-03-07 02:38

Build is failing on my machine (x86_64):

make[1]: Entering directory `/tmp/yaourt-tmp-andrew/aur-julia-git/src/julia-build/ui/webserver'
CC ui/webserver/webserver.o
CC ui/webserver/server.o
server.cpp: In function ‘void scgi::run_server(int, scgi::callback)’:
server.cpp:666:29: error: too few arguments to function ‘int uv_run(uv_loop_t*, uv_run_mode)’
In file included from server.h:4:0,
from server.cpp:2:
../../deps/libuv/include/uv.h:261:15: note: declared here
make[1]: *** [server.o] Error 1
make[1]: Leaving directory `/tmp/yaourt-tmp-andrew/aur-julia-git/src/julia-build/ui/webserver'
make: *** [webrepl] Error 2

mihi commented on 2013-02-17 11:00

Merged pull reqeust by github user Narrat.

Anonymous comment on 2013-01-22 14:58

I'm getting an out of memory error when building with makepkg during the linking phase. FYI I have 32 GB of RAM and I've tried playing around with ulimit to no avail. It works fine when I do the usual make && sudo make install. I've posted the issue on Github. Here's a link: https://github.com/JuliaLang/julia/issues/2102

Anonymous comment on 2012-12-07 05:46

This is fantastic. Thank you!

TrialnError commented on 2012-11-28 17:16

I cannot confirm this.
Probably you got a bad moment
https://github.com/JuliaLang/julia/commit/a6e75e3bfec32a989407587581cfe737d06d0191
https://github.com/JuliaLang/julia/issues/1616

Around that time they worked at the lib/uv / libuv thing

Anonymous comment on 2012-11-27 23:18

I'm getting an error that seems to be caused by libuv not being built with fPIC. Does that happen to anybody else or is it just me?

TrialnError commented on 2012-11-20 18:06

The (web)frontend thing will undergo some changes.
Possible that the lighttpd frontend will be removed soon.
If that happens, the opt can be removed.
Status of nginx is also unknown to me.

What shall come is an iPython based Interface, whatever that means

mihi commented on 2012-11-14 09:46

Thanks to Narrat (https://github.com/Narrat) we've got a new julia release with all system-dependencies.

mihi commented on 2012-10-22 11:38

Hey, I started out by using everything from the system, but some libs weren't compatible (it was an early release). I'd be happy to integrate julia fully into the system. Any help would be appreciated (please contribute on github: https://github.com/mjakl/aur-julia-lang)

Thanks!

JakeDust commented on 2012-10-19 21:06

TBH, although it makes installing much more painful, I like using the julia versions to keep everything separate and working even with or without updates. Maybe you could USE_SYSTEM_* = 1 as a default, and leave an explicit message about the possibility of changing them in the PKBUILD?

TrialnError commented on 2012-10-19 20:53

I would prefer using the system packages. Only changing this behaviour if there is a serious problem

TrialnError commented on 2012-10-19 20:52

I would prefer using the system packages. Only changing this behaviour if there is a serious problem

mihi commented on 2012-10-06 21:03

Added arpack to "conflicts", maybe it'd be better to use the system arpack, lapack, and blas packages again?

mrbit commented on 2012-10-06 20:52

/usr/lib/libarpack.so already exists in the filesystem

add conflict package its arpack

thanks

mihi commented on 2012-09-23 20:56

I've moved the PKGBUILD to github: https://github.com/mjakl/aur-julia-lang

mihi commented on 2012-09-10 07:08

@TrialnError, thanks for your suggestions. I've move the pacakge to /usr and added the USE_SYSTEM_* settings you suggested.

TrialnError commented on 2012-09-08 20:07

Ah
And two suggestions (Maybe just occuring, because I install into /usr)

Julia now creates zlib, which conflicts with the repo one (so adding USE_SYSTEM_ZLIB=1 should be added)

And it conflicts the glpk package if you have installed octave
So, probably adding USE_SYSTEM_GLPK=1 or a conflicts/provides entry into the pkgbuild

TrialnError commented on 2012-09-07 16:02

I'm wondering why is it installed into usr/local?
Any particular reason for that?

mihi commented on 2012-07-16 14:48

@onefire, there is no release of julia as of now, but you could certainly provide a binary package of "stable" snapshots every now and then.

onefire commented on 2012-07-16 00:53

How about a binary package for Julia? I think that it would be useful for people who cannot/do not want to build it from source. It should be easy to do it (I could even do it myself).

mihi commented on 2012-07-13 14:52

Version 20120713-1 uses the system FFTW library (as suggested by oniram)

Anonymous comment on 2012-07-13 14:37

Since fftw has been added as a dependency, we should tell julia to use it:
- USE_SYSTEM_FFTW=0 \
+ USE_SYSTEM_FFTW=1 \

mihi commented on 2012-07-12 20:41

I had to manually remove the installed julia-git package before installing the updated version.

Anonymous comment on 2012-07-10 19:48

Missing FFTW library dependency.

Using 'pacman -S fftw' if it happens.

mihi commented on 2012-05-31 10:40

Thanks for all the help, I've updated the package.

TrialnError commented on 2012-05-31 10:02

@oniram: The extra -build directory is described in the VCS PKGBuild Guidelines: https://wiki.archlinux.org/index.php/Arch_CVS_%26_SVN_PKGBUILD_guidelines
And personally I prefer it that way.

Anonymous comment on 2012-05-30 18:42

The julia.install file is not needed anymore. Today's commit 7351f4812 makes the creation of the 'julia' link part of the regular install process.

Btw, I'm not sure I understand the need to create a clone of the repository into 'julia-build'. Why not just use the 'julia' folder directly?

Anonymous comment on 2012-05-30 18:35

@mihi: The error you're seeing is caused by commit 6879f194d which changes DESTDIR by PREFIX in the Makefile install rule.

This patch to PKGBUILD fixes the problem (at least for me):
--- PKGBUILD.orig 2012-05-25 11:25:49.000000000 -0400
+++ PKGBUILD 2012-05-30 14:35:10.638771189 -0400
@@ -32,7 +32,7 @@

echo "Compiling"
cd "$srcdir/$_gitname-build"
- make PREFIX=/usr \
+ make PREFIX="$pkgdir/usr" \
USE_SYSTEM_LLVM=1 \
USE_SYSTEM_READLINE=1 \
USE_SYSTEM_PCRE=1 \
@@ -47,7 +47,7 @@

package() {
cd "$srcdir/$_gitname-build"
- make PREFIX=/usr \
+ make PREFIX="$pkgdir/usr" \
USE_SYSTEM_LLVM=1 \
USE_SYSTEM_READLINE=1 \
USE_SYSTEM_PCRE=1 \
@@ -58,7 +58,6 @@
USE_SYSTEM_ARPACK=0 \
USE_SYSTEM_BLAS=0 \
USE_SYSTEM_LAPACK=0 \
- DESTDIR="$pkgdir/" \
install
}

mihi commented on 2012-05-30 14:14

Currently the package part fails with a permission denied error:

JULIA usr/lib/julia/sys0.ji
JULIA usr/lib/julia/sys.ji
==> Entering fakeroot environment...
==> Starting package()...
mkdir -p /usr/local/{sbin,bin,etc,lib/julia,share/julia}
mkdir: cannot create directory ‘/usr/local/lib/julia’: Permission denied
mkdir: cannot create directory ‘/usr/local/share/julia’: Permission denied
make: *** [install] Error 1
==> ERROR: A failure occurred in package().
Aborting...

To be honest, I don't know why this is happening, it should be built inside a fakeroot environment...

TrialnError commented on 2012-05-30 10:09

@rennis250: I suppose this was an upstream issue. By this date it compiles fine mit llvm
(I just had the problem, that the package part produced an error)

Anonymous comment on 2012-05-28 00:20

***NOTE:***

I did not change the official PKGBUILD, but altered the local copy on my machine. You will need to do the same until the one on the AUR is changed.

Anonymous comment on 2012-05-28 00:19

I changed the PKGBUILD to not use the system LLVM and it compiled fine. An initial run produced an error about a missing libfftw file, but installing the standard FFTW through Arch's package manager fixed the problem. Everything is working now.

Anonymous comment on 2012-05-27 21:11

Building fails with the following error:

CC src/codegen.o
In file included from codegen.cpp:253:0:
cgutils.cpp: In function 'llvm::GlobalVariable* stringConst(const string&)':
cgutils.cpp:22:63: error: no matching function for call to 'llvm::ConstantArray::get(llvm::LLVMContext&, const char*)'
cgutils.cpp:22:63: note: candidate is:
In file included from /usr/include/llvm/Support/ConstantFolder.h:20:0,
from /usr/include/llvm/Support/IRBuilder.h:24,
from codegen.cpp:19:
/usr/include/llvm/Constants.h:354:20: note: static llvm::Constant* llvm::ConstantArray::get(llvm::ArrayType*, ilvm::ArrayRef<llvm::Constant*>)
/usr/include/llvm/Constants.h:354:20: note: no known conversion for argument 1 from 'llvm::LLVMContext' to 'llvm::ArrayType*'
In file included from codegen.cpp:254:0:
debuginfo.cpp: In function 'void getFunctionInfo(const char**, int*, const char**, size_t)':
debuginfo.cpp:43:47: error: 'const class llvm::Function' has no member named 'getNameStr'
codegen.cpp: In function 'void jl_init_codegen()':
codegen.cpp:2147:5: error: 'NoFramePointerElim' is not a member of 'llvm'
codegen.cpp:2148:5: error: 'NoFramePointerElimNonLeaf' is not a member of 'llvm'
make[2]: *** [codegen.o] Error 1
make[1]: *** [julia-release] Error 2

I'm running an x86_64 build of Arch on an AMD processor.

mihi commented on 2012-05-25 15:27

Link to julia in /usr/julia instead of /usr/share/julia
Use system lighttpd as suggested here: https://github.com/JuliaLang/julia/issues/830#issuecomment-5828360
Did anyone get the web UI up and running?

mihi commented on 2012-05-13 22:05

Currently both ways to build julia, system-fftw and fftw provided by the julia package, fail.
I'll update the package as soon as I find a solution.

JakeDust commented on 2012-05-13 21:15

I'm getting the following error on x86_64 while running makepkg:


Making install in tests
libtool: link: gcc -std=gnu99 -pthread -march=native -O2 -pipe -fstack-protector --param=ssp-buffer-size=4 -D_FORTIFY_SOURCE=2 -Wl,-O1 -Wl,--sort-common -Wl,--as-needed -Wl,-z -Wl,relro -Wl,--hash-style=gnu -o .libs/bench bench-bench.o bench-hook.o bench-fftw-bench.o ../threads/.libs/libfftw3f_threads.so ../.libs/libfftw3f.so ../libbench2/libbench2.a -lpthread -pthread -Wl,-rpath -Wl,/home/jake/pkg/julia-git/src/julia-build/usr/lib
../libbench2/libbench2.a(mflops.o): In function `mflops':
mflops.c:(.text+0x80): undefined reference to `log'
mflops.c:(.text+0xe8): undefined reference to `log'
../libbench2/libbench2.a(verify-lib.o): In function `aphase_shift':
verify-lib.c:(.text+0x7c0): undefined reference to `sincos'
../libbench2/libbench2.a(verify-lib.o): In function `impulse':
verify-lib.c:(.text+0x1108): undefined reference to `sqrt'
verify-lib.c:(.text+0x1198): undefined reference to `sqrt'
../libbench2/libbench2.a(verify-lib.o): In function `accuracy_test':
verify-lib.c:(.text+0x1c7b): undefined reference to `sqrt'
verify-lib.c:(.text+0x1c8c): undefined reference to `sqrt'
../libbench2/libbench2.a(verify-r2r.o): In function `bench_sincos':
verify-r2r.c:(.text+0x136a): undefined reference to `cos'
verify-r2r.c:(.text+0x1392): undefined reference to `sin'
../libbench2/libbench2.a(mp.o): In function `compare':
mp.c:(.text+0x1caa): undefined reference to `sqrt'
collect2: error: ld returned 1 exit status
make[4]: *** [bench] Error 1
make[3]: *** [install-recursive] Error 1
make[2]: *** [/home/jake/pkg/julia-git/src/julia-build/usr/lib/libfftw3f.3.so] Error 2
make[1]: *** [julia-release] Error 2
make: *** [release] Error 2
==> ERROR: A failure occurred in build().
Aborting...

mihi commented on 2012-05-12 22:50

Removed FFTW dependency and rely on the one julia compiles itself.

mihi commented on 2012-03-11 14:46

Removed arpack from system libraries (use the one build by julia linking to lapack with openblas for better performance)

mihi commented on 2012-03-11 13:15

Reverted back to using OpenBLAS and LAPACK provided by julia.

mihi commented on 2012-03-11 12:42

The new "release" uses more libraries already in Archlinux' repositories and compiles fine now.
libunwind is available via AUR.

mihi commented on 2012-03-09 09:27

I've reported the issue upstream, shouldn't take long.
In the meantime you could insert a "git checkout 3eea0c8ffd780290aa0f185f05e786aea42e2f49" just before the compilation in line 35 to use a known good state.
HTH

mefistofeles commented on 2012-03-09 05:18

Getting the following error on arch x86_64:

libtool: link: gcc -shared -Wl,--whole-archive kernel/.libs/libkernel.a dft/.libs/libdft.a dft/scalar/.libs/libdft_scalar.a dft/scalar/codelets/.libs/libdft_scalar_codelets.a rdft/.libs/librdft.a rdft/scalar/.libs/librdft_scalar.a rdft/scalar/r2cf/.libs/librdft_scalar_r2cf.a rdft/scalar/r2cb/.libs/librdft_scalar_r2cb.a rdft/scalar/r2r/.libs/librdft_scalar_r2r.a reodft/.libs/libreodft.a api/.libs/libapi.a simd-support/.libs/libsimd_support.a simd-support/.libs/libsimd_sse2_nonportable.a dft/simd/sse2/.libs/libdft_sse2_codelets.a rdft/simd/sse2/.libs/librdft_sse2_codelets.a -Wl,--no-whole-archive -lm -Wl,-rpath -Wl,-soname -Wl,libfftw3.so.3 -o .libs/libfftw3.so.3.3.0
/usr/bin/ld: cannot find libfftw3.so.3: No such file or directory
collect2: ld returned 1 exit status
make[3]: *** [libfftw3.la] Error 1
make[2]: *** [install-recursive] Error 1

One "weird" thing is that it tries to download and compile at the same time (doing thins in parallel), I'm not sure if it's compiling something that needs the implementation of fftw3 that comes with julia but that fftw3 is not yet compiled when needed.

Suggestions welcomed.

mefistofeles commented on 2012-03-09 03:31

Getting the following error on arch x86_64:

libtool: link: gcc -shared -Wl,--whole-archive kernel/.libs/libkernel.a dft/.libs/libdft.a dft/scalar/.libs/libdft_scalar.a dft/scalar/codelets/.libs/libdft_scalar_codelets.a rdft/.libs/librdft.a rdft/scalar/.libs/librdft_scalar.a rdft/scalar/r2cf/.libs/librdft_scalar_r2cf.a rdft/scalar/r2cb/.libs/librdft_scalar_r2cb.a rdft/scalar/r2r/.libs/librdft_scalar_r2r.a reodft/.libs/libreodft.a api/.libs/libapi.a simd-support/.libs/libsimd_support.a simd-support/.libs/libsimd_sse2_nonportable.a dft/simd/sse2/.libs/libdft_sse2_codelets.a rdft/simd/sse2/.libs/librdft_sse2_codelets.a -Wl,--no-whole-archive -lm -Wl,-rpath -Wl,-soname -Wl,libfftw3.so.3 -o .libs/libfftw3.so.3.3.0
/usr/bin/ld: cannot find libfftw3.so.3: No such file or directory
collect2: ld returned 1 exit status
make[3]: *** [libfftw3.la] Error 1
make[2]: *** [install-recursive] Error 1

One "weird" thing is that it tries to download and compile at the same time (doing thins in parallel), I'm not sure if it's compiling something that needs the implementation of fftw3 that comes with julia but that fftw3 is not yet compiled when needed.

Suggestions welcomed.

mihi commented on 2012-03-03 11:00

Changed to arch=('i686' 'x86_64')
(Thanks, at0m13)

Anonymous comment on 2012-03-03 02:00

The package isn't architecture independent, so the arch line should be:
arch=('i686' 'x86_64')

mihi commented on 2012-02-28 21:28

Thank you, I've updated the PKGBUILD with your suggestion.

d1t2hsu commented on 2012-02-28 20:59

due to commits recently, add "PREFIX=/usr" to make install

mihi commented on 2012-02-22 22:13

Thank you, I've added gcc-fortran to the runtime dependencies.

Anonymous comment on 2012-02-22 21:15

I heard about julialang this weekend. After searching for compiled binaries in the official repos and here without success, I decided to compile it; which I did today.

When I was thinking about uploading it to AUR and finally being responsible for a package here, I saw your post in the dev list. Now I don't know if this was good or bad: it means less responsibility, but I really think I would like maintaining julialang.

Anyway, I wish you good luck and for whatever you are going to use it, happy coding!

Also, I guess you should add gcc-fortran as a dependency.