From nobody Wed Sep 11 14:10:05 2024 X-Original-To: ports-bugs@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4X3jBz55qzz5WmJ3 for ; Wed, 11 Sep 2024 14:10:19 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R11" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4X3jBz35nhz4smG for ; Wed, 11 Sep 2024 14:10:19 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1726063819; a=rsa-sha256; cv=none; b=HXjzmv3w+OFGIznDRON4A8ROVktmbRBRyUYLw9amRdFzPYkcWkJfG9P+TLr3mGRg6YbDrx JE++QxnB5PvJ/34mvoCc9QCVDEAMVls78NglZ/Kf7/QZUGRMOb2ajr8v7mvsaryRhv39Ok i5aqSPfSTjJ+ZB3fGYCAX77Rh6qK5yGVP3o51OpyHWUHNYPih+C42Lptmte5Er3EokEvVc AkkvfYJYwqA0TcJ+WKUNpwFLGtjbVyaLA7H3hPuhOHQu+K/md5pQ+5wdyWOKGD7UEDv5kL ssVkjkOMrYcPRm94d/ygHT76f22ITB7zL3QmWUMIVAiS1atForBEo5ZNdB5WHg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1726063819; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=pKiF/HGYl6BmbvOJaBPnl2r2ZoWwbSCqh3Bra2sExf8=; b=FIR0tG9oea/eTft+NJ5Qy/v0bw1o8xezSARLPzMXZFQvph1F8JllAeBkuAipK2c4SVeiqF cHzXYvvwu1CXbtb8O2TCwaTmUSbq26TpPQeAlc4qz3E7yD5VBRXiu5PIaLUCOZISQx5pDn 33IY91zicoYECsOsz+N9Dfz/RDIwe7EgvGCJlhOF8P1mhvTgNp7nlVIuAEH8PIuMSyLWV7 YujAG8CdsLS+6fOmeeK4FY0cmluIKRfioohYCfU4A7EoiFnMz8YmRMinZJ6sU8mlGZT8bt tDZ3wIDzDPbzXd1gTkTtUY10d7LrN6VBigrCa2ao5XMXHg+HpAOKzL3N3rx/CA== Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4X3jBz2jn8zYdr for ; Wed, 11 Sep 2024 14:10:19 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 48BEAJfl092515 for ; Wed, 11 Sep 2024 14:10:19 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 48BEAJOn092493 for ports-bugs@FreeBSD.org; Wed, 11 Sep 2024 14:10:19 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: ports-bugs@FreeBSD.org Subject: [Bug 281440] devel/llvm18: -Wl,--version-script failing in 'configure' script tests / silent unexpected ABI changes Date: Wed, 11 Sep 2024 14:10:05 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: jcfyecrayz@liamekaens.com X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: brooks@FreeBSD.org X-Bugzilla-Flags: maintainer-feedback? X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status bug_severity priority component assigned_to reporter flagtypes.name Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated List-Id: Ports bug reports List-Archive: https://lists.freebsd.org/archives/freebsd-ports-bugs List-Help: List-Post: List-Subscribe: List-Unsubscribe: X-BeenThere: freebsd-ports-bugs@freebsd.org Sender: owner-freebsd-ports-bugs@FreeBSD.org MIME-Version: 1.0 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D281440 Bug ID: 281440 Summary: devel/llvm18: -Wl,--version-script failing in 'configure' script tests / silent unexpected ABI changes Product: Ports & Packages Version: Latest Hardware: Any OS: Any Status: New Severity: Affects Some People Priority: --- Component: Individual Port(s) Assignee: brooks@FreeBSD.org Reporter: jcfyecrayz@liamekaens.com Assignee: brooks@FreeBSD.org Flags: maintainer-feedback?(brooks@FreeBSD.org) Some ports that do configure script testing for support of --version-script= in the linker are now producing libraries that no longer have symbol versioning enabled for the libraries that are produced. some examples: security/libtasn1, security/p11-kit After updating a FreeBSD system from 13.2 to 13.4, I started seeing linking failures due to libraries that USED to have symbol versioning information t= hat now do not. 13.2's base C compiler was llvm15 and 13.4 has llvm18. Here is (basically) what the configure script is doing: % cat > conftest.map << eof VERS_1 { global: sym; }; VERS_2 { global: sym; } VERS_1; eof % cat > conftest.c << eof int main(void) { ; return0; } eof % cc -Wl,--version-script=3Dconftest.map -o dummy conftest.c clang15 had no problem with that, but clang18 does not like the undefined symbols: ld: error: version script assignment of 'VERS_1' to symbol 'sym' failed: sy= mbol not defined ld: error: version script assignment of 'VERS_2' to symbol 'sym' failed: sy= mbol not defined cc: error: linker command failed with exit code 1 (use -v to see invocation) As a result, the configure script disable symbol versioning, and the librar= ies that are produced no longer have the version definitions that are listed in= the linker script that would have been used if symbol versioning were enabled. This was noticed when ports were rebuilt without rebuilding their dependent ports when no ABI SHOULD have changed (e.g., changing man/ to share/man in security/libtasn1). The new lib that was built no longer had the version definitions from the linker script. And dependent libraries broke due to t= he unexpected ABI change as a result. For example: ld-elf.so.1: /usr/local/lib/libtasn1.so.6: version LIBTASN1_0_3 required by /usr/local/lib/libwebkit2gtk-4.0.so.37 One fix for this is to add -Wl,--undefined-version when doing the configure test (see for instance the recent heimdal linker failure in bug 275979). But I don't know all the ports that are affected. It was noticed (so far) = for security/p11-kit and security/libtasn1. If it is just those two, maybe it's manageable. It's worse (from a detection problem point of view) if the affected port doesn't even have a PORTREVISION bump but gets rebuilt for some other reason that causes the new versions of the libraries to get the ABI change without= the linker script symbols. Maybe the autoconf m4 scripts should be updated to produce a test that incl= udes using --undefined-version for the linker (or adds an attempt to try with --undefined-version when the first attempt fails without it) on a port by p= ort basis. It'd be nice to come up with a way to find ports that are now vulnerable th= is way, but don't fail to build (later failing at dynamic linking time). But I can't think of any particularly effective way to find such vulnerable ports. Maybe what would be helpful would be an ABI before/after check that ports maintainers (or even automation in stage-qa) could use to check for unexpec= ted ABI changes when doing a port update. Maybe something already exists in po= rts/ land? This is really a larger ABI compatibility assessment problem when updating a port / ports. Apologies for classifying this as a devel/llvm18 problem - it's not really.= It would help if I had a better grasp of the affected ports. I'll probably reclassify this after thinking some more (and getting some helpful thoughts= on the subject). If the audience that responds here has ideas about potential ways to address this so users are less likely to be blindsided by ABI changes, please offer suggestions. I guess I'm thinking the best solution is to come up with an automated way to detect ABI changes so at least it is easier to determine w= hen dependent ports need a PORTREVISION bump due to a potential breaking ABI change. --=20 You are receiving this mail because: You are the assignee for the bug.=