[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