Mike, Thank you for your precise answer. I will try this tomorrow. I have few other questions for you:
1.0) Why isn't CMake doing this automatically ? 1.1) Is is just a CMake's missing feature or is there any technical issues ? I think QMake does it for you isn't is ? 2.0) I'm sure Apple has plenty of reasons for doing libs handling this way but is it only me or this is completly retard ? 2.1) I'm not sure but I don't think linux is working this way isn't it ? 2.2) Wouldn't it be easier just to install all the libs with CPack in standard location (/usr/lib) if possible ? Libs handling under OSX is a real PITA. I will give you my feedback soon. Regards, Félix C. Morency On Dec 4, 2007 4:08 PM, Mike Jackson <[EMAIL PROTECTED]> wrote: > Welcome to the "can of worms" called "install_name_tool" on OS X. > Yes, you can change 3rd party libs.. with one BIG caveat. Who ever > compiled it needs to have compiled with the -Header_Pad_Max_install_Names > (or something like that). If that was done then you should be able to change > the library. > > Say we have a 3rd party lib "Foo". Lets run otool -L libFoo.dylib and see > what we get. > /usr/local/lib/libFoo.dylib > /usr/lib/libSystem.B.dylib > > So what we want to do is the following: > install_name_tool -id @executable_path/../Plugins/libFoo.dylib MyApp.app > /Contents/Plugins/libFoo.dylib > > That is the first part. Now we need to change the actual executable also. > install_name_tool -change > /usr/local/lib/libFoo.dylib executable_path/../Plugins/libFoo.dylib > MyApp.app/Contents/MacOS/MyApp > > You can check things are correct by running: > otool -L MyApp.app/Contents/Plugins/libFoo.dylib > otool -L MyApp.app/Contents/MacOS/MyApp > > When you look at the output from those, the paths that refer to > libFoo.dylib should all have @executable_path/../Plugins/libFoo.dylib in > them. > > Shell scripts are great for this. I have some that I have made up just for > this purpose. CMake configures them, then runs them after the build. > > Qt... Again.. that same thing as above BUT You have to correct each and > every Qt library that you use PLUS make sure you get all the dependancies > correct, ie, if your app depends on QtCore and QtGui. you have to make the > following changes. > > Change MyApp to look for QtCore and QtGui in > @executable_path/../Frameworks/QtCore.framework/QtCore > Change the install_name on QtCore and QtGui to each > be @executable_path/../Frameworks/[fill in the rest] > Change QtGui to look for QtCore > in @executable_path/../Frameworks/QtCore.framework/QtCore > > Sound like fun? It isn't. I submitted a bug to Trolltech to properly > support this and got a reply that basically said install_name does not exist > on OS X? Huh? > > You are welcome to look at the following locations and take what ever you > want/need to get your build to work. > This script does some of the above for some 3rd party libs that I use in > my app > < > http://titanium.imts.us/viewvc/Task_7/MXADataModel/Resources/PackageMXALibsForOSXAppBundle.sh.in?view=markup > > > > This script attempts to do everything for QtCore and QtGui also. > < > http://titanium.imts.us/viewvc/Task_7/MXATools/Resources/PackageQt4ForOSXAppBundle.sh.in?view=markup > > > > Hope some of that helps. > > -- > Mike Jackson Senior Research Engineer > Innovative Management & Technology Services > > > On Dec 4, 2007, at 3:51 PM, Félix C. Morency wrote: > > Hi, > > The INSTALL_NAME_DIR is a string specifying the directory portion of the > "install_name" field of shared libraries on Mac OSX to use in the installed > targets (as taken from the current documentation). Is there any way of > setting this property on a third party lib ? I checked the current CVS > CMake's examples (Bundle and Framework) and I couldn't find an positive > answer about third party libraries (I installed mine in Content/Plugins). If > not, if there any other way to include third party libs within the bundle > and make the application find it ? > > I also installed Qt's framework within my bundle with the INSTALL( > DIRECTORY...) command. Is there any better way to do this ? > > I think the current tools work great with CMake generated > libs/projects/framework but I think there is a lack in third > libs/projects/framework party inclusion support. > > Regards, > Félix C. Morency > _______________________________________________ > CMake mailing list > CMake@cmake.org > http://www.cmake.org/mailman/listinfo/cmake > > >
_______________________________________________ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
