Opened 11 years ago

Closed 11 years ago

Last modified 11 years ago

#41135 closed defect (invalid)

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

Reported by: mario.stief@… Owned by: daitakahashi
Priority: Normal Milestone:
Component: ports Version: 2.2.1
Keywords: Cc: neverpanic (Clemens Lang)
Port: gsl

Description

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?

Change History (10)

comment:1 Changed 11 years ago by neverpanic (Clemens Lang)

Owner: changed from macports-tickets@… to dtakahashi42@…
Port: gsl added
Summary: Better way as to set DYLD_LIBRARY_PATH?gsl: libgsl.0.dylib possibly uses incorrect library id.
Type: requestdefect

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.

comment:2 Changed 11 years ago by 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)

comment:3 Changed 11 years ago by neverpanic (Clemens Lang)

Cc: cal@… added

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?

comment:4 Changed 11 years ago by 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/lib is doing fine and both programs are running.

Last edited 11 years ago by mario.stief@… (previous) (diff)

comment:5 Changed 11 years ago by neverpanic (Clemens Lang)

Resolution: invalid
Status: newclosed

Glad you got it working.

comment:6 Changed 11 years ago by mario.stief@…

Thank you for your time. :}

comment:7 in reply to:  1 ; Changed 11 years ago by 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?

comment:8 in reply to:  7 ; Changed 11 years ago by 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.

comment:9 in reply to:  8 ; Changed 11 years ago by 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?

comment:10 in reply to:  9 Changed 11 years ago by 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.

Note: See TracTickets for help on using tickets.