AUR (en) - julia-git

Search Criteria

Enter search criteria

Search by

Keywords

Out of Date

Sort by

Sort order

Per page

Package Details: julia-git 1.8.0.DEV.r51125.g1db8b8f1607-1

Package Actions

Git Clone URL:	https://aur.archlinux.org/julia-git.git (read-only, click to copy)
Package Base:	julia-git
Description:	High-level, high-performance, dynamic programming language
Upstream URL:	https://julialang.org/
Licenses:	MIT
Conflicts:	julia
Provides:	julia
Submitter:	mihi
Maintainer:	TrialnError (fusion809, mar)
Last Packager:	mar
Votes:	53
Popularity:	0.002136
First Submitted:	2012-02-22 08:57 (UTC)
Last Updated:	2022-01-22 22:49 (UTC)

Dependencies (18)

desktop-file-utils (desktop-file-utils-git)
gmp (gmp-hg)
gtk-update-icon-cache (gtk3-git, gtk-update-icon-cache-git, gtk-rc)
hicolor-icon-theme (hicolor-icon-theme-git)
libutf8proc (libutf8proc-git)
openlibm (openlibm-git)
p7zip (p7zip-jinfeihan57-git, p7zip-natspec, 7-zip-full)
xdg-utils (mimi-git, busking-git, xdg-utils-git, linopen, xdg-utils-mimeo, xdg-utils-handlr, xdg-utils-slock, mimi-bachoseven-git, xdg-utils-symlink-fix, mimejs-git)
zlib (zlib-static, zlib-git, zlib-asm, minizip-asm, zlib-ng, zlib-ng-compat-git)
cmake (cmake-git) (make)
gcc-fortran (gccrs-fortran-git, gcc-fortran-multilib-git, gcc-fortran-git) (make)
gcc-libs (fastgcc, gcc-libs-multilib-git, gcc-libs-git) (make)
git (git-git, git-vfs, git-run-command-patch-git) (make)
patchelf (make)
python (python38, python36, python37, python3.7, nogil-python, python311, python39) (make)
fftw (fftw-mpi, fftw-amd) (optional) – If using the FFTW package from julia
gnuplot (gnuplot-caca, gnuplot-svg, gnuplot-git, gnuplot-headless, gnuplot-nogui) (optional) – If using the Gaston Package from julia
openblas-lapack (openblas-lapack-git) (optional) – multithreaded replacement for lapack

Required by (20)

cantor-git (requires julia) (make)
cantor-git (requires julia) (optional)
data-science-languages-meta (requires julia)
gmsh (requires julia) (optional)
gmsh-bin (requires julia) (optional)
julia-aarch64-git-docs (requires julia)
julia-git-docs (requires julia)
julia-loadpath (requires julia) (optional)
libcxxwrap-julia (requires julia)
meep (requires julia)
meep-python (requires julia)
mlpack (requires julia) (optional)
neovim-cmp-latex-symbols-git (requires julia) (make)
neovim-sniprun (requires julia) (optional)
nteract-bin (requires julia) (optional)
octave-hg (requires julia)
python-einsteinpy_geodesics (requires julia)
unblur (requires julia)
vim-codi-git (requires julia) (optional)
vim-julia-git (requires julia) (optional)

Sources (3)

Latest Comments

Brettmahar commented on 2021-07-15 23:03 (UTC)

Julia is not simple to compile, the language is nice but build failures are not rare, eg https://github.com/JuliaLang/julia/issues/40585

FYI for anyone with this issue, the prebuilt binaries for Linux x86 and aarch64 work fine - available at https://julialang.org/downloads/ and https://julialang.org/downloads/nightlies/

Volker_Weissmann commented on 2021-06-08 23:47 (UTC)

