[MacPorts] #29142: libintl and libiconv versions not compatible
MacPorts
noreply at macports.org
Mon Apr 18 22:03:07 PDT 2011
#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
More information about the macports-tickets
mailing list