Run `fixup-libgfortran` at the `make` stage #29522

staticfloat · 2018-10-04T16:28:32Z

This as opposed to at the make binary-dist stage. This allows from-source Julia builds to have libgfortran, etc... sitting in julia's RPATH, which is important for from-source builds using BinaryBuilder versions of e.g. Arpack.jl to be able to link everything together using RPATH magic.

@andreasnoack this should fix your "this doesn't work if I just make && ./julia" problem.

This as opposed to at the `make binary-dist` stage. This allows from-source Julia builds to have `libgfortran`, etc... sitting in `julia`'s `RPATH`, which is important for from-source builds using BinaryBuilder versions of e.g. Arpack.jl to be able to link everything together using `RPATH` magic.

vtjnash

Can we make this optional? This seems like something we definitely don't want to be doing for actual local builds.

Keno · 2018-10-04T16:39:56Z

Can you explain why this is required? Wouldn't opening openblas pull an appropriate libgfortran into the process that Arpack should be able to find?

staticfloat · 2018-10-04T16:59:38Z

It would be enough if we opened libraries with RTLD_GLOBAL by default on all platforms, but we don’t. If that solution is preferred, we should do that instead. It’s required because libraries that are linked against libgfortran when libgfortran is hidden away in some gcc support directory can’t find it, despite Julia being able to find it because of deliberate (r)paths embedded within openblas. -E

…

On Fri, Oct 5, 2018 at 00:40 Keno Fischer ***@***.***> wrote: Can you explain why this is required? Wouldn't opening openblas pull an appropriate libgfortran into the process that Arpack should be able to find? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#29522 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAH_aFSLmFuOZsZkJIo-suWvW0VfMdOeks5uhjnhgaJpZM4XIeMZ> .

andreasnoack · 2018-10-08T07:36:19Z

Bump. If people don't like the solution here then please propose an alternative that will make make && ./julia work with binary dependencies which depend on libgfortran.

staticfloat · 2018-10-11T06:42:51Z

I see three solutions here:

Move libgfortran and co. into Julia's build libdir, so that it can be found through the RPATH. (That's what this PR does)
Change the default dlopen() on all platforms to include RTLD_GLOBAL.
Explicitly dlopen("libgfortran", RTLD_GLOBAL) within Julia somewhere before we try to load other dependent libraries.

I think the first choice is the best. What do you guys think?

vtjnash · 2018-10-11T16:23:56Z

OK. I think I understand better now. Per Keno's PR in 2016 (#17458 (comment)), this was not supposed to work ever (but accidentally was working in installed versions of Julia). But then we re-introduced that code-path in 2017 #21134 incidentally while thinking we were just doing code cleanup.

staticfloat · 2018-10-11T16:28:34Z

Because the lib/julia RPATH is within libjulia and because the dlopen() is initiating from within libjulia, that should be orthogonal though, right? Regardless of what julia has embedded within it, it's what is embedded within libjulia that matters, I would think.

Regardless, I don't think it matters one way or another. We want this behavior, and we need a way to ensure that it works from within the build tree.

staticfloat · 2018-10-18T09:16:49Z

I'm bumping this again, as we are still getting reports of things not working from users that build from source (hence merging this would help them) and that can't use Arpack.jl despite the effort we've put into GCC multiversioning and all that.

staticfloat · 2018-11-05T06:38:03Z

Bump; people are still running into this. Please suggest an alternative solution.

staticfloat · 2018-11-11T01:52:10Z

Please either let me merge this or suggest an alternative solution, I get a steady stream of complaints and bug reports about this.

Keno · 2018-11-11T21:34:26Z

Is this a problem on OS X also? I think OS X chains rpaths so if it's within libjulia's rpath we should be able to find it. In any case, I'd be ok with this if instead of copying it, we'd symlink. Longterm, our plan for dealing with libraries spread over the filesystem should be able to deal with this using a virtual "libgfortran" package.

staticfloat · 2018-11-12T09:06:44Z

Is this a problem on OS X also?

Yes, this is a problem on OS X. You can verify by building a from-source version of Julia on OSX with libgfortran.dylib within a non-default-search path, then running pkg> build Arpack, which fails. On my system, libgfortran.5.dylib is located at /usr/local/opt/gcc/lib/gcc/8/libgfortran.5.dylib, as it's installed through Homebrew.