I can confirm this build error:

 g++ -m64 -shared  -pipe -fPIC -fno-rtti -std=c++14 -pedantic -D_FILE_OFFSET_BITS=64 -march=x86-64 -mtune=generic -O2 -pipe -fno-plt -fexceptions         -Wp,-D_FORTIFY_SOURCE=2 -Wformat -Werror=format-security         -fstack-clash-protection -fcf-protection -Wp,-D_GLIBCXX_ASSERTIONS -w  -O3 -ggdb2 -falign-functions -momit-leaf-frame-pointer -D_GNU_SOURCE -I. -I/home/volker/cloned/julia-git/src/julia/src -I/home/volker/cloned/julia-git/src/julia/src/flisp -I/home/volker/cloned/julia-git/src/julia/src/support -I/home/volker/cloned/julia-git/src/julia/usr/include -I/home/volker/cloned/julia-git/src/julia/usr/include -DLIBRARY_EXPORTS -I/home/volker/cloned/julia-git/src/julia/deps/valgrind -Wall -Wno-strict-aliasing -fno-omit-frame-pointer -fvisibility=hidden -fno-common -Wno-comment -Wpointer-arith -Wundef -Wno-unused-result -DJL_BUILD_ARCH='"x86_64"' -DJL_BUILD_UNAME='"Linux"' -I/home/volker/cloned/julia-git/src/julia/usr/include -DLLVM_SHLIB "-DJL_SYSTEM_IMAGE_PATH=\"../lib/julia/sys.so\"" "-DJL_LIBJULIA_SONAME=\"libjulia.so.1\""       "-DJL_LIBJULIA_INTERNAL_SONAME=\"libjulia-internal.so.1\"" ./jloptions.o ./runtime_ccall.o ./rtutils.o ./codegen.o ./llvm-ptls.o ./jltypes.o ./gf.o ./typemap.o ./smallintset.o ./ast.o ./builtins.o ./module.o ./interpreter.o ./symbol.o ./dlload.o ./sys.o ./init.o ./task.o ./array.o ./dump.o ./staticdata.o ./toplevel.o ./jl_uv.o ./datatype.o ./simplevector.o ./runtime_intrinsics.o ./precompile.o ./threading.o ./partr.o ./stackwalk.o ./gc.o ./gc-debug.o ./gc-pages.o ./gc-stacks.o ./method.o ./jlapi.o ./signal-handling.o ./safepoint.o ./timing.o ./subtype.o ./crc32c.o ./APInt-C.o ./processor.o ./ircode.o ./opaque_closure.o ./jitlayers.o ./aotcompile.o ./debuginfo.o ./disasm.o ./llvm-simdloop.o ./llvm-muladd.o ./llvm-final-gc-lowering.o ./llvm-pass-helpers.o ./llvm-late-gc-lowering.o ./llvm-lower-handlers.o ./llvm-gc-invariant-verifier.o ./llvm-propagate-addrspaces.o ./llvm-multiversioning.o ./llvm-alloc-opt.o ./cgmemmgr.o ./llvm-api.o ./llvm-remove-addrspaces.o ./llvm-remove-ni.o ./llvm-julia-licm.o ./llvm-demote-float16.o -Wl,-rpath,'$ORIGIN/julia' -Wl,-rpath,'$ORIGIN' -Wl,-z,origin -o /home/volker/cloned/julia-git/src/julia/usr/lib/libjulia-internal.so.1.7 -Wl,-Bdynamic -Wl,-no-undefined -Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now -Wl,-Bsymbolic-functions -L/home/volker/cloned/julia-git/src/julia/usr/lib -L/home/volker/cloned/julia-git/src/julia/usr/lib -Wl,--whole-archive ./flisp/libflisp.a -Wl,--whole-archive ./support/libsupport.a -ljulia /home/volker/cloned/julia-git/src/julia/usr/lib/libuv.a -lutf8proc -Wl,--no-whole-archive -lunwind -L/home/volker/cloned/julia-git/src/julia/usr/lib  -lLLVM -Wl,--no-as-needed -ldl -lrt -lpthread -latomic -Wl,--export-dynamic,--as-needed,--no-whole-archive -Wl,--version-script=/home/volker/cloned/julia-git/src/julia/src/julia.expmap   -Wl,-soname=libjulia-internal.so.1
