[MacPorts] #29142: libintl and libiconv versions not compatible

[MacPorts]

#29142: libintl and libiconv versions not compatible
---------------------------------------+------------------------------------
 Reporter:  stephane.jacobs@…          |       Owner:  macports-tickets@…                   
     Type:  defect                     |      Status:  new                                  
 Priority:  Normal                     |   Milestone:                                       
Component:  ports                      |     Version:  1.9.2                                
 Keywords:                             |        Port:  gettext libiconv                     
---------------------------------------+------------------------------------

Comment(by ryandesign@…):

 I have downloaded the fsl source to see what's going on. I see that on
 Leopard, its build scripts say it should create a 4-way universal binary
 -- for the architectures ppc, ppc64, i386 and x86_64. (Look at the files
 in config/apple-darwin9-gcc4.0: most of them include the flags "`-arch ppc
 -arch ppc64 -arch i386 -arch x86_64`".) You've shown that the iconv
 library in your MacPorts is only built for one of those architectures --
 i386 (which is totally normal for MacPorts on Leopard).

 I see that the source includes a copy of libiconv 1.11 (in
 extras/src/libiconv), so I presume it's intending to use its own internal
 copy of this and other libraries, but for some reason has instead chosen
 to use your MacPorts libraries. I can find no mention of "/opt/local" in
 the source, so I assume you have somehow informed the fsl build that you
 would like it to use the MacPorts libiconv instead. Perhaps you've set
 environment variables like CPPFLAGS, LDFLAGS, C_INCLUDE_PATH,
 LIBRARY_PATH, DYLD_LIBRARY_PATH, DYLD_FALLBACK_LIBRARY_PATH...

 Replying to [comment:6 stephane.jacobs@…]:
 > Is it that it's falling back on the library located in /usr/lib,

 Yes. Because of environment variables you set, or whatever reason, it
 initially found the libiconv library provided by MacPorts, found that it
 is version 8, and recorded that somewhere. But then it found that the
 MacPorts library didn't contain all the architectures it needed, so,
 because /usr/lib is a standard location for libraries, it went looking for
 the library there, and found it.

 > whihc is version 7.0.0

 Yes, that is the version of the libiconv library Apple ships with Mac OS
 X. Since version 7 is less than the version 8 MacPorts library it found
 earlier, it now complains about that version mismatch.

 > and for the wrong architecture, for some reason?

 No -- the library in /usr/lib has the right architectures (all four of
 them), but is the wrong library version.

 Long story short: you should either 1) let fsl use its own internal copies
 of the libraries it needs, by unsetting whatever environment variables you
 set, possibly going so far as to remove /opt/local/* from PATH
 temporarily; hopefully this would then work correctly, ignoring anything
 you've installed with MacPorts; 2) if you want fsl to use the MacPorts
 libraries and don't care about universal builds, edit the fsl build files
 and change every occurrence of "`-arch ppc -arch ppc64 -arch i386 -arch
 x86_64`" to just "`-arch i386`"; or 3) if you want fsl to use the MacPorts
 libraries and you do want universal builds, rebuild libiconv and any other
 ports it wants to use for all four architectures -- that is, set
 universal_archs to "`ppc ppc64 i386 x86_64`" in macports.conf and rebuild
 those ports (using e.g. for libiconv: "`sudo port upgrade --enforce-
 variants libiconv +universal`").

-- 
Ticket URL: <https://trac.macports.org/ticket/29142#comment:7>
MacPorts <http://www.macports.org/>
Ports system for Mac OS