On Sun, Jan 08 2023, Jeremie Courreges-Anglas <j...@wxcvbn.org> wrote:
[...] >> https://wxcvbn.org/~jca/build-failures/amd64-clang/2023-01-03/net/openvpn-auth-ldap.txt > [patch] > Incorrect LDFLAGS > ===> making all in src > gmake[1]: Entering directory > '/usr/ports/pobj/openvpn-auth-ldap-2.0.4/build-amd64/src' > ../tools/lemon > -T/usr/ports/pobj/openvpn-auth-ldap-2.0.4/openvpn-auth-ldap-auth-ldap-2.0.4/tools/lempar.c > -m -q > /usr/ports/pobj/openvpn-auth-ldap-2.0.4/openvpn-auth-ldap-auth-ldap-2.0.4/src/TRConfigParser.lemon > -OTRConfigParser.m > gmake[1]: *** [../Mk/compile.mk:12: TRConfigParser.m] Segmentation fault > (core dumped) This one is funny. There is a behavior difference between lld 13: shannon /tmp$ cc -export-dynamic main.c ld: warning: cannot find entry symbol xport-dynamic; defaulting to 0x1660 shannon /tmp$ ./a.out hello, world! and lld 15: pbuild-amd64 /tmp$ cc -export-dynamic main.c ld: warning: cannot find entry symbol xport-dynamic; not setting start address pbuild-amd64 /tmp$ ./a.out Segmentation fault (core dumped) Why "cannot find entry symbol xport-dynamic"? Because ld.lld(1) interprets this as -e xport-dynamic, and -e (--entry) sets the entry point. Now in the example above, 0x1660 is the start of the .text section. It somehow works with a trivial hello world example, openvpn-auth-ldap seems to rely on it and it's quite possible that other ports rely on this behavior. I have committed the fix for openvpn-auth-ldap. -- jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
signature.asc
Description: PGP signature
