On linux I ship all .so files (with few exception) listed by ldd in a given directory. I also ship a wrapper script that add this directory to LD_LIBRARY_PATH prior to execute the executable.
Here the script: #!/bin/sh # This script overload the dynamic library path. # Resolve links referring to me. if test -L "$0"; then exec $(readlink -f "$0") fi appname=$(basename $0 | sed s,\.sh$,,) dirname=$(dirname $0) case "$dirname" in /*) # nothing to do ;; *) dirname="$PWD/$dirname" ;; esac paths="$dirname/../@EXTRA_LIBRARIES_DIR@" LD_LIBRARY_PATH="$paths" export LD_LIBRARY_PATH DYLD_LIBRARY_PATH="$paths" export DYLD_LIBRARY_PATH "$dirname/$appname" $* and here the list of .so that I do not ship: set(DLDEP_UNIX_EXCLUSION_LIST "^libc.so" "^libdl.so" "^libpthread.*" # Fedora 9 ) Note that, when you ship binary package for Linux you have to compile your project on a system with the oldest GLIBC you want to support. For instance package built on Ubuntu (glibc 2.4) won't work on Debian stable (glibc 2.0). I build my package on Debian and I have tested it on various freshly installed Linux distribution and it works fine. Cheers, On Tue, Oct 28, 2008 at 9:47 PM, David Cole <[EMAIL PROTECTED]> wrote: > You are not being stupid. It does need to be used at installation time to be > useful. > The intent is to analyze a given built executable to determine the required > set of (possibly 3rd-party, possibly built elsewhere on the build machine) > libraries that it needs to run. Then, given that set, you need to make sure > that you have install rules to cover all of those libraries. > > The first working example of its use is in the ParaView code base where it > is used to copy libraries into ParaView's Mac bundle application. It is used > in conjunction with BundleUtilities.cmake to "fix up" the bundle app so that > it is standalone and contains all of its referenced libraries in the bundle > directory structure. Then the bundle can be copied to any directory or to > another Mac and it should all "just work." > Having said that, there is more work to be done to make this a genuinely > easy to use feature of CMake. I envision being able to do the same thing at > make install time for Linux and Win32 builds, but according to the > conventions of those platforms. Dlls copied into the same dir with the exe > on Win32 and "whatever's appropriate" on Linux builds... (Feel free to make > suggestions.) > So... ideally it would all just work automatically and all you would have to > do in CMake is add an install rule for your executable and call a > post-install script that copies/fixes up libraries appropriately in a > platform-independent manner. > Thanks for asking questions / contributing to the discussion / improving > this development feature of CMake..... > David > > On Tue, Oct 28, 2008 at 7:36 AM, Mike Arthur <[EMAIL PROTECTED]> wrote: >> >> Perhaps I'm just being stupid but I can't see how this can be used as it >> needs >> to be called at installation time and I'm not aware that modules can be? >> >> Does anyone have a working example of how to install its outputted >> libraries? >> -- >> Cheers, >> Mike Arthur >> http://mikearthur.co.uk/ >> _______________________________________________ >> 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 > -- Nicolas Desprès _______________________________________________ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake