make dist result and libgfortran library

[crayxt]

This is more like question than issue.

I tried to run Julia built with make dist, on 64-bit Centos 6.5 LiveCD. It turns out that Julia wasn't able to load libopenblas.so, which itself depends on libgfortran, which is not present on that LiveCD. I expected the make dist result to be self-sufficient (ready to use on any average Linux system).

Is the only solution here to have libgfortran installed on target Linux systems? No way to ship this library together with Julia binary build?

[staticfloat]

We run into this problem on MacOS as well. We have a script called fixup-libgfortran (which, incidentally, is the first google result for the search "fixup-libgfortran") that does basically what you want. Note that it uses OSX-specific commands to find libgfortran, (based on what shared libraries arpack and friends depend on) but the basic operation should be the same for Linux.

[crayxt]

@staticfloat Thanks for the link. I suppose it must be rewritten using patchelf. I'll give it a try!

[ViralBShah]

We have tried to link libgfortran statically in the past but the compiler does not allow static linking of libquadmath. If that has changed with recent gfortran, it would make things so much easier.

[tkelman]

I've done static linking of gfortran and quadmath on much smaller projects, it requires spelling out the full path to the static .a library of each.

[tkelman]

Statically linking libgfortran doesn't make too much sense when we've got multiple independent libraries that all depend on it. Should be easy enough to make fixup-libgfortran.sh do the right thing on Linux too, by replacing dylib with a uname-dependent $SHLIB_EXT, replacing otool -L with ldd and cut -d' ' -f1 with cut -d' ' -f3 on Linux (or anything non-Darwin? we handle the gfortran dll's elsewhere for mingw, but I'm assuming ldd works the same way on FreeBSD etc?). And don't bother with the install_name_tool lines on non-Darwin either.

[staticfloat]

Yeah, that shouldn't be too hard. I'll take a crack at it tonight.
-E

On Sun, Sep 21, 2014 at 7:09 PM, Tony Kelman notifications@github.com
wrote:

Statically linking libgfortran doesn't make too much sense when we've got
multiple independent libraries that all depend on it. Should be easy enough
to make fixup-libgfortran.sh do the right thing on Linux too, by
replacing dylib with a uname-dependent $SHLIB_EXT, replacing otool -L
with ldd and cut -d' ' -f1 with cut -d' ' -f3 on Linux (or anything
non-Darwin? we handle the gfortran dll's elsewhere for mingw, but I'm
assuming ldd works the same way on FreeBSD etc?). And don't bother with
the install_name_tool lines on non-Darwin either.

—
Reply to this email directly or view it on GitHub
#8397 (comment).

[crayxt]

I suppose from three libraries listed in fixup-libgfortran script only libgfortran.so is required to be added to archive on Linux? I see that second library libgcc_s.so.1 already present on my Linux boxes.
What about libquadmath - what depends on it?

[tkelman]

libgfortran depends on libquadmath, at least in relatively recent versions of gcc

[staticfloat]

We should also ship libgcc_s.so regardless, as these libraries should move in lockstep with eachother.

[ViralBShah]

For that we really should just build with -static-libgcc

[staticfloat]

@ViralBShah I was just coming to that conclusion. We may want to experiment with doing that by default on Linux for make dist.

[tkelman]

And -static-libstdc++ too? I've gone down this path before. It sort-of works (only with GCC 4.7.3 or newer though) if your delivered binary is a single shared library. It's not a very good idea when you have a whole collection of interdependent libraries as in Julia. Also you need to link to versions of libstdc++.a, libgfortran.a, etc that were compiled --with-pic if you want to statically link them into a shared library. I've never seen a distribution do that by default when compiling GCC. Debian does have a separate libstdc++6-4.8-pic package that you can use with some fiddling, but no such equivalent is pre-built for fortran.

[crayxt]

Ok, thanks @staticfloat for handling this, nice work! Now I will close this ticket.