Lion's libcups expects _iconv in libiconv.

[k.polezhaiev@…]

I am trying to build .app bundle of application that uses GStreamer. I have Snow Leopard computer with macports installed. I've copied all the dependencies of my binary in Content/Resources/lib subdir and made launcher that modifies DYLD_LIBRARY_PATH before call of main binary. It seems .app works good on my computer. But as soon as I run it on Lion computer, application fails to start cause of /usr/lib/libcups expects _iconv symbol in my libiconv.2.dylib. If I will not ship libiconv.2.dylib, libgio (and may be other libs) will try to use Apple's libiconv.2.dylib, which is of version 7.0.0 (but 8.0.0 is required). Is there possibility to link all the libraries with Apple native libiconv instead of macports one, or to exclude CUPS from dependencies?

[ryandesign@…]

Replying to k.polezhaiev@…:

I am trying to build .app bundle of application that uses GStreamer. I have Snow Leopard computer with macports installed. I've copied all the dependencies of my binary in Content/Resources/lib subdir and made launcher that modifies DYLD_LIBRARY_PATH before call of main binary. It seems .app works good on my computer. But as soon as I run it on Lion computer, application fails to start cause of /usr/lib/libcups expects _iconv symbol in my libiconv.2.dylib.

It sounds like you're trying to do a whole bunch of stuff that MacPorts was designed to do (compiling on one OS version and running on another; compiling against MacPorts libs and expecting things to work with non-MacPorts libs).

If I will not ship libiconv.2.dylib, libgio (and may be other libs) will try to use Apple's libiconv.2.dylib, which is of version 7.0.0 (but 8.0.0 is required).

libiconv library version 8.0.0 is only required because that is the version of libiconv in MacPorts which was used when building libgio. If libgio had been built against a libiconv with a different library version then only that version would be required.

Is there possibility to link all the libraries with Apple native libiconv instead of macports one,

MacPorts does not provide the option to link ports with Apple's libiconv, no. See wiki:FAQ#syslibs and wiki:FAQ#ownlibs.

or to exclude CUPS from dependencies?

I don't know which port it is that's making use of CUPS here.

[k.polezhaiev@…]

So, macports isn't capable to make .app which will work on Mac without installed macports?

[k.polezhaiev@…]

Replying to ryandesign@…: Thanks.

[schmitt@…]

I'm running into a simliar problem: I installed some ports on my build machine. I then build my application and otool -L myApp.binary shows dependencies on libraries installed at /opt/local/lib. myApp.binary runs fine on the build machine. In order to deploy my application to other machines, I copy the corresponding libraries to "myApplication/darwin-libs", write a wrapper script at "myApplication/launchMyApp.sh" which looks something like this:

#!/bin/env sh
export DYLD_LIBRARY_PATH=/path/to/myApplication/darwin-libs
/path/to/myApplication/myApp.binary.

Now when I run launchMyApp.sh on either the build or the user machine, I get an error:

dyld: Symbol not found: _iconv
  Referenced from: /usr/lib/libcups.2.dylib
  Expected in: /path/to/myApplication/darwin-libs/libiconv.2.dylib
 in /usr/lib/libcups.2.dylib

The confusing thing is that libcups.2.dylib isn't used anywhere in my application: otool -L on myApp.binary and all the libraries in /opt/local/lib/* does not resolve any reference to /usr/lib/libcups.2.dylib. Furthermore, I can "fix" the problem by either cp /usr/lib/libcups.2.dylib /path/to/myApplication/darwin-libs or appending DYLD_LIBRARY_PATH+=/usr/lib. Finally, I only have this problem when running the launchMyApp.sh on OSX 10.7 (Lion) machines. The whole procedure seems to work fine on Leopard and Snow Leopard machines.
Any idea of what's going on here?

[schmitt@…]

Cc Me!

[ryandesign@…]

Replying to ryandesign@…:

It sounds like you're trying to do a whole bunch of stuff that MacPorts was designed to do

that should have been "...that MacPorts wasn't designed to do".

Setting DYLD_LIBRARY_PATH is probably asking for trouble.

Have you tried dylibbundler instead?

[jmr@…]

Yes, the breakage is because you're setting DYLD_LIBRARY_PATH to an incorrect value.