Library libgfortran not found after installing gfortran

[rwest]

After installing gfortran, I have the following libraries:

/usr/local/Cellar/gfortran/4.2.4-5666.3/lib/gcc/i686-apple-darwin11/4.2.1/libgfortran.a
/usr/local/Cellar/gfortran/4.2.4-5666.3/lib/gcc/i686-apple-darwin11/4.2.1/libgfortranbegin.a
/usr/local/Cellar/gfortran/4.2.4-5666.3/lib/gcc/i686-apple-darwin11/4.2.1/libgfortranbegin.la
/usr/local/Cellar/gfortran/4.2.4-5666.3/lib/gcc/i686-apple-darwin11/4.2.1/x86_64/libgfortran.a
/usr/local/Cellar/gfortran/4.2.4-5666.3/lib/gcc/i686-apple-darwin11/4.2.1/x86_64/libgfortranbegin.a
/usr/local/Cellar/gfortran/4.2.4-5666.3/lib/gcc/i686-apple-darwin11/4.2.1/x86_64/libgfortranbegin.la

And I have the link /usr/local/lib/gcc -> ../Cellar/gfortran/4.2.4-5666.3/lib/gcc

so that they can be found at

/usr/local/lib/gcc/i686-apple-darwin11/4.2.1/libgfortran.a
/usr/local/lib/gcc/i686-apple-darwin11/4.2.1/libgfortranbegin.a
/usr/local/lib/gcc/i686-apple-darwin11/4.2.1/libgfortranbegin.la
/usr/local/lib/gcc/i686-apple-darwin11/4.2.1/x86_64/libgfortran.a
/usr/local/lib/gcc/i686-apple-darwin11/4.2.1/x86_64/libgfortranbegin.a
/usr/local/lib/gcc/i686-apple-darwin11/4.2.1/x86_64/libgfortranbegin.la

However, when I try to build things with, for example, /usr/bin/llvm-gcc -bundle -undefined dynamic_lookup ... -lgfortran ... I get:

ld: library not found for -lgfortran
collect2: ld returned 1 exit status
error: command '/usr/bin/llvm-gcc' failed with exit status 1

It is failing to find any libgfortan.a.

Various workarounds are described by other people who have had this problem, for example:

https://github.com/zk00006/OpenTLD/wiki/InstallingOctave-Mac

Currently Mac homebrew won't install libgfortran to your default library path (even with brew link). So we also must create links to libgfortran in /usr/local/lib.

http://eris.liralab.it/wiki/Homebrew

following links I created after installing gfortran by "brew install gfortran".
ln -s /usr/local/Cellar/gfortran/4.2.4-5664/lib/gcc/i686-apple-darwin10/4.2.1/x86_64/libgfortran.a /usr/local/lib/libgfortran.a
ln -s /usr/local/Cellar/gfortran/4.2.4-5664/lib/gcc/i686-apple-darwin10/4.2.1/x86_64/libgfortranbegin.a /usr/local/lib/libgfortranbegin.a
ln -s /usr/local/Cellar/gfortran/4.2.4-5664/lib/gcc/i686-apple-darwin10/4.2.1/x86_64/libgfortranbegin.la /usr/local/lib/libgfortranbegin.la

http://obspy.org/wiki/InstallingDependenciesMac

