[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@…):

 Sorry my suggestions haven't helped so far. To be honest the fsl build is
 so enormous and so convoluted that it's hard for me to understand exactly
 what it's doing, and therefore why it's not working on your system,
 without studying it a great deal more.


 Replying to [comment:8 stephane.jacobs@…]:
 > I'm not sure of what I "want", I don't know if I "want" to use the
 unversal builds :-),

 This is an easy question so I'll answer it first.
 [http://en.wikipedia.org/wiki/Universal_binary "Universal" means "for more
 than one architecture"], and in the case of FSL and Leopard, it means for
 all four Mac OS X architectures: PowerPC and Intel, in both 32-bit and
 64-bit versions. Only one architecture of a program will run at once, so
 you just need to decide which architectures you're going to want to run
 the program in. Are you going to want to run this program on a Mac with a
 PowerPC processor in it? If not, you don't need to build the PowerPC
 architectures. Are you going to want to run this program 64-bit? Your
 computer can probably handle 64-bit software (unless it is from the first
 generation of Intel Macs), but building 64-bit is not the default on
 Leopard. (It is on Snow Leopard.) 64-bit software might be slightly
 faster, and also lets you access more than 4GB of memory per program. If
 you don't need to access more than 4GB of memory in this program, then you
 probably don't need 64-bit.

 > but I'm thinking there's a reason for them to put it in the FSL scripts,

 Building universal is a great thing for the developers of FSL to be doing
 when they're distributing a binary, since it means any user, regardless of
 the processor in their Mac, can use it optimally. But if you're building
 it for your own use, you know what kind of processor you have, so you
 don't need to bother with the others.

 > so I'll probably go for the 3rd option... Unless changing the order of
 the PATH variable can do the trick?

 I haven't looked at the FSL build scripts closely enough to know exactly
 what they do, but it would certainly be possible for them to look for
 pkgconfig information or other *-config scripts in $PATH, and if
 /opt/local/bin is in your $PATH, then it might find MacPorts software. If
 that's the problem, removing /opt/local/bin from your $PATH would ensure
 FSL can't find those items. Remember to put it back after you're done
 building.

 -----

 Perhaps the most important question, and one I should have asked earlier,
 is why you're building FSL at all. They distribute Mac binaries, so using
 them would probably be much easier than wading through this build process.

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