That is not within libjulia's RPATH; libopenblas64_.dylib has a direct path to that location embedded within it; we don't add system directories to the RPATH of our libraries by default; (I just checked on Linux and OSX) so OSX finds things due to full paths being embedded, Linux finds things because they tend to be on the system path already, and FreeBSD does this early copying already.

I'd be ok with this if instead of copying it, we'd symlink.

I don't see why copying is a problem. If you're worried about staleness in the face of a compiler upgrade, we have many other things that would be stale in that event, and so a make cleanall would already be required. Symlinks would save some disk space, but I'm not convinced the extra complexity required to collapse those symlinks at make binary-dist time is worth it.

Longterm, our plan for dealing with libraries spread over the filesystem should be able to deal with this using a virtual "libgfortran" package.

True, but that's still a little ways off, and I don't see any real downsides to this change.

StefanKarpinski · 2018-11-15T19:30:11Z

Triage defers to Elliot "The Linker" Saba on this one.

vtjnash · 2018-11-15T19:36:32Z

and FreeBSD does this early copying already.

That's present to work around a configuration issue with their gcc compiler. I think the idea is that once the real fix makes its way upstream, we can drop that hack?

StefanKarpinski · 2018-11-15T20:02:22Z

@staticfloat: please do go ahead with this.

staticfloat · 2018-11-17T16:06:37Z

Thanks for the vote of confidence, Triage. We'll be able to remove this once JuliaLang/Pkg.jl#841 is brought to fruition.

Keno · 2018-11-20T11:33:20Z

We now see

PATH=/usr/local/texlive/2018/bin/x86_64-linux:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/home/keno/julia/usr/tools /home/keno/julia/contrib/fixup-libgfortran.sh --verbose /home/keno/julia/usr/lib
Discovered traces of libgfortran within /home/keno/julia/usr/lib
Got SONAMES of libgcc_s.so.1 libgfortran.so.4 libquadmath.so.0
changing linkage of /home/keno/julia/usr/lib/libopenblas64_.so to libgcc_s.so.1
changing linkage of /home/keno/julia/usr/lib/libopenblas64_.so to libgfortran.so.4
changing linkage of /home/keno/julia/usr/lib/libopenblas64_.so to libquadmath.so.0
changing linkage of /home/keno/julia/usr/lib/libopenblas64_.so.0 to libgcc_s.so.1
changing linkage of /home/keno/julia/usr/lib/libopenblas64_.so.0 to libgfortran.so.4
changing linkage of /home/keno/julia/usr/lib/libopenblas64_.so.0 to libquadmath.so.0
changing linkage of /home/keno/julia/usr/lib/libcholmod.so to libgcc_s.so.1
changing linkage of /home/keno/julia/usr/lib/libcholmod.so to libgfortran.so.4
changing linkage of /home/keno/julia/usr/lib/libcholmod.so to libquadmath.so.0
changing linkage of /home/keno/julia/usr/lib/liblapack* to libgcc_s.so.1
  /home/keno/julia/usr/lib/liblapack* doesn't exist, skipping
changing linkage of /home/keno/julia/usr/lib/liblapack* to libgfortran.so.4
  /home/keno/julia/usr/lib/liblapack* doesn't exist, skipping
changing linkage of /home/keno/julia/usr/lib/liblapack* to libquadmath.so.0
  /home/keno/julia/usr/lib/liblapack* doesn't exist, skipping
changing linkage of /home/keno/julia/usr/lib/libgcc_s.so.1 to libgcc_s.so.1
changing linkage of /home/keno/julia/usr/lib/libgcc_s.so.1 to libgfortran.so.4
changing linkage of /home/keno/julia/usr/lib/libgcc_s.so.1 to libquadmath.so.0
changing linkage of /home/keno/julia/usr/lib/libgfortran.so.4 to libgcc_s.so.1
changing linkage of /home/keno/julia/usr/lib/libgfortran.so.4 to libgfortran.so.4
changing linkage of /home/keno/julia/usr/lib/libgfortran.so.4 to libquadmath.so.0
changing linkage of /home/keno/julia/usr/lib/libquadmath.so.0 to libgcc_s.so.1
changing linkage of /home/keno/julia/usr/lib/libquadmath.so.0 to libgfortran.so.4
changing linkage of /home/keno/julia/usr/lib/libquadmath.so.0 to libquadmath.so.0

