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

--=-=-=
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

Nick Bowler <[email protected]> writes:

> On 2024-08-15 12:13, Sam James wrote:
>> Ileana Dumitrescu <[email protected]> writes:
>>> However, you could also just specify '-no-suppress' when compiling
>>> rather than changing the default behaviour.
>>=20
>> (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=3D-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?=20
>
> 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

--=-=-=
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iOUEARYKAI0WIQQlpruI3Zt2TGtVQcJzhAn1IN+RkAUCZr48518UgAAAAAAuAChp
c3N1ZXItZnByQG5vdGF0aW9ucy5vcGVucGdwLmZpZnRoaG9yc2VtYW4ubmV0MjVB
NkJCODhERDlCNzY0QzZCNTU0MUMyNzM4NDA5RjUyMERGOTE5MA8cc2FtQGdlbnRv
by5vcmcACgkQc4QJ9SDfkZCuUgD9FaJc7OIcRwEYtuDhT1cXBivonpgiO/Xvmpwh
uBQ7rcABAIBjtGEz8YX1JeeK18JS5VkeBP5j8IP/JuWymU9wjtcJ
=gW68
-----END PGP SIGNATURE-----
--=-=-=--