[MacPorts] #34309: incompatible libintl and libiconv versions
MacPorts
noreply at macports.org
Wed May 2 11:08:42 PDT 2012
#34309: incompatible libintl and libiconv versions
-------------------------------------+--------------------------------------
Reporter: sima.chalavi@… | Owner: macports-tickets@…
Type: defect | Status: closed
Priority: Normal | Milestone:
Component: ports | Version: 2.0.4
Resolution: invalid | Keywords:
Port: |
-------------------------------------+--------------------------------------
Changes (by ryandesign@…):
* status: new => closed
* resolution: => invalid
Comment:
Replying to [ticket:34309 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
[http://echelog.com/logs/browse/macports/1267138800 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.
--
Ticket URL: <https://trac.macports.org/ticket/34309#comment:2>
MacPorts <http://www.macports.org/>
Ports system for Mac OS
More information about the macports-tickets
mailing list