From owner-freebsd-ports-bugs@FreeBSD.ORG Wed Jun 11 17:49:52 2014 Return-Path: Delivered-To: freebsd-ports-bugs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E5BE0A6C for ; Wed, 11 Jun 2014 17:49:51 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C72DF21A1 for ; Wed, 11 Jun 2014 17:49:51 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.8/8.14.8) with ESMTP id s5BHnpCV096776 for ; Wed, 11 Jun 2014 18:49:51 +0100 (BST) (envelope-from bz-noreply@freebsd.org) From: bz-noreply@freebsd.org To: freebsd-ports-bugs@FreeBSD.org Subject: [Bug 190941] New: [exp-run] Mk/Uses/libtool.mk: eliminate relinking Date: Wed, 11 Jun 2014 17:49:51 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports Tree X-Bugzilla-Component: Infrastructure X-Bugzilla-Version: Latest X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: tijl@FreeBSD.org X-Bugzilla-Status: Needs Triage X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-ports-bugs@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status bug_severity priority component assigned_to reporter attachments.created Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-ports-bugs@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Ports bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jun 2014 17:49:52 -0000 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.