using @rpath on the mac

[teemo10]

Hi,

How can I build wxiwdgets release with @rpath as the install_name on
the mac?

I built wx with the following config command:
../configure CFLAGS="-arch i386" CXXFLAGS="-arch i386" LDFLAGS="-arch
i386" OBJCFLAGS="-arch i386" OBJCXXFLAGS="-arch i386" --enable-debug --
with-cocoa --with-macosx-sdk=/Developer/SDKs/MacOSX10.5.sdk --disable-
compat28 --with-opengl --prefix="$(pwd)" && make

I then ran:
install_name_tool -id @rpath/libwx_baseu-2.9.dylib /Developer/Packages/
wxWidgets/build-release/lib/wx_baseu-2.9.dylib

If i then run: otool -D libwx_baseu-2.9.dylib
I get:
libwx_baseu-2.9.dylib:
@rpath/libwx_baseu-2.9.dylib

So it seems things are ok. However if i copy over
"libwx_baseu-2.9.dylib" to my app's framework folder, to which i add a
runtime search path. I get a run-time crash when the app starts in the
wxFrame constructor. If in my runtime search paths i add the directory
where wx was built (i.e. /Developer/Packages/wxWidgets/build-release/
lib) the app runs fine.

So I'm a little confused.

1. How come in the lib folder there are always 3 versions of the
dylibs with the following naming convention:
libwx_osx_cocoau_adv-2.9.2.0.0.dylib
libwx_osx_cocoau_adv-2.9.2.dylib
libwx_osx_cocoau_adv-2.9.dylib

2. Is there a way when building wx to use @rpath to avoid having to
use install_name_tool?

[Dion Whittaker]

I believe you also need to run:
"install_name_tool -change oldpath newpath file" on your executable and
all of the libraries you use.

install_name_tool -id changes the internal name of the file, you need
to later the path to any externally linked libraries.

So in your case I think you need something like:
install_name_tool -change
"/Developer/Packages/wxWidgets/build-release/lib/wx_baseu-2.9.dylib"
"@rpath/libxw_baseu-2.9.dylib" executable_name

Remember you need to do this for all libraries used by the executable,
and then for all internal library paths used by each library file.
otool -L, will give you a list of all libraries used by the executable
and each library file.

Hope this is some help.
Dion

[teemo10]

Thanks for the tip.

I understand the part about doing this for all libraries used by the
executable. For example for the minimal sample (which is suffering
from the same issue), if I run otool -L minimal I get:
@rpath/libwx_baseu-2.9.dylib (compatibility version 1.0.0,
current version 1.0.0)
@rpath/libwx_osx_cocoau_core-2.9.dylib (compatibility version 1.0.0,
current version 1.0.0)
/System/Library/Frameworks/Carbon.framework/Versions/A/Carbon
(compatibility version 2.0.0, current version 136.0.0)
/usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current
version 7.4.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)
/System/Library/Frameworks/CoreFoundation.framework/Versions/A/
CoreFoundation (compatibility version 150.0.0, current version
476.19.0)

Do I need to run something as follows, for all the other libraries
listed?:
install_name_tool -change "/Developer/Packages/wxWidgets/build-
debug/lib/libwx_baseu-2.9.dylib" "@rpath/libxw_baseu-2.9.dylib"
minimal
install_name_tool -change "/Developer/Packages/wxWidgets/build-
debug/lib/libwx_osx_cocoau_core-2.9.dylib" "@rpath/
libwx_osx_cocoau_core-2.9.dylib" minimal


Do i then have to do something like:
install_name_tool -change "/System/Library/Frameworks/Carbon.framework/
Versions/A/Carbon" "@rpath/libxw_baseu-2.9.dylib" minimal

It doesn't make sense to me.

I'm thinking wx needs be built with some indication of @rpath. That's
why it runs fine from its build directory, but not from outside it.
Its like its looking for something (resources) but can't find them,
when the dylib is moved.

[M Gagnon]

Hi,

if you wish to bundle your dynamic libraries into your application, I
believe the easiest way is to use this small
tool I wrote :

http://macdylibbundler.sourceforge.net/

This will allow you to integrate a dynamic library into your application
bundle with a single line on the terminal;
probably much easier that what you're trying to do at this time (or
build wxWidgets as static if you can, of course,
that's still easiest)

-- Auria

[Tamer El Nashar]

--
Please read http://www.wxwidgets.org/support/mlhowto.htm before posting.

To unsubscribe, send email to wx-users+u...@googlegroups.com
or visit http://groups.google.com/group/wx-users

Pleasantly, but not very surprisingly, I found yet another undocumented feature in wxWidgets. A script that is generated after building wx as a dynamic library called "change-install-names" that does exactly what I was looking for. The script is found in the build-debug (or build-release) folder (e.g. /Developer/Packages/wxWidgets/build-debug).