obspy.taup is linked against libgfortran.a and for some reason it is not found. You will have to search for libgfortran.a on your system and add the corresponding path to the LIBRARY_PATH variable to be able to link anything against the fortran library using another compiler. I am not sure how this can be avoided (See ticket #262 for more information). Change the path according to your system (it will be something similiar if you installed gfortran using brew):
export LIBRARY_PATH=$LIBRARY_PATH:/usr/local/Cellar/gfortran/4.2.4-5666.3/lib/gcc/i686-apple-darwin11/4.2.1/x86_64/

What is the best way to solve this?

[Sharpie]

Please provide the output of brew doctor and brew --config.

[rwest]

$ brew doctor
Your system is raring to brew.

$ brew --config
HOMEBREW_VERSION: 0.8
HEAD: 290c81f5f468672281aafa7db3f08395d92a716e
HOMEBREW_PREFIX: /usr/local
HOMEBREW_CELLAR: /usr/local/Cellar
HOMEBREW_REPOSITORY: /usr/local
HOMEBREW_LIBRARY_PATH: /usr/local/Library/Homebrew
Hardware: quad-core 64-bit sandybridge
OS X: 10.7.2
Kernel Architecture: x86_64
Ruby: 1.8.7-249
/usr/bin/ruby => /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/bin/ruby
Xcode: 4.1
GCC-4.0: N/A 
GCC-4.2: build 5666 
LLVM: build 2335 
MacPorts or Fink? false
X11 installed? true

[Sharpie]

Does the problem persist if you use GCC instead of LLVM-GCC:

/usr/bin/gcc-4.2 -bundle -undefined dynamic_lookup ... -lgfortran ...

[rwest]

Yes, it persists. (didn't mean to close the issue just now - I fell foul of some keyboard shortcut)

$ /usr/bin/gcc-4.2 -bundle -undefined dynamic_lookup -L/usr/local/Cellar/readline/6.2.1/lib build/temp.macosx-10.4-x86_64-2.7/pydas.o dassl/daux.o dassl/ddassl.o dassl/dlinpk.o -lgfortran -o build/lib.macosx-10.4-x86_64-2.7/pydas.so
ld: library not found for -lgfortran
collect2: ld returned 1 exit status

[Sharpie]

Hmm... have you upgraded XCode since installing GFortran?

[rwest]

Ummm, not sure.

$ brew info gfortran
gfortran 4.2.4-5666.3
http://r.research.att.com/tools/
/usr/local/Cellar/gfortran/4.2.4-5666.3 (15 files, 30M)

The XCode startup window says it is Version 4.1 (4B110), which I now realize is not the latest. I will try upgrading and see if that changes things.

[Sharpie]

Homebrew's GFortran won't work with XCode 4.2 since all non-LLVM compilers have been removed and GFortran is not an LLVM compiler.

[rwest]

Oh - so I would have been better off staying with Xcode 4.1?

[Sharpie]

Oh - so I would have been better off staying with Xcode 4.1?

Yeah, I wouldn't recommend upgrading to 4.2 unless you are building software for the Mac App Store or the iTunes Store.

[argoneus]

I've run into this issue as well. I'm compiling a C++ program which links to libgfortran during configure.

Should the brew for gfortran install a .dylib or .a in the homebrew lib directory? I have to manually pass the full path of the lib, i.e. /usr/local/homebrew/Cellar/gfortran/4.2.4-5666.3/lib/gcc/i686-apple-darwin/4.2.1/x86_64

I realize I could easily symlink it to /usr/local/homebrew/lib myself; it just seems like something the formula ought to do.

Thanks.

[Sharpie]

Should the brew for gfortran install a .dylib or .a in the homebrew lib directory?

The libraries are installed to the lib directory:

bash-3.2$ tree /usr/local/lib/gcc
/usr/local/lib/gcc
└── i686-apple-darwin11
    └── 4.2.1
        ├── finclude
        │   ├── omp_lib.f90
        │   ├── omp_lib.h
        │   ├── omp_lib.mod
        │   └── omp_lib_kinds.mod
        ├── libgfortran.a
        ├── libgfortranbegin.a
        ├── libgfortranbegin.la
        └── x86_64
            ├── libgfortran.a
            ├── libgfortranbegin.a
            └── libgfortranbegin.la

4 directories, 10 files

The directory is set up in a specific way so that compilers can locate the right libraries for the right architectures---which allows you to build universal binaries. The problem is, only gfortran knows to look in /usr/local/lib/gcc. gcc, g++ and the rest of the compilers from XCode are looking in /usr/lib/gcc because that is where their prefix is.

I think this problem can be fixed by setting the LIBRARY_PATH environment variable before you try to link against libgfortran using a compiler other than gfortran:

bash-3.2$ gcc --version
i686-apple-darwin11-llvm-gcc-4.2 (GCC) 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2335.15.00)
Copyright (C) 2007 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

bash-3.2$ gcc test.c -lgfortranbegin
ld: library not found for -lgfortranbegin
collect2: ld returned 1 exit status

bash-3.2$ export LIBRARY_PATH=/usr/local/lib/gcc
bash-3.2$ gcc test.c -lgfortranbegin

bash-3.2$ unset LIBRARY_PATH
bash-3.2$ gcc test.c -lgfortranbegin
ld: library not found for -lgfortranbegin
collect2: ld returned 1 exit status

[jacknagel]

Anything to do here? Caveats or something?

[Sharpie]

Yeah, a caveat that LIBRARY_PATH needs to be set if the user intends to use gcc instead of gfortran as the linker would probably suffice.

One unknown that needs to be tested is what clang will do in this situation.

[rwest]

I fear that clang may ignore the LIBRARY_PATH all together, but I haven't quite got to the bottom of the situation yet, so don't know what to suggest.

[samueljohn]

The stupid question, I have: Why does -L /usr/local/Cellar/gcc/4.7.2/gcc/lib not work here?

I should add a note in the caveats of the new gfortran formula, if that would solve the linking issues you had.

[Sharpie]

Why does -L/usr/local/Cellar/gcc/4.7.2/gcc/lib not work here?

I think it doesn't work because that lib folder has different subdirectories for each architecture. So one would need to include a different path depending on the -arch flags being used and things would be very confusing if multiple -arch flags were in play.

[2bits]

@rwest Homebrew updated their gfortran to version 4.7 yesterday. Please brew update and try again. Let us know how it goes.

[samueljohn]

I don't think my new gfortran formula helps here. It's basically still the same issue. Linking with gfortran works but other compiler don't know about the location of the gfortran libs.

@rwest any progress or ideas?

[samueljohn]

@Sharpie -L $(gfortran --print-file-name libgfortran.dylib) ?

[Sharpie]

Not all versions of GCC behave like that. For example:

➜  ~  /usr/local/Cellar/gfortran/4.2.4-5666.3/bin/gfortran --print-file-name libgfortran.dylib
libgfortran.dylib

I'm still convinced that setting LIBRARY_PATH is absolutely the right solution if one is using GCC. This is because the compiler suite knows what to do if there are multiple architectures or a flag like -Bstatic was passed specifying that one doesn't want to link against the dynamic Fortran libs.

[Sharpie]

Also, --print-file-name returns the path to a file which is inappropriate since -L needs a path to a directory. So, for compilers which actually return the full path, it would have to be something even more hackish like:

-L"$(dirname `gfortran --print-file-name libgfortran.dylib`)"

[samueljohn]

Ok, it was just an idea out of the blue. Let's forget about it.

We should close this issue and perhaps add a caveat to the gfortran formula?

[samueljohn]

@Sharpie perhaps you can add a little caveat, so we can finally close this issue?

[mkhorton]

Just wanted to say that I'd be much obliged if someone could "fix" this. I'm not a programmer by trade or education, and just had to compile something for work and was having huge problems until I stumbled onto this thread. Thankfully, setting library_path worked fine, but the thought that there was something "wrong" with my homebrew installation hadn't even crossed my mind until I found this page (ironically because homebrew usually works so smoothly).

In future, if I were to brew install gcc45 and use that gcc instead of Apple's, would it have avoided this issue?

[samueljohn]

@mkhorton yes, if you use the brew install gcc --enable-fortran from homebrew/dupes and compile with that gcc-4.7 or gfortran-4.7, the correct paths are built in.

Not sure what the state of the gcc45 formula is.

@Sharpie adding the LIBRARY_PATH to the gfortran caveats would be super great :-)

