Trouble distributing application that links to MacPort libraries

Jan Stary hans at stare.cz
Fri Mar 30 02:27:51 PDT 2012


On Mar 29 16:17:04, Peter Schmitt wrote:
> Hi macports-users!
> 
> I installed some ports on a build machine. I then build my application
> and `otool -L myApp.binary` shows dependencies on some MacPorts
> libraries installed at /opt/local/lib.

At this point, it doesn't matter that those libraries come from macports.

> myApp.binary runs fine on this
> build machine.  In order to deploy my application to other machines, I
> copy the corresponding libraries to "myApplication/darwin-libs" and
> write a wrapper script at "myApplication/launchMyApp.sh" which looks
> something like this:
> 
> >
> >  #!/bin/env sh
> >  # this is "launchMyApp.sh".
> >  export DYLD_LIBRARY_PATH=/path/to/myApplication/darwin-libs
> >  /path/to/myApplication/myApp.binary.

You cannot expect a binary to run on another system just by
copying it (and its dependencies) over.

Also, your DYLD_LIBRARY_PATH now doesn't even contain libc.

> Now when I run launchMyApp.sh on either the build or the user machine,
> I get an error:
> 
> >  dyld: Symbol not found: _iconv

See?

> >    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 myApp.binary` and all the libraries in
> /opt/local/lib/* do not resolve any reference to
> /usr/lib/libcups.2.dylib!

Show me; launch script(1) and run 'otool -L' on your binary,
then run it on each of its dependencies, recursively.
Somewhere along the way, libcups must be a dependency;
either that, or your linker is broken.


> 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
> >
> 
> to launchMyApp.sh. I only get this behavior when running
> 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?

Really, you cannot expect library dependencies _on_another_system_
to be resolved by just copying the lib files over.



More information about the macports-users mailing list