libintl and libiconv versions not compatible

[stephane.jacobs@…]

Hello,

I'm trying to run an open source software and ran into a bug I can't seem to find a solution to. Sorry if this is is a trivial problem, I am far from an expert, but could not find solutions in all the threads I've read so far.

I am on Mac OS 10.5.8, using Xcode 3.1.4.

Here is the error message I get:

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

After havind read other threads, I have already done the following:

sudo port selfupdate
sudo port upgrade outdated

libiconv exists and seems to be the right version:

otool -L /opt/local/lib/libiconv.2.dylib
/opt/local/lib/libiconv.2.dylib:
	/opt/local/lib/libiconv.2.dylib (compatibility version 8.0.0, current version 8.0.0)
	/usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 111.1.4)

Both libiconv and libintl are for the right architecture:

lipo -info /opt/local/lib/libintl.8.dylib 
Non-fat file: /opt/local/lib/libintl.8.dylib is architecture: i386
lipo -info /opt/local/lib/libiconv.2.dylib 
Non-fat file: /opt/local/lib/libiconv.2.dylib is architecture: i386

It does not seem to be a problem with DYLD environment variables, as running "env |grep -i dyld" does not return anything...

I'm stuck here, any help would really be greatly appreciated.

Best,

Stephane

[stephane.jacobs@…]

Cc Me!

[ryandesign (Ryan Carsten Schmidt)]

Replying to stephane.jacobs@…:

I'm trying to run an open source software

Which software? Another port installed with MacPorts? or something you've built by hand?

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 cause of this error that the iconv library built by MacPorts (library version 8) is built for the wrong architecture, thus it tries to fall back to the iconv library provided by Mac OS X (library version 7). The usual reason for this architecture mismatch is upgrading to Snow Leopard without following Migration instructions. But you're on Leopard, and you've demonstrated that the libraries are built for the right architecture -- at least, the libraries installed by MacPorts. Is it possible there is another iconv library that's built for the wrong architecture, perhaps in /usr/local/lib, /usr/lib or /sw/lib?

[stephane.jacobs@…]

Replying to jmr@…:

Thanks for your response!

I'm trying to run an open source software

Which software? Another port installed with MacPorts? or something you've built by hand?

It's a package of tcl scripts for data analysis (​http://www.fmrib.ox.ac.uk/fsl/fsl/list.html), not installed with MacPorts. As far as I understand, the (characters in the) scripts are not interpreted correctly because of the libraries issue, and thus won't run...

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 cause of this error that the iconv library built by MacPorts (library version 8) is built for the wrong architecture, thus it tries to fall back to the iconv library provided by Mac OS X (library version 7). The usual reason for this >architecture mismatch is upgrading to Snow Leopard without following Migration instructions. But you're on Leopard, and you've demonstrated that the libraries are built for the right architecture -- at least, the libraries installed by MacPorts. >Is it possible there is another iconv library that's built for the wrong architecture, perhaps in /usr/local/lib, /usr/lib or /sw/lib?

/usr/local/lib contains the same version for the same architecture:

otool -L /usr/local/lib/libiconv.2.dylib 
/usr/local/lib/libiconv.2.dylib:
	/usr/local/lib/libiconv.2.dylib (compatibility version 8.0.0, current version 8.0.0)
	/usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 111.1.5)
lipo -info /usr/local/lib/libiconv.2.dylib 
Non-fat file: /usr/local/lib/libiconv.2.dylib is architecture: i386

The problem seems to be in /usr/lib: wrong version, wrong architecture! :-)

otool -L /usr/lib/libiconv.2.dylib 
/usr/lib/libiconv.2.dylib:
	/usr/lib/libiconv.2.dylib (compatibility version 7.0.0, current version 7.0.0)
	/usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 111.1.1)
lipo -info /usr/lib/libiconv.2.dylib 
Architectures in the fat file: /usr/lib/libiconv.2.dylib are: ppc7400 ppc64 i386 x86_64 

Nothing in /sw/lib.

Now, I'm not sure how to update the iconv library in /usr/lib, or why the intl library is looking there but reports problems regading the library in /usr/opt/lib (which on top of it is fine)???

[ryandesign (Ryan Carsten Schmidt)]

Replying to stephane.jacobs@…:

/usr/local/lib contains the same version for the same architecture:

Please remove it and anything else in /usr/local; having files installed there is a frequent source of problems when using MacPorts and is therefore not supported.

The problem seems to be in /usr/lib: wrong version, wrong architecture! :-)

