GCC frontend binaries + Darwin10 (Mac OS X)

Hi,

if I want to use 'llvm-gcc' I get:

dyld: Library not loaded: /opt/local/lib/libiconv.2.dylib
  Referenced from: /Users/me/llvm/gcc/bin/llvm-gcc
  Reason: Incompatible library version: llvm-gcc requires version 8.0.0 or later, but libiconv.2.dylib provides version 7.0.0
Trace/BPT trap

So I installed MacPorts and 'libiconv', but I get the same error message. But it _should_ work, because

otool -L /opt/local/lib/libiconv.2.dylib

gives me:

/opt/local/lib/libiconv.2.dylib:
  /opt/local/lib/libiconv.2.dylib (compatibility version 8.0.0, current version 8.0.0)
  /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 125.0.0)

Any hint what went wrong?

Thanks a lot,
Nico

Fun. My guess is that it's still not loading the right libiconv, but not sure ultimately. I've never seen that problem (and I do run with macports and libiconv on my system).

At any rate, we do have binaries for that system that are shipped with the developer tools. Otherwise I would try building and running on the same system.

-eric

Did you follow the macports migration guide (Migration – MacPorts
) after upgrading from 10.5 to 10.6? I seem to remember having a
similar problem and fixing it by recompiling everything on 10.6

Not at all :wink:

I think installing libiconv with +universal makes that problem go away.

/jakob

Hi,

if I want to use 'llvm-gcc' I get:

dyld: Library not loaded: /opt/local/lib/libiconv.2.dylib
Referenced from: /Users/me/llvm/gcc/bin/llvm-gcc
Reason: Incompatible library version: llvm-gcc requires version 8.0.0 or later, but libiconv.2.dylib provides version 7.0.0
Trace/BPT trap

So I installed MacPorts and 'libiconv', but I get the same error message. But it _should_ work, because

otool -L /opt/local/lib/libiconv.2.dylib

gives me:

/opt/local/lib/libiconv.2.dylib:
  /opt/local/lib/libiconv.2.dylib (compatibility version 8.0.0, current version 8.0.0)
  /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 125.0.0)

Any hint what went wrong?

Perhaps a 32/64 bit mixup? If one is 32-bit and the other is 64-bit, that could cause something like this. Use "otool -vf" and "otool -vh" to check which slices are built for the programs.