gsl: libgsl.0.dylib possibly uses incorrect library id.

[mario.stief@…]

I'm using MacPorts for Mavericks. After installing the package gsl and executing a program that's using the library I'm getting

dyld: Library not loaded: /usr/local/lib/libgsl.0.dylib

because obviously the library is located in /opt. Setting DYLD_LIBRARY_PATH to /opt/local/lib solves this problem, but then I get errors like

dyld: Symbol not found: _iconv
  Referenced from: /usr/lib/libcups.2.dylib
  Expected in: /opt/local/lib/libiconv.2.dylib
 in /usr/lib/libcups.2.dylib
./bin/login: line 1:  7163 Trace/BPT trap: 5       osascript -e 'mount volume "afp://10.0.0.3/hdd1"'

for scripts that run just well before. I expect there is some better way than setting DYLD_LIBRARY_PATH?

[neverpanic (Clemens Lang)]

Yes, there is. The binary that links against libgsl.0.dylib can be modified with install_name_tool(1) to correctly reference the library in /opt/local.

These problems usually happen when the libgsl.0.dylib library isn't built with the correct library id; see the first line out output from otool -L /opt/local/lib/libgsl.0.dylib. If that contains /usr/local this is a bug in the gsl port and should be fixed.

[mario.stief@…]

It affects a program from me where I try to include <gsl/gsl_rng.h>.

The first line from the requested output refers to /opt, so there should be no problem with gsl?

/opt/local/lib/libgsl.0.dylib:
	/opt/local/lib/libgsl.0.dylib (compatibility version 18.0.0, current version 18.0.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1197.1.1)

[neverpanic (Clemens Lang)]

In that case it seems gsl is indeed built correctly. Do happen to have another installation of libgsl.0.dylib in /usr/local/lib? How do you link your software against MacPorts gsl?

[mario.stief@…]

No, I don't have another installation if gsl in /usr. It's some exercise code from my prof using gsl which is compiled by a Makefile. Is linking the code against /opt/local/lib the only way? Can't I tell my system to look in /usr/local/lib as well as in /opt/local/lib? That's why I tried modify the dyld path...

/edit: I just found out that adding setting DYLD_FALLBACK_LIBRARY_PATH to /opt/local/bin is doing fine and both programs are running.

[neverpanic (Clemens Lang)]

Glad you got it working.

[mario.stief@…]

Thank you for your time. :}

[mf2k (Frank Schima)]

Replying to cal@…:

Yes, there is. The binary that links against libgsl.0.dylib can be modified with install_name_tool(1) to correctly reference the library in /opt/local.

These problems usually happen when the libgsl.0.dylib library isn't built with the correct library id; see the first line out output from otool -L /opt/local/lib/libgsl.0.dylib. If that contains /usr/local this is a bug in the gsl port and should be fixed.

Given this fact, shouldn't this ticket remain open until that problem is fixed?

[neverpanic (Clemens Lang)]

Replying to macsforever2000@…:

Given this fact, shouldn't this ticket remain open until that problem is fixed?

The library in MacPorts is built correctly, see comment:2. The library that causes the incorrect load command must be located elsewhere.

[daitakahashi]

Replying to cal@…:

The library in MacPorts is built correctly, see comment:2. The library that causes the incorrect load command must be located elsewhere.

So, the portfile does not need any change, does it?

[neverpanic (Clemens Lang)]

Replying to dtakahashi42@…:

So, the portfile does not need any change, does it?

Nope, the Portfile is perfectly fine. Sorry for bothering you.