[Bug 190941] New: [exp-run] Mk/Uses/libtool.mk: eliminate relinking

[bz-noreply at freebsd.org]

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 at FreeBSD.org
          Reporter: tijl at 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.