[mkhorton]

@samueljohn thank you, your explanation's much appreciated

[aisipos]

I has similar issues myself, it seems the remains of a non-homebrew installed gfortran (installed from a source tarball) were conflicting with the Homebrew installed gfortran. I had to do a lot of manual cleaning out of files, most particularly removing the non-homebrew /usr/bin/gfortran

I noticed in ENV.rb if which gfortran returns anything, homebrew assumes this is a brew installed gfortran. This is not necessarily the case. Perhaps it should really be looking for brew prefix/bin/gfortran, with a caveat that if there are other gfortran's installed this can cause problems (or perhaps a brew doctor for this).

[awreece]

I get what is probably this problem attempting to build sage: https://gist.github.com/awreece/4981412

[samueljohn]

@Sharpie you know more about gfortran than, me. Want to add a proper caveat to gfortran?

In homebrew-science, there is the following line, which is also related to the gfortran library:
ENV.append 'LDFLAGS', "-L#{Formula.factory('gfortran').opt_prefix}/gfortran/lib -lgfortran"

It seems to work but I don't know if that is a hack or solution.

[samueljohn]

@awreece if you set the LDFLAGS or the LIBRARY_PATH vars, does it work for you? If so, which of these variables did the trick for you? I assume you have a brewed gfortran.

[awreece]

@samueljohn Actually, I managed to get it to work a while back after rebuilding gcc from homebrew/dupes and doing some other stuff. Unfortunately, I don't think I can reproduce the steps I took to fix the issue :-/

[adamv]

Closing because of the age of this issue, and because various reporters have found reasons or workarounds. Any new issues should come up as new issues, with appropriate documentation.

[chinchliff]

I also ran into this problem, when attempting to use brew-installed gcc 4.8.2 to compile external code (not managed in the brew repos). My workaround was to install GFortran 4.8.2 from https://gcc.gnu.org/wiki/GFortranBinaries and set the compiler flag -L/usr/local/gfortran/lib/ in my Makefile. Definitely agree that it would be nicer if brew-installed gcc could find the proper fortran libraries, but is sounds like this won't be done?