/usr/local/bin/ld: /usr/local/bin/ld: DWARF error: can't find .debug_ranges section.
./codegen.o: in function `gen_cfun_wrapper(llvm::Module*, jl_codegen_params_t&, function_sig_t const&, _jl_value_t*, char const*, _jl_value_t*, _jl_method_instance_t*, jl_unionall_t*, jl_svec_t*, jl_array_t**)':
codegen.cpp:(.text+0x41483): undefined reference to `std::__throw_bad_array_new_length()'
/usr/local/bin/ld: /usr/local/bin/ld: DWARF error: can't find .debug_ranges section.
./llvm-late-gc-lowering.o: in function `std::vector<int, std::allocator<int> >::operator=(std::vector<int, std::allocator<int> > const&) [clone .isra.0]':
llvm-late-gc-lowering.cpp:(.text+0x8d7): undefined reference to `std::__throw_bad_array_new_length()'
/usr/local/bin/ld: ./llvm-late-gc-lowering.o: in function `TrackCompositeType(llvm::Type*, std::vector<unsigned int, std::allocator<unsigned int> >&, std::vector<std::vector<unsigned int, std::allocator<unsigned int> >, std::allocator<std::vector<unsigned int, std::allocator<unsigned int> > > >&)':
llvm-late-gc-lowering.cpp:(.text+0x47a9): undefined reference to `std::__throw_bad_array_new_length()'
/usr/local/bin/ld: ./llvm-late-gc-lowering.o: in function `LateLowerGCFrame::ComputeLiveSets(State&)':
llvm-late-gc-lowering.cpp:(.text+0x16a79): undefined reference to `std::__throw_bad_array_new_length()'
/usr/local/bin/ld: llvm-late-gc-lowering.cpp:(.text+0x16e51): undefined reference to `std::__throw_bad_array_new_length()'
/usr/local/bin/ld: ./llvm-late-gc-lowering.o:llvm-late-gc-lowering.cpp:(.text._ZNSt6vectorIiSaIiEEC2ERKS1_[_ZNSt6vectorIiSaIiEEC5ERKS1_]+0xa7): more undefined references to `std::__throw_bad_array_new_length()' follow
collect2: error: ld returned 1 exit status
make[1]: *** [Makefile:300: /home/volker/cloned/julia-git/src/julia/usr/lib/libjulia-internal.so.1.7] Error 1
make[1]: Leaving directory '/home/volker/cloned/julia-git/src/julia/src'
make: *** [Makefile:76: julia-src-release] Error 2
make: Leaving directory '/home/volker/cloned/julia-git/src/julia'
==> ERROR: A failure occurred in build().
    Aborting...

gustaphe commented on 2021-06-08 06:28 (UTC)

I get a build error:

/usr/bin/ld: ./codegen.o: in function `__gnu_cxx::new_allocator<llvm::Type*>::allocate(unsigned long, void const*)':
/usr/include/c++/11.1.0/ext/new_allocator.h:110: undefined reference to `std::__throw_bad_array_new_length()'
/usr/bin/ld: ./llvm-late-gc-lowering.o: in function `__gnu_cxx::new_allocator<int>::allocate(unsigned long, void const*)':
/usr/include/c++/11.1.0/ext/new_allocator.h:110: undefined reference to `std::__throw_bad_array_new_length()'
/usr/bin/ld: ./llvm-late-gc-lowering.o: in function `__gnu_cxx::new_allocator<unsigned int>::allocate(unsigned long, void const*)':
/usr/include/c++/11.1.0/ext/new_allocator.h:110: undefined reference to `std::__throw_bad_array_new_length()'
/usr/bin/ld: ./llvm-late-gc-lowering.o: in function `__gnu_cxx::new_allocator<int>::allocate(unsigned long, void const*)':
/usr/include/c++/11.1.0/ext/new_allocator.h:110: undefined reference to `std::__throw_bad_array_new_length()'
/usr/bin/ld: /usr/include/c++/11.1.0/ext/new_allocator.h:110: undefined reference to `std::__throw_bad_array_new_length()'
/usr/bin/ld: ./llvm-late-gc-lowering.o:/usr/include/c++/11.1.0/ext/new_allocator.h:110: more undefined references to `std::__throw_bad_array_new_length()' follow
collect2: error: ld returned 1 exit status

sh4kesbeer commented on 2020-12-31 09:04 (UTC)

There seems to be a dependency on 7z, as the build is failing with following error for me:

caused by: 7z binary not found

Volker_Weissmann commented on 2020-12-25 21:15 (UTC)

Without the patch below, build+installation fails on my machine because the stringreplace binary was not found.

