Re: [PATCH] ltmain.in: don't suppress output for PIC compilations

[Sam James]

Nick Bowler <nbowler@draconx.ca> writes:

> On 2024-08-15 12:13, Sam James wrote:
>> Ileana Dumitrescu <ileanadumitrescu95@gmail.com> writes:
>>> However, you could also just specify '-no-suppress' when compiling
>>> rather than changing the default behaviour.
>> 
>> (Is there a way to do this globally? If I put it in CFLAGS globally,
>> won't this break if libtool isn't used for a package, given GCC or Clang
>> will see it and bail out?)
>
> Automake provides LIBTOOLFLAGS and AM_LIBTOOLFLAGS for this kind of
> purpose but unfortunately it is not in the right position to pass
> mode-specific options like -no-suppress.
>
> I think it would be a big improvement to allow most mode-specific options
> to appear earlier on the libtool command line.  Then you could just do
>
>   make LIBTOOLFLAGS=-no-suppress
>
> and it'd work.

Ah, thanks. This is a good idea.

>
>> I really feel like the current behaviour is unexpected and surprising,
>> and perhaps it was based on the (wrong) idea that the -fPIC vs non-PIC
>> build will produce identical warnings and if one fails, the other will
>> fail, but that's not true at least with modern compilers.
>
> Can we fix the compilers instead?  Why does PIC compilation suppress
> warnings?  That behaviour seems unexpected and surprising.

Because PIC can substantially affect generated output. Not only that, as
in the GCC bug I linked to, this behaviour hid a compiler crash.

The same thing could be true if an error is only emitted without PIC.

>
>> That's the part I want to discuss -- does anyone actually think the
>> suppression is still a good idea? 
>
> Duplicate output sounds very annoying so yes, I think it is a good idea
> to suppress duplicate output.

More annoying to have an error suppressed that is not obvious to debug,
especially if one isn't aware of this behaviour.

>
> If you change the default, maybe just print the differences on the
> second run.  This might be as simple as just running diff on the
> output of both runs.

Yeah, that might be a good compromise.

>
> Cheers,
>   Nick

signature.asc
Description: PGP signature