Nope, this looks fine; this is the version of libiconv Apple provides in Mac OS X.

[stephane.jacobs@…]

Replying to ryandesign@…:

Replying to stephane.jacobs@…:

/usr/local/lib contains the same version for the same architecture:

Please remove it and anything else in /usr/local; having files installed there is a frequent source of problems when using MacPorts and is therefore not supported.

The problem seems to be in /usr/lib: wrong version, wrong architecture! :-)

Nope, this looks fine; this is the version of libiconv Apple provides in Mac OS X.

I have erased everything in /usr/local/lib, but still get the same 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

Is it that it's falling back on the library located in /usr/lib, whihc is version 7.0.0 and for the wrong architecture, for some reason?

[ryandesign (Ryan Carsten Schmidt)]

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

[stephane.jacobs@…]

Replying to 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).

Thank you so much for taking the time to look into this! It is very much appreciated.

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

None of these variables have been set...

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

Could it be because my PATH variable points to dorectories in a wrong order (can't remember whether the order sets priorities as well...): PATH=/usr/local/fsl/bin:/opt/local/bin:/opt/local/sbin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/X11/bin

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

I'm not sure of what I "want", I don't know if I "want" to use the unversal builds :-), but I'm thinking there's a reason for them to put it in the FSL scripts, so I'll probably go for the 3rd option... Unless changing the order of the PATH variable can do the trick?

[stephane.jacobs@…]

update: unfortunately, rebuilding libiconv for all architectures did not fix the problem, I still get the same error... I'll remove /opt/local from my PATH variable for now, but expect this might cause other problems?

[ryandesign (Ryan Carsten Schmidt)]

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

[stephane.jacobs@…]

Replying to 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 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. ​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!

[ryandesign (Ryan Carsten Schmidt)]

Ah! You're not building it at all, just trying to use their pre-compiled software. Well that changes things, and makes it sound more and more like a DYLD_LIBRARY_PATH thing. If you're not setting that environment variable or similar, then maybe they are. I guess they're taking the components of PATH, changing bin to lib, and setting that as the library path. Whether they're doing that at install time or at runtime I don't know. Give it a try: change your path to exclude /opt/local/bin, then reinstall fsl. Does it then work? What if you put /opt/local/bin back in PATH? does it still work? If fsl is getting PATH at runtime and doing this, then the solution will probably be for you to write a wrapper script that sets PATH to just what fsl needs and then runs fsl; I can probably help with that script if this turns out to be necessary.

[stephane.jacobs@…]

Replying to ryandesign@…:

Ah! You're not building it at all, just trying to use their pre-compiled software. Well that changes things, and makes it sound more and more like a DYLD_LIBRARY_PATH thing.

Yup, sorry for not having been clear on that!

If you're not setting that environment variable or similar, then maybe they are. I guess they're taking the components of PATH, changing bin to lib, and setting that as the library path. Whether they're doing that at install time or at runtime I don't know. Give it a try: change your path to exclude /opt/local/bin, then reinstall fsl. Does it then work?

Yes it does...

What if you put /opt/local/bin back in PATH? does it still work?

Nope...

If fsl is getting PATH at runtime and doing this, then the solution will probably be for you to write a wrapper script that sets PATH to just what fsl needs and then runs fsl; I can probably help with that script if this turns out to be necessary.

If this is not too much to ask, a little hand with this would be great!

Thanks again...

[ryandesign (Ryan Carsten Schmidt)]

The wrapper script could be a simple ​Bash shell script which would just need to set PATH and any other environment variables as desired, then run the real program. I am not familiar with fsl, but if for example the program you want to run is called "fsl" and is in the directory "/usr/local/fsl/bin", then you could use this script:

#!/bin/bash
export PATH="/usr/local/fsl/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/X11/bin"
exec "fsl" "$@"

Save this file in a plain text editor (if you use TextEdit, make sure to select "Make Plain Text" from the Format menu), call it "fsl", and put it in a directory that's in your PATH. For example, on my system, I have a directory "scripts" in my home directory where I can put scripts I've made, and my ~/.bash_profile includes "~/scripts" at the beginning of my PATH. Also make sure to set the execute bit on the script. (For example, run "chmod 755 ~/scripts/fsl".) If there are multiple programs you want to run like this, create multiple wrapper scripts.

[stephane.jacobs@…]

Perfect, thanks a lot again for your help, I really appreciate the time you took to get me out of this rut!

Best,

Stephane

[ryandesign (Ryan Carsten Schmidt)]

Glad to be of service!