diff --git a/PKGBUILD b/PKGBUILD
index 87ecf86..b56957a 100644
--- a/PKGBUILD
+++ b/PKGBUILD
@@ -26,7 +26,7 @@ sha256sums=('SKIP'
             '1aee33d62dcd8e6b65672bd9996a61c83e44056dd31efa79761cb85effb0e6a1'
             'd4c8fe9eec1bc416549924ae328ceb3f63cc736ecd5e67886faa924e7c14bc5d'
             '856dab2da8124df95e4fbd17f1164bebe1b10e99852fedf38f9dfe31f8ae295c'
-            '0b57e0bc6e25c92fde8a6474394f7a99bfb57f9b5d0f7b53f988622ae67de8b7')
+            '09b6077149fa3d22b71b63e471f077d1f3dbeb39d682030c73c316e939e2cc19')


 pkgver() {
diff --git a/make-install-no-build.patch b/make-install-no-build.patch
index 6d89d95..19eeb43 100644
--- a/make-install-no-build.patch
+++ b/make-install-no-build.patch
@@ -10,7 +10,7 @@
 -else
 -  @$(MAKE) $(QUIET_MAKE) release
 -endif
-+install:
++install: $(build_depsbindir)/stringreplace
    @for subdir in $(bindir) $(datarootdir)/julia/stdlib/$(VERSDIR) $(docdir) $(man1dir) $(includedir)/julia $(libdir) $(private_libdir) $(sysconfdir) $(libexecdir); do \
        mkdir -p $(DESTDIR)$$subdir; \
    done

PedroHLC commented on 2020-10-22 13:42 (UTC)

Building form a clean chroot, it failed with:

make[1]: Entering directory '/home/main-builder/pkgwork/src/julia'
 cd /home/main-builder/pkgwork/src/julia/base && /home/main-builder/pkgwork/src/julia/usr/bin/julia -C "native" --output-ji /home/main-builder/pkgwork/src/julia/usr/lib/julia/corecompiler.ji.tmp --startup-file=no --warn-overwrite=yes -g0 -O0 compiler/compiler.jl
ERROR: Unable to load dependent library /home/main-builder/pkgwork/src/julia/usr/bin/../lib/libgcc_s.so.1
Message:/home/main-builder/pkgwork/src/julia/usr/bin/../lib/libgcc_s.so.1: cannot open shared object file: No such file or directory
make[1]: *** [sysimage.mk:61: /home/main-builder/pkgwork/src/julia/usr/lib/julia/corecompiler.ji] Error 1
make[1]: Leaving directory '/home/main-builder/pkgwork/src/julia'
make: *** [Makefile:81: julia-sysimg-ji] Error 2
make: Leaving directory '/home/main-builder/pkgwork/src/julia'
==> ERROR: A failure occurred in build().

TrialnError commented on 2020-06-22 19:39 (UTC)

@fusion809: Every little thing helps. Thank you for your offer :) I will add you as a co-maintainer.

fusion809 commented on 2020-06-21 14:27 (UTC)

@TrialInError I'd be happy to be a co-maintainer. Although, I will admit, I too have my limits in what I can fix. But I can at least fix the odd little things I know how to fix.

fusion809 commented on 2020-06-21 14:25 (UTC)

Build currently fails as docs aren't built but package_julia-git-docs() tries to install them anyway. To fix this, replace lines 68 to 70 of the PKGBUILD with: make.

dlin commented on 2020-03-20 02:02 (UTC)

Could you change to source from git to https to let firewall happier? That's

source=(git+https://github.com/JuliaLang/julia

TrialnError commented on 2019-05-22 22:01 (UTC)

Since a while I haven't done anything with Julia. And since this time the updates and adjustment on this PKGBUILD got sparse. Patches for example couldn't be applied anymore. So anyone who wants to be added as a Comaintainer or even maintain it fully?

fusion809 commented on 2018-12-19 17:00 (UTC) (edited on 2018-12-19 17:00 (UTC) by fusion809)

Build failed for me, with the error:

CC src/flisp/julia_extensions.o
LINK src/flisp/libflisp.a
CC src/flisp/flmain.o
LINK src/flisp/flisp

make[2]: Leaving directory '/data/AUR/julia-git/src/julia/src/flisp' FLISP src/julia_flisp.boot FLISP src/julia_flisp.boot.inc make[1]: Leaving directory '/data/AUR/julia-git/src/julia/src' make[1]: Entering directory '/data/AUR/julia-git/src/julia/src' CC src/jltypes.o In file included from /usr/include/libunwind-x86_64.h:129, from /usr/include/libunwind.h:25, from /data/AUR/julia-git/src/julia/src/julia_internal.h:619, from /data/AUR/julia-git/src/julia/src/jltypes.c:14: /data/AUR/julia-git/src/julia/src/julia_internal.h:623:35: error: floating constant in preprocessor expression (UNW_VERSION_MAJOR == 1 && UNW_VERSION_MINOR != 0 && UNW_VERSION_MINOR != 1)) ^~~~~~~~~~~~~~~~~ /data/AUR/julia-git/src/julia/src/julia_internal.h:623:61: error: floating constant in preprocessor expression (UNW_VERSION_MAJOR == 1 && UNW_VERSION_MINOR != 0 && UNW_VERSION_MINOR != 1)) ^~~~~~~~~~~~~~~~~ make[1]: [Makefile:131: jltypes.o] Error 1 make[1]: Leaving directory '/data/AUR/julia-git/src/julia/src' make: [Makefile:72: julia-src-release] Error 2 make: Leaving directory '/data/AUR/julia-git/src/julia' ==> ERROR: A failure occurred in build(). Aborting...

TrialnError commented on 2018-08-17 00:00 (UTC)

