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

 Replying to [comment:10 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.
 >

 Don't apologize, I'm amazed by the time you're willing to spend on this
 already!! :)

 >
 > 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.
 >
 > -----

 Thanks for answering these questions! And you were right, removing
 /opt/local directories from my $PATH variable did the trick and allowed
 FSL to work. I was just concerned other stuff, especially Macports, would
 not work any more, and it would be a âin to change the PATH each time
 before and after running analyses with FSL.

 >
 > 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.

 I'm actually not building FSL, but trying to use it. I downloaded the Mab
 binaries and used their install script. The thing is, it used to work
 before that story. But now I realize I hadn't used FSL in a while, and
 just before using it again a few days ago, I installed the latest version
 of FSL as described above. My guess is that I didn't have MacPorts
 installed when I first installed FSL on my machine, so FSL worked fine
 right, and kept working after I had installed MacPorts as well. But when I
 installed the latest version of FSL *with* MacPorts already installed (and
 with /opt/local in PATH), the problem appeared.
 Would that make sense? If so, re-installing FSL without /opt/local in PATH
 and putting those directories back in PATH after the installation should
 do the trick, right?

 Thanks again for the great assistance!

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