On Sunday, April 28th, 2024 at 19:19, Rainer Orth <r...@cebitec.uni-bielefeld.de> wrote:
> > > Hi Lorenzo, > > > On Sunday, April 28th, 2024 at 12:24, Gerald Pfeifer ger...@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
