From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from hamza.pair.com (hamza.pair.com [209.68.5.143]) by sourceware.org (Postfix) with ESMTPS id 5875E3858D20 for ; Sun, 28 Apr 2024 10:24:13 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 5875E3858D20 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=pfeifer.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=pfeifer.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 5875E3858D20 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=209.68.5.143 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1714299855; cv=none; b=YmupP7OdVb5ZS/DlpeOQPPq8RYm8q7rMe4vO1CvPdqNAlxBXoKqgDJeNAgp6HhGgPDtrKPiDYfE8SFB/awSlwlqn0lFb64hEQBjnhMejDP4wQ3IS0uWlsTZjfa3P+YM2+tF/TuPidkuV5xg5XdvOdFK5rnVhP8XsL+qnBPn+Mhs= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1714299855; c=relaxed/simple; bh=80tzaaIAS9p4NdS+NzpVgS/Xm52ZOgJlTrjSbl6nchg=; h=Date:From:To:Subject:Message-ID:MIME-Version; b=Tp/uONyY5cRoSJwarciD15QHNfBp7q/X8b2okUtGZeL0lNqZsdM0sSPtpJqp3MfXJp/j6UDMkVkg/v4y6wE+LtWSmuaRe8O/YqqbU/9EhQBgwJHeI65pCLXm5g9c1U3+/ixJjHDmCuCYfcYK8bJhdrJ3CGYshBGHY1oDojkA6So= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from hamza.pair.com (localhost [127.0.0.1]) by hamza.pair.com (Postfix) with ESMTP id 71FA533E8E; Sun, 28 Apr 2024 06:24:12 -0400 (EDT) Received: from daya.localdomain (188-23-56-169.adsl.highway.telekom.at [188.23.56.169]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by hamza.pair.com (Postfix) with ESMTPSA id AE53633E8D; Sun, 28 Apr 2024 06:24:11 -0400 (EDT) Date: Sun, 28 Apr 2024 12:24:09 +0200 (CEST) From: Gerald Pfeifer To: Jonathan Wakely cc: Andreas Tobler , Lorenzo Salvadore , gcc@gcc.gnu.org Subject: Re: GCC testing on FreeBSD In-Reply-To: Message-ID: <866dda5e-c983-ac16-de71-05b685536cd7@pfeifer.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Scanned-By: mailmunge 3.11 on 209.68.5.143 X-Spam-Status: No, score=-3.7 required=5.0 tests=BAYES_00,KAM_DMARC_STATUS,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Hi Jonathan, On Fri, 26 Apr 2024, Jonathan Wakely wrote: > How are you testing on FreeBSD? > > When I build GCC trunk on FreeBSD 14.0 and try to run the libstdc++ > testsuite it fails due to lots of these errors: > > Excess errors: > /usr/local/bin/ld: /tmp//ccev946q.o: relocation R_X86_64_32 against > symbol `_ZTIN10__cxxabiv115__forced_unwindE@@CXXABI_1.3.2' can not be > used when making a PDE object; recompile with -fPIE > /usr/local/bin/ld: failed to set dynamic section sizes: bad value my first reaction was to recommend using binutils instead of /usr/bin/ld which is LLD 16.0.6 or similar (since a while ago FreeBSD switched to that toolchain as part of the base system). My nightly tester has been using GNU ld since # 2012-03-11 Configure using --with-as=$localbase/bin/as and # --with-ld=$localbase/bin/ld on *.freebsd.org. in the script invoked by cron, even before FreeBSD made that switch. Seeing /usr/local/bin/ld in the error message it appears you are doing that already, though? > Which suggests that -fPIE is missing from the default test flags. > > Have you seen this? Do you do something locally to work around it? All I have in terms of adjustments to the FreeBSD systems I build on via that script are the following CONFIGUREFLAGS="--with-gmp=$LOCALBASE --with-as=$LOCALBASE/bin/as $CONFIGUREFLAGS" LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$LOCALBASE/lib PATH=$LOCALBASE/bin:$PATH where LOCALBASE looks like it would be /usr/local in your case. Nothing explicit around PIE there. Looking at the logs of a serialized build I triggered manually where I remove the --with-ld configure option, I see checking linker PIE support with copy reloc... no checking for -fno-PIE option... yes checking for -no-pie option... yes and then build invocations like c++ -std=c++11 -fno-PIE -c ... during all-stage1-target-libgcc which ultimately fails with - mystery?! - ld: error: unable to find library -lc collect2: error: ld returned 1 exit status gmake[3]: *** [Makefile:1005: libgcc_s.so] Error 1 (Disclaimer: all my tests on FreeBSD 13.2, not FreeBSD 14 as in your case.) Looking at the lang/gcc* ports that I maintained for two decades until Lorenzo (copied now) kindly took them over two years ago I see the following change among others for newer versions: % git show b6a5871a0cf40 commit b6a5871a0cf40dfc194217704e2dc03e2e91fb62 Author: Lorenzo Salvadore Date: Fri Feb 3 20:12:49 2023 +0100 lang/gcc10: Mark PIE_UNSAFE Building the port with WITH_PIE fails if the BOOTSTRAP option is enabled. Mark PIE_UNSAFE when this option is enabled until a better solution is found. PR: 268901 where https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268901 is the PR referenced. PIE_UNSAFE=yes in a port's Makefile (the equivalent to a spec file in RPM land) is used as follows in ports/Mk/Features/pie.mk: . if !defined(PIE_UNSAFE) PIE_CFLAGS?= -fPIE -fPIC CFLAGS+= ${PIE_CFLAGS} CXXFLAGS+= ${PIE_CFLAGS} LDFLAGS+= -pie STATIC_PIE_ARGS+= -static-pie . endif You are not using the Ports Infrastructure, I believe, so the above does not directly apply, may provide some additional background, though? Hope this helps - and please chime in Lorenzo and Andreas! Gerald