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 Changed 13 years ago by ryandesign (Ryan Carsten Schmidt)
Resolution: | → invalid |
---|---|
Status: | new → closed |
Note: See
TracTickets for help on using
tickets.
Replying to sima.chalavi@…:
The usual reason for this is explained here: wiki:ProblemHotlist#libiconv-version
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 agree there are some differences between your case and the usual manifestation, particularly this:
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.
Sorry, our rsync server is down right now. See #34298 for alternatives.