Did not forget about updating the PKGBUILD. But there are currently issues with some components, which causes failure in the build process. Need to identify those. And not really able to use system llvm isn't helping in the process

TrialnError commented on 2018-08-01 19:47 (UTC)

Thanks for the work. Will take a look at it. Although I can already tell, I won't include the removal of Make.user

alyst commented on 2018-07-25 19:52 (UTC)

I've updated the PKGBUILD to 0.7-beta2. It's in https://github.com/alyst/aur-julia-git, julia07 branch. @TrialnError Feel free to pick up the changes.

TrialnError commented on 2018-02-23 19:29 (UTC)

I followed the bug for the julia package from the repo where they discussed the llvm situation. I assumed, reading those comments, that the situation isn't that "dire" if building directly from master. But well. Apparently not. Will change the build options

robsmith11 commented on 2018-02-23 13:22 (UTC)

I got it to build by changing it to use the bundled LLVM and libm.

robsmith11 commented on 2018-02-22 12:19 (UTC)

Has anyone built this recently?

First I ran into https://github.com/JuliaLang/julia/issues/23615 which was easily solved.

But now I'm getting more errors:

    LINK usr/bin/julia
/tmp/julia-git/src/julia/usr/lib/libjulia.so: undefined reference to `llvm::CloneModule(llvm::Module const*, llvm::ValueMap<llvm::Value const*, llv
m::WeakVH, llvm::ValueMapConfig<llvm::Value const*, llvm::sys::SmartMutex<false> > >&)'
/tmp/julia-git/src/julia/usr/lib/libjulia.so: undefined reference to `llvm::APInt::EqualSlowCase(unsigned long) const'
/tmp/julia-git/src/julia/usr/lib/libjulia.so: undefined reference to `llvm::AttributeSet::addAttribute(llvm::LLVMContext&, unsigned int, llvm::Stri
ngRef, llvm::StringRef) const'
/tmp/julia-git/src/julia/usr/lib/libjulia.so: undefined reference to `llvm::Value::stripInBoundsOffsets()'
/tmp/julia-git/src/julia/usr/lib/libjulia.so: undefined reference to `llvm::AttributeSet::getFnAttributes() const'
/tmp/julia-git/src/julia/usr/lib/libjulia.so: undefined reference to `vtable for llvm::GetElementPtrInst'
/tmp/julia-git/src/julia/usr/lib/libjulia.so: undefined reference to `llvm::User::anchor()'
/tmp/julia-git/src/julia/usr/lib/libjulia.so: undefined reference to `llvm::Function::getReturnType() const'
/tmp/julia-git/src/julia/usr/lib/libjulia.so: undefined reference to `llvm::APInt::shl(llvm::APInt const&) const'
/tmp/julia-git/src/julia/usr/lib/libjulia.so: undefined reference to `llvm::APFloat::IEEEdouble'
/tmp/julia-git/src/julia/usr/lib/libjulia.so: undefined reference to `llvm::APInt::operator+(llvm::APInt const&) const'
/tmp/julia-git/src/julia/usr/lib/libjulia.so: undefined reference to `llvm::TargetRecip::TargetRecip()'
/tmp/julia-git/src/julia/usr/lib/libjulia.so: undefined reference to `llvm::AttributeSet::getNumSlots() const'
/tmp/julia-git/src/julia/usr/lib/libjulia.so: undefined reference to `vtable for llvm::ICmpInst'
...

smldis commented on 2017-03-01 22:57 (UTC)

Ok I missed that, I solved the problem with this patch to Cxx.jl (Maybe it is not necessary anymore if it's working for you): ``` diff --git a/deps/BuildBootstrap.Makefile b/deps/BuildBootstrap.Makefile index 2d1731c..27e8661 100644 --- a/deps/BuildBootstrap.Makefile +++ b/deps/BuildBootstrap.Makefile @@ -158,7 +158,7 @@ LLVM_LIB_NAME := LLVM-$(CXX_LLVM_VER) endif LDFLAGS += -l$(LLVM_LIB_NAME) -LIB_DEPENDENCY += $(LIBDIR)/lib$(LLVM_LIB_NAME).$(SHLIB_EXT) +LIB_DEPENDENCY += /usr/lib/libLLVM-3.9.so #$(LIBDIR)/lib$(LLVM_LIB_NAME).$(SHLIB_EXT) usr/lib: @mkdir -p $(CURDIR)/usr/lib/ ```

TrialnError commented on 2017-02-22 23:41 (UTC)

Cannot replicate the issue smldis. Maybe a temporary problem in the build process. And as a hint for future contributions. Localized output can be blocker. To make life easier either translate non-english stuff to english, or use LANG=C or similar in front of the command to set the language for the actual process/programm :)

smldis commented on 2017-02-22 21:09 (UTC)

Any hints on what's wrong with the Cxx.jl build? The output is: ` Pkg.build("Cxx") INFO: Building Cxx writing path.jl file Tuning for julia installation at /usr/bin with sources possibly at /usr/bin/../.. INFO: Building julia binary build mkdir -p src/clang-3.9.1 mkdir -p src/llvm-3.9.1 make: *** Nessuna regola per generare l'obiettivo "/usr/bin/../lib/julia/libLLVM.so", necessario per "build/bootstrap.o". Arresto. make: *** Attesa per i processi non terminati.... tar -C src/clang-3.9.1 --strip-components=1 -xf src/cfe-3.9.1.src.tar.xz tar -C src/llvm-3.9.1 --strip-components=1 -xf src/llvm-3.9.1.src.tar.xz =======================================================================[ ERROR: Cxx ]======================================================================= LoadError: failed process: Process(`make -j2 -f BuildBootstrap.Makefile BASE_JULIA_BIN=/usr/bin BASE_JULIA_SRC=/usr/bin/../..`, ProcessExited(2)) [2] while loading /home/smldis/.julia/v0.6/Cxx/deps/build.jl, in expression starting on line 54 ============================================================================================================================================================ ======================================================================[ BUILD ERRORS ]====================================================================== WARNING: Cxx had build errors. - packages with build errors remain installed in /home/smldis/.julia/v0.6 - build the package(s) and all dependencies with `Pkg.build("Cxx")` - build a single package by running its `deps/build.jl` script ============================================================================================================================================================ `

TrialnError commented on 2017-01-12 20:54 (UTC)

Thanks for the note ajdunlap. And I was still waiting for that package to get orphaned. I filed my request, it got deleted (whatever it caused, because there is no report), the request was rejected, but I didn't get notified. Splendid

ajdunlap commented on 2017-01-12 17:44 (UTC)

The package currently depends on "openlibm" which is a non-existent package.

Deathaluz commented on 2016-08-10 23:17 (UTC) (edited on 2016-08-10 23:18 (UTC) by Deathaluz)

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 (UTC)

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 (UTC)

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 (UTC)

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 (UTC)

==> 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 (UTC)

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 (UTC) (edited on 2016-04-06 06:19 (UTC) by SideburnEtic)

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 (UTC)

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 (UTC) (edited on 2015-11-08 13:09 (UTC) by TrialnError)

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 (UTC)

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 (UTC)

@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 (UTC)

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 (UTC)

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 (UTC)

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 (UTC)

@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

yuyichao commented on 2015-06-02 13:44 (UTC)

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 (UTC)

@big_gie You need openblas to get the test pass.

yuyichao commented on 2015-06-02 13:39 (UTC)

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

TrialnError commented on 2015-05-28 01:50 (UTC)

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 (UTC)

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

big_gie commented on 2015-03-17 15:29 (UTC)

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 (UTC)

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 (UTC)

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 (UTC)

@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 (UTC)

python2-sphinx is needed as build-dependency.

myles commented on 2015-02-18 13:06 (UTC)

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 (UTC)

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 (UTC)

@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

Snow commented on 2015-01-31 03:13 (UTC)

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 (UTC)

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

alyst commented on 2014-12-17 09:09 (UTC)

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 (UTC)

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 (UTC)

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 (UTC)

@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

haawda commented on 2014-10-25 15:38 (UTC)

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

TrialnError commented on 2014-09-24 09:16 (UTC)

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 (UTC)

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

PythonNut commented on 2014-09-22 00:58 (UTC)

This fails to build unless "clang" is installed. (Manually building from source works fine without clang) Is clang a dependency?

TrialnError commented on 2014-09-16 12:28 (UTC)

@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 (UTC)

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 (UTC)

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 (UTC)

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 (UTC)

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 (UTC)

@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 (UTC)

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 (UTC)

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 (UTC)

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 (UTC)

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 (UTC)

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

devmotion commented on 2014-03-14 04:41 (UTC)

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

DiegoAscanio commented on 2014-03-13 03:03 (UTC)

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 (UTC)

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 (UTC)

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!

vchuravy commented on 2014-03-02 02:30 (UTC)

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

vchuravy commented on 2014-03-01 15:45 (UTC)

Build breaks with readline = 6.3 https://github.com/JuliaLang/julia/issues/6000

TrialnError commented on 2014-02-09 16:01 (UTC)

@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 (UTC)

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

alyst commented on 2014-02-08 15:26 (UTC)

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 (UTC)

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 (UTC)

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 (UTC)

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 (UTC)

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 (UTC)

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

csousa commented on 2013-12-27 16:48 (UTC)

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

csousa commented on 2013-12-27 16:19 (UTC)

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 (UTC)

Any fix to this issue?

LowGravitas commented on 2013-12-25 19:39 (UTC)

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 (UTC)

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 (UTC)

Thanks videan42, your patch worked for me.

videan42 commented on 2013-12-21 18:29 (UTC)

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 (UTC)

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 (UTC)

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

k8n commented on 2013-12-01 00:02 (UTC)

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

TrialnError commented on 2013-11-27 18:58 (UTC)

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 (UTC)

@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

mokasin commented on 2013-11-25 21:26 (UTC)

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 (UTC)

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 (UTC)

@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 (UTC)

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 (UTC)

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 (UTC)

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 (UTC)

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.

snowball commented on 2013-07-04 06:06 (UTC)

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

commented on 2013-07-03 18:40 (UTC)

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.

commented on 2013-07-03 16:43 (UTC)

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 (UTC)

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

fhs commented on 2013-07-01 18:04 (UTC)

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 (UTC)

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 (UTC)

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 (UTC)

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 (UTC)

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

commented on 2013-06-13 15:01 (UTC)

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 (UTC)

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.

commented on 2013-06-08 10:36 (UTC)

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 (UTC)

@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 (UTC)

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 (UTC)

@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 (UTC)

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 (UTC)

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 (UTC)

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 (UTC)

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 (UTC)

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 (UTC)

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 14:30 (UTC)

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 (UTC)

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:16 (UTC)

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 (UTC)

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 (UTC)

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 (UTC)

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 (UTC)

@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 (UTC)

@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 (UTC)

@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 (UTC)

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 (UTC)

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

burntsushi commented on 2013-03-07 02:38 (UTC)

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 (UTC)

Merged pull reqeust by github user Narrat.

commented on 2013-01-22 14:58 (UTC)

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

commented on 2012-12-07 05:46 (UTC)

This is fantastic. Thank you!

TrialnError commented on 2012-11-28 17:16 (UTC)

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

commented on 2012-11-27 23:18 (UTC)

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 (UTC)

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 (UTC)

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 (UTC)

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 (UTC)

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 (UTC)

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 (UTC)

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 (UTC)

/usr/lib/libarpack.so already exists in the filesystem add conflict package its arpack thanks

mihi commented on 2012-09-23 20:56 (UTC)

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

mihi commented on 2012-09-10 07:08 (UTC)

@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 (UTC)

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 (UTC)

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

mihi commented on 2012-07-16 14:48 (UTC)

@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 (UTC)

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 (UTC)

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

commented on 2012-07-13 14:37 (UTC)

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 (UTC)

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

commented on 2012-07-10 19:48 (UTC)

Missing FFTW library dependency. Using 'pacman -S fftw' if it happens.

mihi commented on 2012-05-31 10:40 (UTC)

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

TrialnError commented on 2012-05-31 10:02 (UTC)

@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.

commented on 2012-05-30 18:42 (UTC)

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?

commented on 2012-05-30 18:35 (UTC)

@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 (UTC)

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 (UTC)

@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)

commented on 2012-05-28 00:20 (UTC)

***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.

commented on 2012-05-28 00:19 (UTC)

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.

commented on 2012-05-27 21:11 (UTC)

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 (UTC)

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 (UTC)

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 (UTC)

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 (UTC)

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

mihi commented on 2012-03-11 14:46 (UTC)

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 (UTC)

Reverted back to using OpenBLAS and LAPACK provided by julia.

mihi commented on 2012-03-11 12:42 (UTC)

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 (UTC)

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 03:31 (UTC)

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 (UTC)

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

commented on 2012-03-03 02:00 (UTC)

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

mihi commented on 2012-02-28 21:28 (UTC)

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

d1t2 commented on 2012-02-28 20:59 (UTC)

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

mihi commented on 2012-02-22 22:13 (UTC)

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

commented on 2012-02-22 21:15 (UTC)

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.

Arch Linux User Repository

Search Criteria

Package Details: julia-git 1.8.0.DEV.r51125.g1db8b8f1607-1

Package Actions

Dependencies (18)

Required by (20)

Sources (3)

Latest Comments

Brettmahar commented on 2021-07-15 23:03 (UTC)

Volker_Weissmann commented on 2021-06-08 23:47 (UTC)

gustaphe commented on 2021-06-08 06:28 (UTC)

sh4kesbeer commented on 2020-12-31 09:04 (UTC)

Volker_Weissmann commented on 2020-12-25 21:15 (UTC)

PedroHLC commented on 2020-10-22 13:42 (UTC)

TrialnError commented on 2020-06-22 19:39 (UTC)

fusion809 commented on 2020-06-21 14:27 (UTC)

fusion809 commented on 2020-06-21 14:25 (UTC)

dlin commented on 2020-03-20 02:02 (UTC)

TrialnError commented on 2019-05-22 22:01 (UTC)

fusion809 commented on 2018-12-19 17:00 (UTC) (edited on 2018-12-19 17:00 (UTC) by fusion809)

TrialnError commented on 2018-08-17 00:00 (UTC)

TrialnError commented on 2018-08-01 19:47 (UTC)

alyst commented on 2018-07-25 19:52 (UTC)

TrialnError commented on 2018-02-23 19:29 (UTC)

robsmith11 commented on 2018-02-23 13:22 (UTC)

robsmith11 commented on 2018-02-22 12:19 (UTC)

smldis commented on 2017-03-01 22:57 (UTC)

TrialnError commented on 2017-02-22 23:41 (UTC)

smldis commented on 2017-02-22 21:09 (UTC)

TrialnError commented on 2017-01-12 20:54 (UTC)

ajdunlap commented on 2017-01-12 17:44 (UTC)

Deathaluz commented on 2016-08-10 23:17 (UTC) (edited on 2016-08-10 23:18 (UTC) by Deathaluz)

TrialnError commented on 2016-08-10 08:14 (UTC)

Deathaluz commented on 2016-08-10 03:57 (UTC)

TrialnError commented on 2016-06-26 17:42 (UTC)

haawda commented on 2016-06-24 20:28 (UTC)

TrialnError commented on 2016-04-16 12:25 (UTC)

SideburnEtic commented on 2016-04-06 06:13 (UTC) (edited on 2016-04-06 06:19 (UTC) by SideburnEtic)

TrialnError commented on 2015-11-08 14:05 (UTC)

TrialnError commented on 2015-11-08 13:08 (UTC) (edited on 2015-11-08 13:09 (UTC) by TrialnError)

gabor_bernat commented on 2015-11-08 08:32 (UTC)

TrialnError commented on 2015-09-20 20:08 (UTC)

TrialnError commented on 2015-09-20 19:36 (UTC)

TrialnError commented on 2015-09-20 18:28 (UTC)

haawda commented on 2015-09-20 16:38 (UTC)

TrialnError commented on 2015-06-03 17:54 (UTC)

yuyichao commented on 2015-06-02 13:44 (UTC)

yuyichao commented on 2015-06-02 13:39 (UTC)

yuyichao commented on 2015-06-02 13:39 (UTC)

TrialnError commented on 2015-05-28 01:50 (UTC)

TrialnError commented on 2015-04-14 23:04 (UTC)

big_gie commented on 2015-03-17 15:29 (UTC)

TrialnError commented on 2015-03-12 01:47 (UTC)

TrialnError commented on 2015-03-05 15:12 (UTC)

TrialnError commented on 2015-03-03 19:06 (UTC)

haawda commented on 2015-02-22 13:24 (UTC)

myles commented on 2015-02-18 13:06 (UTC)

TrialnError commented on 2015-02-02 12:09 (UTC)

TrialnError commented on 2015-02-02 11:56 (UTC)

Snow commented on 2015-01-31 03:13 (UTC)

TrialnError commented on 2014-12-23 11:12 (UTC)

alyst commented on 2014-12-17 09:09 (UTC)

TrialnError commented on 2014-11-21 22:46 (UTC)

sivapvarma commented on 2014-11-12 16:15 (UTC)

TrialnError commented on 2014-10-27 16:42 (UTC)

haawda commented on 2014-10-25 15:38 (UTC)

TrialnError commented on 2014-09-24 09:16 (UTC)

TrialnError commented on 2014-09-23 11:47 (UTC)

PythonNut commented on 2014-09-22 00:58 (UTC)

TrialnError commented on 2014-09-16 12:28 (UTC)

PythonNut commented on 2014-09-14 21:53 (UTC)

TrialnError commented on 2014-09-05 23:57 (UTC)

xyproto commented on 2014-08-24 21:07 (UTC)

TrialnError commented on 2014-07-11 23:19 (UTC)

csousa commented on 2014-05-05 23:18 (UTC)

pwl commented on 2014-05-05 14:40 (UTC)

csousa commented on 2014-04-10 17:55 (UTC)

TrialnError commented on 2014-04-08 05:57 (UTC)

alyst commented on 2014-04-06 13:19 (UTC)

JoiDegn commented on 2014-03-23 12:16 (UTC)