julia @0.4.2_1 fails building on 10.6.8

[udbraumann]

As julia @0.4.2_1 now uses MacPorts' libgit2 and OpenBLAS, I was curious if it now builds on 10.6.8. However, during building the flisp component, I run into this problem:

...
:info:destroot make[3]: Entering directory `/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_julia/julia/work/julia-0.4.2/src/flisp'
:info:destroot     CC src/flisp/flisp.dbg.obj
:info:destroot     CC src/flisp/builtins.dbg.obj
:info:destroot     CC src/flisp/string.dbg.obj
:info:destroot     CC src/flisp/equalhash.dbg.obj
:info:destroot     CC src/flisp/table.dbg.obj
:info:destroot     CC src/flisp/iostream.dbg.obj
:info:destroot     CC src/flisp/julia_extensions.dbg.obj
:info:destroot     LINK src/flisp/libflisp-debug.a
:info:destroot     CC src/flisp/flmain.dbg.obj
:info:destroot     LINK src/flisp/flisp-debug
:info:destroot ld: library not found for -lssp
:info:destroot collect2: ld returned 1 exit status
...

I have no idea how to provide this stack smashing protection (ssp) library.

[seanfarley (Sean Farley)]

You'll have to a julia dev to look at this because I have no idea what's wrong. It seems that julia only supports 10.7+. If you're able to patch this to work I'll take a look at it but otherwise will mark this as wontfix since upstream would need to add the support for 10.6.8.

[udbraumann]

Well, may I ask if what compiler you are expecting to be used for building julia? gcc5?

For me I had to specify this using the configure.compiler switch in the command line.

Then I got beyond the point where it stopped above. Since in debuginfo.cpp the function strndup is being used (was not provided in 10.6.8) I put an own definition of strndup (as is being done in many ports via patches) into debuginfo.cpp.

The problem I could not solve happened later, during linking libjulia-debug.dylib. Lots of LLVM related symbols could not be resolved. This is strange, as USE_SYSTEM_LLVM=1 and LLVM_CONFIG=llvm-config-mp-3.7 should guide the linking process to the correct libraries. However, I suspect, nevertheless it still tries to use Xcode-related libraries (which should be no problem with a modern Xcode), but this is not fully clear, as no paths are being printed in the log file.

Thanks for comments.

[seanfarley (Sean Farley)]

I would probably avoid gcc5 since julia is built on top of LLVM and compiles down to IR. Their webpage only list ​10.7+. It appears you are on your way to patching julia to work on 10.6, which seems to be a lesson in futility since the community of julia relies on modern features of LLVM but, hey, that's your discretion. I have no way to test 10.6 so I won't be of much help. Besides, you know, the usual advice of upgrading to newer OS to save yourself the headache.

[udbraumann]

Well, but why gcc5 is listed under build dependencies?

$ sudo port info --pretty --fullname --depends julia
Full Name: julia @0.4.2+gcc5
Build Dependencies:   gcc5
Library Dependencies: llvm-3.7, curl, pcre2, gmp, mpfr, SuiteSparse, fftw-3,
                      fftw-3-single, ncurses, arpack, libgit2, OpenBLAS, libgcc

In other words, are you using clang for building julia? And if yes, what version? Would you recommend to use clang-3.7?

At the moment I do not fully understand what the selection of the compiler for building julia has to do with julia's way to compile at runtime. Could you please explain what the +gcc5 variant means? And how julia it interacting with llvm-3.7?

As I wrote earlier, when specifying e.g. configure.compiler=macports-gcc-5 during configuration of julia it searches an non-existing archiver named gcc-ar. However, the correct name resolution would be gcc-ar-mp-5, as the compiler is named gcc-mp-5. Also, when specifying configure.compiler=macports-clang-3.7 it searches clang-ar, which also is not existing, instead the corresponding archiver's name is llvm-ar-mp-3.7. This problem occurs since the name of the archiver is being deduced from the compiler name. This is unusual in MacPorts, I think, as /opt/local/bin/ar should do anyway, and since /opt/local/bin should occur before /usr/bin in the $PATH variable, there seems to be no reason why not simply calling ar instead of deducing the name from the compiler name.

[seanfarley (Sean Farley)]

All good questions.

julia is built on top of LLVM and compiles down to ​IR. Using clang for C is the only thing that makes sense to me. The variants of gccX for julia are just for the fortran parts.

I somehow missed the configure.compiler specified on the command-line before. Simply put, I wrote the mpi and compiler portgroups to avoid having to use configure.compiler. That way you know exactly which compiler was used by looking at the variant. My suggestion would be to nuke everything built with your custom configure.compiler and just use the variants to select the compiler.