The script is supposed to iterate through all the library files and fixes their the ids and paths (couldn't believe my eyes when i found the script just lying there in the folder)! However the code in the script needed a small fix.

Original Code:
#!/bin/sh
libnames=`cd ${1} ; ls -1 | grep '\.[0-9][0-9]*\.dylib$'`
for i in ${libnames} ; do
    install_name_tool -id ${1}/${i} ${1}/${i}
    for dep in ${libnames} ; do
        install_name_tool -change ${2}/${dep} ${1}/${dep} ${1}/${i}
    done
done

Fixed Code:
#!/bin/sh
libnames=`cd ${1} ; ls -1 | grep '\.[0-9][0-9]*\.dylib$'`
for i in ${libnames} ; do
    install_name_tool -id ${2}/${i} ${1}/${i}
    for dep in ${libnames} ; do
        install_name_tool -change ${1}/${dep} ${2}/${dep} ${1}/${i}
    done
done

Running the fixed script, with the following parameters, does exactly what I needed:
./change-install-names /Developer/Packages/wxWidgets/build-debug/lib @rpath

Now I can place wxWidgets wherever I need, provided I add a run-time search path in my app to that directory. Also I must copy the required library with its 2 symbolic links over to that folder (e.g. libwx_baseu-2.9.2.0.0.dylib - libwx_baseu-2.9.2.dylib - libwx_baseu-2.9.dylib).

[Stefan Csomor]

Hi

>./change-install-names /Developer/Packages/wxWidgets/build-debug/lib
>@rpath

please note that @rpath is 10.5+ only, @executable_path is working on
earlier systems as well, but needs relative placement to the executable
while @rpath also is useful for bundles

Best,

Stefan

[Vadim Zeitlin]

On Thu, 19 May 2011 12:26:45 +0300 Tamer El Nashar <tee...@gmail.com> wrote:

TEN> Pleasantly, but not very surprisingly, I found yet another undocumented
TEN> feature in wxWidgets. A script that is generated after building wx as a
TEN> dynamic library called "change-install-names" that does exactly what I was
TEN> looking for. The script is found in the build-debug (or build-release)
TEN> folder (e.g. /Developer/Packages/wxWidgets/build-debug).
TEN>
TEN> The script is supposed to iterate through all the library files and fixes
TEN> their the ids and paths (couldn't believe my eyes when i found the script
TEN> just lying there in the folder)! However the code in the script needed a
TEN> small fix.
TEN>
TEN> Original Code:
TEN> #!/bin/sh
TEN> libnames=`cd ${1} ; ls -1 | grep '\.[0-9][0-9]*\.dylib$'`
TEN> for i in ${libnames} ; do
TEN> install_name_tool -id ${1}/${i} ${1}/${i}
TEN> for dep in ${libnames} ; do
TEN> install_name_tool -change ${2}/${dep} ${1}/${dep} ${1}/${i}
TEN> done
TEN> done
TEN>
TEN> Fixed Code:
TEN> #!/bin/sh
TEN> libnames=`cd ${1} ; ls -1 | grep '\.[0-9][0-9]*\.dylib$'`
TEN> for i in ${libnames} ; do
TEN> install_name_tool -id ${2}/${i} ${1}/${i}
TEN> for dep in ${libnames} ; do
TEN> install_name_tool -change ${1}/${dep} ${2}/${dep} ${1}/${i}
TEN> done
TEN> done

I don't really understand why is the fix needed. It looks like you mostly
exchanged the first and second parameters but maybe I'm missing something.

FWIW I didn't know about this script too but I did write
misc/scripts/set_install_name which was supposed to do the same thing but
in a bit more user-friendly way. I didn't test it since a long time though,
but it did work back in 2005 when it was written.

Regards,
VZ

--
TT-Solutions: wxWidgets consultancy and technical support
http://www.tt-solutions.com/

[Tamer El Nashar]

It needs to be fixed, because the order of the parameters does make a difference. The original code will not work.

Yet another hidden script! I didn't try set_install_name. But when I do test it, i'll be sure to report it here.

[Robin Dunn]

On 5/22/11 1:58 AM, Tamer El Nashar wrote:
> I don't really understand why is the fix needed. It looks like you
> mostly
> exchanged the first and second parameters but maybe I'm missing
> something.
>
> FWIW I didn't know about this script too but I did write
> misc/scripts/set_install_name which was supposed to do the same
> thing but
> in a bit more user-friendly way. I didn't test it since a long time
> though,
> but it did work back in 2005 when it was written.
>

> It needs to be fixed, because the order of the parameters does make a

> difference. The original code will not work.

Did you test with the current trunk or a previous release/snapshot? I
recently applied a patch that makes, IIRC, a similar change to how
install_name_tool is run in that script.

http://trac.wxwidgets.org/changeset/67603/wxWidgets/trunk/configure.in

--
Robin Dunn
Software Craftsman
http://wxPython.org

[Tamer El Nashar]

After browsing the source online, it seems that I apparently got wx from svn, before your fix. I have not tested with the latest changes. However my fix differs from yous. If I get a chance to test it (hopefully soon), I will report it here.