GNOME Bugzilla – Bug 350385
Compilation against evo without using .la files does not work
Last modified: 2013-09-10 13:57:57 UTC
Please describe the problem: libtool have to ways to figure out which dependencies and compilation flags to pull in: one is to use .la files, the other is to use pkg-config. The latter is becoming increasingly popular. Compiling against evolution (for example evolution-exchange) this way result in binaries that are unable to find the private libraries because RPATH is not set in the ELF binaries. Steps to reproduce: 1. Do not install evolution *.la files 2. Compile evolution-exchange 3. Note that compilation/linking works, but running doesn't. Also see that libraries (like libeutil.so.0 and libeshell.so.0) in /usr/lib/evolution/2.6/ cannot be resolved, by running 'ldd evolution-exchange'. 'objdump -p /usr/bin/ximian-connector-setup-2.6 | grep RPATH' shows that RPATH is not set Actual results: No RPATH is set in the binaries Expected results: RPATH should be set and the libraries should be resolved. Does this happen every time? Yes Other information:
Created attachment 70460 [details] [review] Patch that fixes the problem This patch is being used by Debian with success since Jul 6 2006. It lets pkg-config know about the required RPATH. A different solution to the problem could be to move the private libraries to a public location like /usr/lib. Please reassign to Harish.
Thanks for the patch. Just curious - I had always thought debian did not prefer rpaths to be set. Is it ok for evolution to use rpath because we do not install in the /usr/lib prefix ?
Fix committed to trunk and stable-branch.
This patch is not portable and the .pc from evolution-2.24.5 are not usable on darwin. -R is an ELF (or GNU gcc, I forget the specific determinant) flag, and using it on darwin causes the linker to abort with an error. In fact, darwin linker by default *always* hardcodes the full path to a shared lib regardless of where it is, so the whole idea of loadtime/dyld searching for it (and hence having to control that searching) is meaningless. Seems like libtool should know the semantics of the linker and automatically add -R if appropriate when linking against a lib in a non-standard location (via -L flag in the .pc) even without using a .la file. If not, that sounds like a libtool bug? But that's irrelevant here...simply need to restrict passing a -R flag to platforms where it is legal. I think libtool's autoconf pieces might already determine this internally (it does seem to know about -rpath semantics), but otherwise could use a platform test and only pass it on linux or pass it on "all but darwin" or somesuch.
I asked a libtool friend, who said that libtool's configure doesn't test for support of this flag, but that the following configure.in block would work: ># pogma's -Wl,-R check >AC_PROG_CC >AC_CACHE_CHECK([if we can use -Wl,-R,/foo],[dm_cv_dash_r_ok], > [save_LDFLAGS="${LDFLAGS}" > LDFLAGS="-Wl,-R,/nothinghere ${LDFLAGS}" > >AC_LINK_IFELSE([AC_LANG_PROGRAM([],[])],[dm_cv_dash_r_ok=yes],[dm_cv_dash_r_ok=no]) > LDFLAGS="$save_LDFLAGS" > ]) then could do something like: if test "${dm_cv_dash_r_ok} = "yes"; then PRIVLIBDIR_R_FLAG='-Wl,-R${privlibdir}' fi AC_SUBST(PRIVLIBDIR_R_FLAG) and that flag would only get pasted into @PRIVLIBDIR_R_FLAG@ in the .pc if the local platform supports it. I can't test because my platform *doesn't* support it.