Index | Thread | Search

From:
Stuart Henderson <stu@spacehopper.org>
Subject:
devel/libtool: remove path from LD= in generated script
To:
Brad <brad@comstyle.com>
Cc:
ports <ports@openbsd.org>
Date:
Thu, 21 Nov 2024 13:37:37 +0000

Download raw body.

Thread
Ports infrastructure writes a wrapper script to ${WRKDIR}/bin/ld if
variables are set which cause extra linker flags to be used - e.g.
USE_NOBTCFI, USE_NOEXECONLY, USE_WXNEEDED - or if a non-default
linker is used - USE_LLD.

Currently, the majority of ports don't have a linker script written
out because they don't use these flags.

I've just tried a test bulk build where I wanted to use linker flags,
so I added this to bsd.port.mk:

_LINKER_FLAGS += --threads=3

As this changes the linker flags for every port, it causes an ld wrapper
to be written (to WRKDIR/bin/ld) in many ports where it wasn't before.

This showed up that devel/libtool generates the gnu libtool script with
LD=/path/to/ld set to whichever ld was used during build _of libtool_.
So in the case of this test build, I had:

$ grep ^LD= /usr/local/bin/libtool | uniq
LD="/pobj/libtool-2.4.2/bin/ld"
LD=""

In this case, it will just totally fail if used to link another port
when libtool's wrkdir has been cleaned, making the problem more obvious.
I ran into it in comms/sigrok/libsigrok:

/usr/local/bin/libtool  --tag=CC --silent   --mode=link cc -std=c99 -fvisibility=hidden -Wall -Wextra -Wmissing-prototypes -I/usr/local/include -pthread -I/usr/local/include/libftdi1 -I/usr/local/include/hidapi -I/usr/local/include/libusb-1.0 -I/usr/local/include/glib-2.0 -I/usr/local/lib/glib-2.0/include -O2 -pipe    -o src/libdrivers.o src/libdrivers_head.la src/libdrivers.la  src/libdrivers_tail.la
/usr/local/bin/libtool: /pobj/libtool-2.4.2/bin/ld: not found

However, in the normal case _without_ my test diff, we have

$ grep ^LD= /usr/local/bin/libtool | uniq
LD="/usr/bin/ld"
LD=""

This still gives a slight problem - using the full path means the
wrapper (if present) is no longer called. So, if a port using
USE_LIBTOOL=gnu calls the libtool script to run the linker, afaict it
won't handle the linker-related USE_* variables mentioned above.

Does this make sense? I've built everything that uses USE_LIBTOOL=gnu
with a libtool package including the change.

Index: Makefile
===================================================================
RCS file: /cvs/ports/devel/libtool/Makefile,v
diff -u -p -r1.91 Makefile
--- Makefile	21 Sep 2023 09:49:59 -0000	1.91
+++ Makefile	21 Nov 2024 11:58:15 -0000
@@ -4,7 +4,7 @@ COMMENT-ltdl=	GNU libtool system indepen
 VERSION=	2.4.2
 DISTNAME=	libtool-${VERSION}
 PKGNAME-ltdl=	libltdl-${VERSION}
-REVISION=	2
+REVISION=	3
 CATEGORIES=	devel
 SITES=		${SITE_GNU:=libtool/}
 
@@ -41,6 +41,14 @@ RUN_DEPENDS-main=	devel/libtool,-ltdl
 
 pre-configure:
 	@cd ${WRKDIR}/bin && ln -sf /usr/bin/true g77
+
+# Don't include path to ld in the generated script.
+# This could override a ld wrapper in ${WRKDIR}/bin/ld used by
+# other ports using gnu libtool, and will be incorrect (including
+# pobj/libtool-*/bin/ld in the generated script) if an ld wrapper
+# ends up getting used in devel/libtool.
+post-build:
+	sed -i 's,^LD="/.*",LD="ld",' ${WRKBUILD}/libtool
 
 do-test:
 	@cd ${WRKDIR}/bin && ln -sf \
Index: pkg/PLIST-ltdl
===================================================================
RCS file: /cvs/ports/devel/libtool/pkg/PLIST-ltdl,v
diff -u -p -r1.8 PLIST-ltdl
--- pkg/PLIST-ltdl	11 Mar 2022 18:50:40 -0000	1.8
+++ pkg/PLIST-ltdl	21 Nov 2024 11:55:43 -0000
@@ -3,7 +3,7 @@ include/libltdl/lt_dlloader.h
 include/libltdl/lt_error.h
 include/libltdl/lt_system.h
 include/ltdl.h
-lib/libltdl.a
+@static-lib lib/libltdl.a
 lib/libltdl.la
 @lib lib/libltdl.so.${LIBltdl_VERSION}
 share/aclocal/