Re: Sourceware mitigating and preventing the next xz-backdoor

[Boris Kolpackov]

Martin Uecker  writes:

> Do we really still need complex build systems such as autoconf? Are
> there still so many different configurations with subtle differences
> that every single feature needs to be tested individually by running
> code at build time?

We have taken the alternative approach in build2. Specifically, instead
of dynamic compilation/linking tests (which can fail for all kinds of
reasons besides the absent feature), we use static expected values
based on the platform/compiler macro checks. For example, if we are
compiling with glibc and the version is 2.38 or later, then we know
the strl*() function family is available:

https://github.com/build2/libbuild2-autoconf

We currently have ~200 checks and have built quite a bit of software
using this approach (including Qt classic libraries and all their
dependencies) on the mainstream platforms (Linux, Windows, Mac OS,
FreeBSD).

RE: Updated Sourceware infrastructure plans

[Aktemur, Tankut Baris via Gcc]

On Tuesday, April 23, 2024 5:26 PM, Simon Marchi wrote:
> On 2024-04-23 11:08, Tom Tromey wrote:
> >> Indeed.  Though Patchwork is another option for patch tracking, that
> >> glibc seem to be having success with.
> >
> > We tried this in gdb as well.  It was completely unworkable -- you have
> > to manually clear out the patch queue, meaning it's normally full of
> > patches that already landed.  I know glibc has success with it, but I
> > wouldn't consider it for gdb unless it gained some new abilities.
> 
> The thing that Gerrit excels at is tracking the different versions of a
> given patch, being able to easily diff versions, etc.  And then mark a
> patch as merged once it's committed to master.

FWIW, I think this is a very useful feature.  I used gitlab and github, too;
their revision tracking is far worse.

Regards
-Baris

> Patchwork doesn't have this capability built-in (AFAIK).  You can try to
> do some automation, but I doubt that any system based solely on getting
> patches from a mailing list can ever be as good as something like Gerrit
> for this.
> 
> Simon



Intel Deutschland GmbH
Registered Address: Am Campeon 10, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0, www.intel.de 
Managing Directors: Christin Eisenschmid, Sharon Heck, Tiffany Doon Silva  
Chairperson of the Supervisory Board: Nicole Lau
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928

Re: Sourceware mitigating and preventing the next xz-backdoor

[Andreas Schwab]

On Apr 24 2024, Boris Kolpackov wrote:

> https://github.com/build2/libbuild2-autoconf

Welcaome back, imake.

-- 
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

[RISC-V] Support for trapping math in RISC-V

[Krishna Narayanan via Gcc]

Hi all,
Is the RISC-V community planning to add support for trapping math in RISC-V
in the near future!?
This LLVM thread
https://discourse.llvm.org/t/trapping-math-for-risc-v/72168/7  suggests a
software emulation of traps, is the GNU team also on similar lines to this
implementation or has some different views.

Thanks,
Krishna Narayanan.

[Regarding GCOV].gcda:stamp mismatch with notes file

[Gejoe Daniel via Gcc]

Hi team,
The following is my query posted but would need more inputs :
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114751

The gcov tool which was working so far seems to fail with our latest branch 
where gcc is 11.4.0 and hence we wanted to sort this out by getting the right 
help as early as possible.

Awaiting prompt reply.

Thanks to the GCC team for all the help !

Regards,
Gejoe