* GCC testing on FreeBSD @ 2024-04-26 11:06 Jonathan Wakely 2024-04-28 10:24 ` Gerald Pfeifer 0 siblings, 1 reply; 8+ messages in thread From: Jonathan Wakely @ 2024-04-26 11:06 UTC (permalink / raw) To: Gerald Pfeifer, Andreas Tobler; +Cc: gcc Hi Gerald, Andreas, 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 Which suggests that -fPIE is missing from the default test flags. Have you seen this? Do you do something locally to work around it? Thanks, Jonathan ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: GCC testing on FreeBSD 2024-04-26 11:06 GCC testing on FreeBSD Jonathan Wakely @ 2024-04-28 10:24 ` Gerald Pfeifer 2024-04-28 10:32 ` Rainer Orth ` (2 more replies) 0 siblings, 3 replies; 8+ messages in thread From: Gerald Pfeifer @ 2024-04-28 10:24 UTC (permalink / raw) To: Jonathan Wakely; +Cc: Andreas Tobler, Lorenzo Salvadore, gcc 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 <salvadore@FreeBSD.org> 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: GCC testing on FreeBSD 2024-04-28 10:24 ` Gerald Pfeifer @ 2024-04-28 10:32 ` Rainer Orth 2024-04-28 13:39 ` Lorenzo Salvadore 2024-04-28 16:17 ` Jonathan Wakely 2 siblings, 0 replies; 8+ messages in thread From: Rainer Orth @ 2024-04-28 10:32 UTC (permalink / raw) To: Gerald Pfeifer; +Cc: Jonathan Wakely, Andreas Tobler, Lorenzo Salvadore, gcc Hi Gerald, > 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). right: some time ago I tried bootstrapping trunk on FreeBSD 14.0 myself, which was a very rough journey unfortunately. I've filed a number of PRs for the issues found. They should all be referenced in PR target/112959 install.tex needs updates on FreeBSD which is primarily a call for documention so the next unwary non-FreeBSD developer won't run into all the same known issues again. Rainer -- ----------------------------------------------------------------------------- Rainer Orth, Center for Biotechnology, Bielefeld University ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: GCC testing on FreeBSD 2024-04-28 10:24 ` Gerald Pfeifer 2024-04-28 10:32 ` Rainer Orth @ 2024-04-28 13:39 ` Lorenzo Salvadore 2024-04-28 17:19 ` Rainer Orth 2024-04-28 16:17 ` Jonathan Wakely 2 siblings, 1 reply; 8+ messages in thread From: Lorenzo Salvadore @ 2024-04-28 13:39 UTC (permalink / raw) To: Gerald Pfeifer; +Cc: Jonathan Wakely, Andreas Tobler, gcc On Sunday, April 28th, 2024 at 12:24, Gerald Pfeifer <gerald@pfeifer.com> wrote: > 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 Hi Gerald and Jonathan! I normally test every weekly GCC snapshots through the FreeBSD ports framework on Cirrus, so that all my tests are publicly accessible: http://cirrus-ci.com/github/lsalvadore/freebsd-ports/lang/gcc11-devel http://cirrus-ci.com/github/lsalvadore/freebsd-ports/lang/gcc12-devel http://cirrus-ci.com/github/lsalvadore/freebsd-ports/lang/gcc13-devel http://cirrus-ci.com/github/lsalvadore/freebsd-ports/lang/gcc14-devel And of course the cirrus configuration is public as well: https://github.com/lsalvadore/freebsd-ports/blob/lang/gcc11-devel/.cirrus.yml By the way, is it possible for FreeBSD to enter GCC's CI pipeline? Where would one start? I am willing to help of course. Cheers, Lorenzo Salvadore ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: GCC testing on FreeBSD 2024-04-28 13:39 ` Lorenzo Salvadore @ 2024-04-28 17:19 ` Rainer Orth 2024-04-28 18:38 ` Lorenzo Salvadore 0 siblings, 1 reply; 8+ messages in thread From: Rainer Orth @ 2024-04-28 17:19 UTC (permalink / raw) To: Lorenzo Salvadore via Gcc Cc: Gerald Pfeifer, Lorenzo Salvadore, Jonathan Wakely, Andreas Tobler Hi Lorenzo, > On Sunday, April 28th, 2024 at 12:24, Gerald Pfeifer <gerald@pfeifer.com> wrote: > >> 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 > > Hi Gerald and Jonathan! > > I normally test every weekly GCC snapshots through the FreeBSD ports > framework on Cirrus, so that all my tests are publicly accessible: > http://cirrus-ci.com/github/lsalvadore/freebsd-ports/lang/gcc11-devel > http://cirrus-ci.com/github/lsalvadore/freebsd-ports/lang/gcc12-devel > http://cirrus-ci.com/github/lsalvadore/freebsd-ports/lang/gcc13-devel > http://cirrus-ci.com/github/lsalvadore/freebsd-ports/lang/gcc14-devel > > And of course the cirrus configuration is public as well: > https://github.com/lsalvadore/freebsd-ports/blob/lang/gcc11-devel/.cirrus.yml this isn't particularly helpful if you just try to build upstream GCC for comparision with your own targets or to verify a patch of yours. Having to go hunting for configs like this if you're not a regular FreeBSD user is a no-no IMO. GCC trunk should either build out of the box or the quirks be documented in install.texi. Otherwise, non-FreeBSD developers will get frustrated and give up on the target, to the detriment both of their patches and the platform. Unfortunately, it's pretty common that targets keep necessary patches in some ports collection of their own (usually a different one per target) and neglect to submit them upstream. Rainer -- ----------------------------------------------------------------------------- Rainer Orth, Center for Biotechnology, Bielefeld University ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: GCC testing on FreeBSD 2024-04-28 17:19 ` Rainer Orth @ 2024-04-28 18:38 ` Lorenzo Salvadore 2024-04-29 12:21 ` Rainer Orth 0 siblings, 1 reply; 8+ messages in thread From: Lorenzo Salvadore @ 2024-04-28 18:38 UTC (permalink / raw) To: Rainer Orth Cc: Lorenzo Salvadore via Gcc, Gerald Pfeifer, Jonathan Wakely, Andreas Tobler On Sunday, April 28th, 2024 at 19:19, Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE> wrote: > > > Hi Lorenzo, > > > On Sunday, April 28th, 2024 at 12:24, Gerald Pfeifer gerald@pfeifer.com wrote: > > > > > 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 > > > > Hi Gerald and Jonathan! > > > > I normally test every weekly GCC snapshots through the FreeBSD ports > > framework on Cirrus, so that all my tests are publicly accessible: > > http://cirrus-ci.com/github/lsalvadore/freebsd-ports/lang/gcc11-devel > > http://cirrus-ci.com/github/lsalvadore/freebsd-ports/lang/gcc12-devel > > http://cirrus-ci.com/github/lsalvadore/freebsd-ports/lang/gcc13-devel > > http://cirrus-ci.com/github/lsalvadore/freebsd-ports/lang/gcc14-devel > > > > And of course the cirrus configuration is public as well: > > https://github.com/lsalvadore/freebsd-ports/blob/lang/gcc11-devel/.cirrus.yml > > > this isn't particularly helpful if you just try to build upstream GCC > for comparision with your own targets or to verify a patch of yours. > Having to go hunting for configs like this if you're not a regular > FreeBSD user is a no-no IMO. GCC trunk should either build out of the > box or the quirks be documented in install.texi. Otherwise, non-FreeBSD > developers will get frustrated and give up on the target, to the > detriment both of their patches and the platform. > > Unfortunately, it's pretty common that targets keep necessary patches in > some ports collection of their own (usually a different one per target) > and neglect to submit them upstream. I totally agree with you: upstreaming patches is important! It is not only for the upstream project itself, but for the target as well: having patches sitting in a ports collection also requires more maintainance, they require to be kept up to date with the upstream progresses. Unfortunately, it is not always possible to upstream a patch. Sometimes, patches are too specific to a target to be suitable for upstream. For example, smaller projects might be interested in supporting only very popular platforms and would not accept (or could not accept) the complexity of supporting a less known target. Hopefully this is not the case for GCC. Other times, developers do try to upstream a patch, but fail. This happened to myself in GCC too, when I was unable to get any attention to a patch I submitted, and could not do any better than keep the patch into the FreeBSD ports collection: https://gcc.gnu.org/pipermail/jit/2023q3/001642.html https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101491#c5 If you are able to help with this upstreaming, I would appreciate it a lot. Thanks. Cheers, Lorenzo Salvadore ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: GCC testing on FreeBSD 2024-04-28 18:38 ` Lorenzo Salvadore @ 2024-04-29 12:21 ` Rainer Orth 0 siblings, 0 replies; 8+ messages in thread From: Rainer Orth @ 2024-04-29 12:21 UTC (permalink / raw) To: Lorenzo Salvadore Cc: Lorenzo Salvadore via Gcc, Gerald Pfeifer, Jonathan Wakely, Andreas Tobler Hi Lorenzo, > I totally agree with you: upstreaming patches is important! It is not > only for the upstream project itself, but for the target as well: having > patches sitting in a ports collection also requires more maintainance, > they require to be kept up to date with the upstream progresses. indeed: e.g. some mechanical changes that affect your port can be dealt with easily when the developer in question finds the code in tree. Otherwise, this is only noticed during your next merge, possibly months later. > Unfortunately, it is not always possible to upstream a patch. Sometimes, > patches are too specific to a target to be suitable for upstream. Those are called hacks ;-) True: the code needs to be general to avoid the codebase slowly becoming unmaintainable. Maintainers keep the general code structure in mind, which may create more work for the submitter to develop a cleaner implementation. However, this ensures that the hack isn't broken subsequently and the code is more understandable to everyone. > For example, smaller projects might be interested in supporting only > very popular platforms and would not accept (or could not accept) > the complexity of supporting a less known target. > Hopefully this is not the case for GCC. I don't think so: the primary question is if the code is actively tested and maintained. And even so, we do have several ports in tree that have seen barely any maintenance in a long time. If they become a burden, this may lead to them being obsoleted and removed. > Other times, developers do try to upstream a patch, but fail. This > happened to myself in GCC too, when I was unable to get any > attention to a patch I submitted, and could not do any better > than keep the patch into the FreeBSD ports collection: > https://gcc.gnu.org/pipermail/jit/2023q3/001642.html > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101491#c5 It happens to all of us. It usually helps to include the maintainers in question in the Cc: I've often also had better success by pinging not in the patch submission thread (where the pings can become lost in the noise), but by posting a separate message to gcc-patches with subject and URL to the latest version and perhaps a short indication who's required to review the patch, also Cc'ing the relevant maintainers. > If you are able to help with this upstreaming, I would appreciate > it a lot. Thanks. Probably not much: for one I'm pretty busy with my own Solaris work, and I've also stopped testing on FreeBSD even with the issues I've found and developed workarounds for. Rainer -- ----------------------------------------------------------------------------- Rainer Orth, Center for Biotechnology, Bielefeld University ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: GCC testing on FreeBSD 2024-04-28 10:24 ` Gerald Pfeifer 2024-04-28 10:32 ` Rainer Orth 2024-04-28 13:39 ` Lorenzo Salvadore @ 2024-04-28 16:17 ` Jonathan Wakely 2 siblings, 0 replies; 8+ messages in thread From: Jonathan Wakely @ 2024-04-28 16:17 UTC (permalink / raw) To: Gerald Pfeifer; +Cc: Andreas Tobler, Lorenzo Salvadore, gcc [-- Attachment #1: Type: text/plain, Size: 3721 bytes --] On Sun, 28 Apr 2024, 11:24 Gerald Pfeifer, <gerald@pfeifer.com> wrote: > 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? > Yes, I'm using GNU ld. On IRC Andreas suggested that also using GNU objdump would solve my issue, but I haven't tried yet. > > 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 <salvadore@FreeBSD.org> > 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 > ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2024-04-29 12:21 UTC | newest] Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2024-04-26 11:06 GCC testing on FreeBSD Jonathan Wakely 2024-04-28 10:24 ` Gerald Pfeifer 2024-04-28 10:32 ` Rainer Orth 2024-04-28 13:39 ` Lorenzo Salvadore 2024-04-28 17:19 ` Rainer Orth 2024-04-28 18:38 ` Lorenzo Salvadore 2024-04-29 12:21 ` Rainer Orth 2024-04-28 16:17 ` Jonathan Wakely
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).