Date: Wed, 11 Jun 2014 17:49:51 +0000 From: bz-noreply@freebsd.org To: freebsd-ports-bugs@FreeBSD.org Subject: [Bug 190941] New: [exp-run] Mk/Uses/libtool.mk: eliminate relinking Message-ID: <bug-190941-13@https.bugs.freebsd.org/bugzilla/>
next in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=190941 Bug ID: 190941 Summary: [exp-run] Mk/Uses/libtool.mk: eliminate relinking Product: Ports Tree Version: Latest Hardware: Any OS: Any Status: Needs Triage Severity: Affects Some People Priority: --- Component: Infrastructure Assignee: freebsd-ports-bugs@FreeBSD.org Reporter: tijl@FreeBSD.org Created attachment 143686 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=143686&action=edit patch During staging libtool may relink libA when it links to another library in the work directory libB. The reason is that libA created during build phase has its runpath set to the location of libB in the work directory. This allows running an executable that links to libA from within the work directory. The relink removes this extra runpath. Executables that link to a library in the work directory would normally also need to have their runpath set to allow running them from the work directory, but instead libtool creates a wrapper script that runs the real executable with LD_LIBRARY_PATH set to the location of the library. When libtool relinks libA it replaces "libB.la" on the linker command line with "-L${STAGEDIR}${PREFIX}/lib -lB" with the intention to link to the libB in the stage directory but this -L flag isn't necessarily the first so another libB may be linked instead. For instance, there may be "libC.la" on the linker command line before "libB.la" and the dependency_libs field in libC.la may contain "-L/usr/local/lib -lintl" because it uses gettext. In this case libB from /usr/local/lib may be picked up. Rather than fixing the order of these -L flags which isn't always possible I think, the attached patch eliminates relinking by modifying ltmain.sh. The first sed command prevents that .la files contain a relink_command so they will never be relinked. The second sed command makes sure that libraries don't get the extra runpath during build phase. This should still allow running executables that link to these libraries from the work directory because due to libtool overlinking the executables will link to all libraries they depend on and any library from the work directory will have its location added to LD_LIBRARY_PATH by the executables' wrapper scripts. An exp-run is needed to make sure this is really the case. These sed commands apply to libtool versions 1.4 and up. It doesn't look like earlier versions ever relink libraries. (This fixes building devel/apr1 in unclean environments.) -- You are receiving this mail because: You are the assignee for the bug.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-190941-13>