Opened 13 years ago

Closed 13 years ago

#34309 closed defect (invalid)

incompatible libintl and libiconv versions

Reported by: sima.chalavi@… Owned by: macports-tickets@…
Priority: Normal Milestone:
Component: ports Version: 2.0.4
Keywords: Cc: ryandesign (Ryan Carsten Schmidt)
Port:

Description (last modified by ryandesign (Ryan Carsten Schmidt))

Hello,

I am running a data analysis software with Mac OS X (10.5.8) and recently running the previously running commands give me this error:

dyld: Library not loaded: /opt/local/lib/libiconv.2.dylib
  Referenced from: /opt/local/lib/libintl.8.dylib
  Reason: Incompatible library version: libintl.8.dylib requires version 8.0.0 or later, but libiconv.2.dylib provides version 7.0.0
/usr/local/fsl/bin/fsl_sub: line 243: [: !=: unary operator expected
usage: basename string [suffix]
       basename [-a] [-s suffix] string [...]
44693

I read the Ticket #29142 which is using the same software as me however there are some differences between his/her settings than mine.

I also tried otool and lipo:

otool -L /opt/local/lib/libiconv.2.dylib

/opt/local/lib/libiconv.2.dylib:
        /usr/people/cowboy/var/jalapeno4_apple-darwin8-gcc4.0/sandboxes/fsl/extras/lib/libiconv.2.dylib (compatibility version 7.0.0, current version 7.0.0)
        /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 88.3.3)


lipo -info /opt/local/lib/libiconv.2.dylib
Architectures in the fat file: /opt/local/lib/libiconv.2.dylib are: ppc ppc64 i386 x86_64 

 lipo -info /opt/local/lib/libintl.8.dylib 
Non-fat file: /opt/local/lib/libintl.8.dylib is architecture: i386

and it seems that it is correct that the version of libiconv is 7 and not 8, I tried to update my system however selfupdate also failed:

 sudo port selfupdate
Password:
Warning: port definitions are more than two weeks old, consider using selfupdate
--->  Updating the ports tree
Error: Synchronization of the local ports tree failed doing rsync
Error: /opt/local/bin/port: port selfupdate failed: Couldn't sync the ports tree: Synchronization of 1 source(s) failed

Now I am really stuck and would appreciate any help.

Thanks, Sima.

Change History (2)

comment:1 Changed 13 years ago by ryandesign (Ryan Carsten Schmidt)

Cc: ryandesign@… added
Description: modified (diff)

comment:2 in reply to:  description Changed 13 years ago by ryandesign (Ryan Carsten Schmidt)

Resolution: invalid
Status: newclosed

Replying to sima.chalavi@…:

I am running a data analysis software with Mac OS X (10.5.8) and recently running the previously running commands give me this error:

dyld: Library not loaded: /opt/local/lib/libiconv.2.dylib
  Referenced from: /opt/local/lib/libintl.8.dylib
  Reason: Incompatible library version: libintl.8.dylib requires version 8.0.0 or later, but libiconv.2.dylib provides version 7.0.0

The usual reason for this is explained here: wiki:ProblemHotlist#libiconv-version

/usr/local/fsl/bin/fsl_sub: line 243: [: !=: unary operator expected
usage: basename string [suffix]
       basename [-a] [-s suffix] string [...]
44693

Installing 3rd-party software (like fsl) in /usr/local can be problematic for MacPorts. But it looks like this fsl is contained within /usr/local/fsl, which would be ok. Just make sure there's nothing installed directly in /usr/local (meaning: /usr/local/bin, /usr/local/lib, /usr/local/include, etc.).

I read the Ticket #29142 which is using the same software as me however there are some differences between his/her settings than mine.

I agree there are some differences between your case and the usual manifestation, particularly this:

otool -L /opt/local/lib/libiconv.2.dylib
/opt/local/lib/libiconv.2.dylib:
        /usr/people/cowboy/var/jalapeno4_apple-darwin8-gcc4.0/sandboxes/fsl/extras/lib/libiconv.2.dylib (compatibility version 7.0.0, current version 7.0.0)
        /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 88.3.3)

That /usr/people/cowboy path is certainly unique. I Googled it and found this conversation on our IRC server two years ago where a user analyzed the problem. The verdict was that in one of fsl's scripts they set the DYLD_LIBRARY_PATH variable (which is mentioned as a possible culprit in wiki:ProblemHotlist#libiconv-version). Therefore, when their script calls the getopt program, and MacPorts' getopt is found, the MacPorts getopt program doesn't get to use its MacPorts libraries anymore; it tries to use the fsl versions of the libraries which the DYLD_LIBRARY_PATH variable points to, with which the MacPorts getopt program is not compatible.

These kinds of problems are why it is such a very bad idea to ever set DYLD_LIBRARY_PATH. The developers of fsl should not have done that.

fsl seems to be a monolithic distribution including every possible piece of software; it does not want to play nice with other software you might already be using. When I looked into it a year ago, their distfile alone was an absurd 1.2 GB. I found it extremely frustrating and ultimately pointless to try to understand how it all works together.

On the plus side, since it's monolithic, I'll bet it includes its own copy of getopt that it would work fine with. So your solution might be to simply adjust your PATH. Make sure /usr/local/fsl/bin is first in $PATH when you want to use fsl, and otherwise, make sure /opt/local/bin is first in $PATH when you want to use MacPorts software.

I'm closing the ticket as invalid since there's no bug in MacPorts software; it's a bug in fsl.

I tried to update my system however selfupdate also failed:

Sorry, our rsync server is down right now. See #34298 for alternatives.

Note: See TracTickets for help on using tickets.