#50226: julia @0.4.2_1 fails building on 10.6.8 -------------------------+-------------------- Reporter: braumann@… | Owner: sean@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.3.4 Resolution: | Keywords: Port: julia | -------------------------+-------------------- Changes (by mf2k@…): * keywords: ssp => * owner: macports-tickets@… => sean@… * cc: sean@… (removed) -- Ticket URL: <https://trac.macports.org/ticket/50226#comment:1> MacPorts <https://www.macports.org/> Ports system for OS X

#50226: julia @0.4.2_1 fails building on 10.6.8 -------------------------+-------------------- Reporter: braumann@… | Owner: sean@… Type: defect | Status: closed Priority: Normal | Milestone: Component: ports | Version: 2.3.4 Resolution: wontfix | Keywords: Port: julia | -------------------------+-------------------- Comment (by braumann@…): 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. -- Ticket URL: <https://trac.macports.org/ticket/50226#comment:3> MacPorts <https://www.macports.org/> Ports system for OS X

#50226: julia @0.4.2_1 fails building on 10.6.8 -------------------------+-------------------- Reporter: braumann@… | Owner: sean@… Type: defect | Status: closed Priority: Normal | Milestone: Component: ports | Version: 2.3.4 Resolution: wontfix | Keywords: Port: julia | -------------------------+-------------------- Comment (by braumann@…): 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. -- Ticket URL: <https://trac.macports.org/ticket/50226#comment:5> MacPorts <https://www.macports.org/> Ports system for OS X