on every make. Can we avoid that?

This as opposed to at the `make binary-dist` stage. This allows from-source Julia builds to have `libgfortran`, etc... sitting in `julia`'s `RPATH`, which is important for from-source builds using BinaryBuilder versions of e.g. Arpack.jl to be able to link everything together using `RPATH` magic.

staticfloat · 2018-11-23T23:18:24Z

#30135

andreasnoack · 2018-12-04T07:36:41Z

Can this be backported?

staticfloat · 2018-12-04T15:51:35Z

Sure, I just opened a PR.

vtjnash requested changes Oct 4, 2018

View reviewed changes

ararslan added the building Build system, or building Julia or its dependencies label Oct 9, 2018

staticfloat mentioned this pull request Oct 18, 2018

Installation error when Julia is built from source JuliaLinearAlgebra/Arpack.jl#5

Closed

andreasnoack added the triage This should be discussed on a triage call label Nov 7, 2018

StefanKarpinski removed the triage This should be discussed on a triage call label Nov 15, 2018

StefanKarpinski added this to the 1.1 milestone Nov 15, 2018

staticfloat merged commit 90e3155 into master Nov 17, 2018

martinholters deleted the sf/the_ultimate_gfortran_conspiracy branch November 17, 2018 19:40

staticfloat mentioned this pull request Dec 4, 2018

Backport libgfortran Makefile changes (#29522 and #30135) to 1.0 #30262

Merged

omus mentioned this pull request May 21, 2019

Error with fixup-libgfortran.sh when spaces in PATH #32100

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Run `fixup-libgfortran` at the `make` stage #29522

Run `fixup-libgfortran` at the `make` stage #29522

staticfloat commented Oct 4, 2018 •

edited

Loading

vtjnash left a comment

Keno commented Oct 4, 2018

staticfloat commented Oct 4, 2018 via email

andreasnoack commented Oct 8, 2018

staticfloat commented Oct 11, 2018

vtjnash commented Oct 11, 2018

staticfloat commented Oct 11, 2018 •

edited

Loading

staticfloat commented Oct 18, 2018

staticfloat commented Nov 5, 2018

staticfloat commented Nov 11, 2018

Keno commented Nov 11, 2018

staticfloat commented Nov 12, 2018

StefanKarpinski commented Nov 15, 2018

vtjnash commented Nov 15, 2018

StefanKarpinski commented Nov 15, 2018

staticfloat commented Nov 17, 2018

Keno commented Nov 20, 2018

staticfloat commented Nov 23, 2018

andreasnoack commented Dec 4, 2018

staticfloat commented Dec 4, 2018

Run fixup-libgfortran at the make stage #29522

Run fixup-libgfortran at the make stage #29522

Conversation

staticfloat commented Oct 4, 2018 • edited Loading

vtjnash left a comment

Choose a reason for hiding this comment

Keno commented Oct 4, 2018

staticfloat commented Oct 4, 2018 via email

andreasnoack commented Oct 8, 2018

staticfloat commented Oct 11, 2018

vtjnash commented Oct 11, 2018

staticfloat commented Oct 11, 2018 • edited Loading

staticfloat commented Oct 18, 2018

staticfloat commented Nov 5, 2018

staticfloat commented Nov 11, 2018

Keno commented Nov 11, 2018

staticfloat commented Nov 12, 2018

StefanKarpinski commented Nov 15, 2018

vtjnash commented Nov 15, 2018

StefanKarpinski commented Nov 15, 2018

staticfloat commented Nov 17, 2018

Keno commented Nov 20, 2018

staticfloat commented Nov 23, 2018

andreasnoack commented Dec 4, 2018

staticfloat commented Dec 4, 2018

Run `fixup-libgfortran` at the `make` stage #29522

Run `fixup-libgfortran` at the `make` stage #29522

staticfloat commented Oct 4, 2018 •

edited

Loading

staticfloat commented Oct 11, 2018 •

edited

Loading