bug#54020: Impossible to pass `-no-suppress` to `libtool` via automake files

[Mike Frysinger]

On 17 Jan 2024 00:11, Mike Frysinger wrote:
> On 15 Feb 2022 23:03, Damian Szuberski wrote:
> > A standard `libtool` invocation line generated by automake looks like:
> > ```
> > LTCOMPILE = $(LIBTOOL) $(AM_V_lt) --tag=CC $(AM_LIBTOOLFLAGS) \
> > $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) \
> > $(DEFAULT_INCLUDES) $(INCLUDES) $(AM_CPPFLAGS) $(CPPFLAGS) \
> > $(AM_CFLAGS) $(CFLAGS)
> > ```
> > Sometimes files compiled using the method above make the compiler emit
> > errors. Those errors are suppressed by default which makes troubleshooting
> > impossible. `libtool` has a command line option, `-no-suppress` which can
> > be used to make the compiler verbose. Unfortunately, there is no way to
> > inject that option since `libtool` demands that it comes after
> > `--mode=compile`. `AM_LIBTOOLFLAGS` nor `LIBTOOLFLAGS` cannot be used for
> > that purpose since "it is too early", according to `libtool`'s command line
> > parser. It is somewhat possible to use `AM_CFLAGS` for that purpose but
> > then it breaks modes other than `--mode=compile`.
> 
> i was reading the libtool manual today and was reminded that libtool processes
> some standard options straight out of the wrapped command rather than forcing
> you to split things up.  for example, it detects the -o option and parses 
> that.
> then i was reminded that when passing libtool linker options like 
> -no-undefined,
> you simply add them to the standard LDFLAGS.
> 
> which is to say, options like -no-suppress do not need exact placement.  put 
> it
> in existing CFLAGS variables as makes sense for your target.
>   AM_CFLAGS = -no-suppress
> or
>   libfoo_la_CFLAGS = $(AM_CFLAGS) -no-suppress
> and libtool should parse & discard it before invoking the underlying compiler.

the Automake manual has libtool examples for general & linking flags,
but nothing for compiling.  we could add some to make it more clear.
-mike


signature.asc
Description: PGP signature

bug#54020: Allow user-defined libtool options

[Bogdan via Bug reports for Automake]

Mike Frysinger , 2024-01-17 06:04:

On 14 Jan 2024 18:55, Bogdan wrote:

Mike Frysinger , 2024-01-14 02:06:

On 13 Jan 2024 22:29, Bogdan wrote:

Mike Frysinger , 2024-01-13 07:19:

On 15 Mar 2023 17:31, Bogdan wrote:

 Another patch from my side. This one makes it possible for users to
pass additional options to libtool in 'compile' mode. Fixes #54020.

 Added documentation and a test case including the '-no-suppress'
option. All tests with 'lt' or 'libtool' in the name pass.

 Feel free to rename the variables, I just came up with the names
LTCOMPILE_PREFLAGS and LTCOMPILE_POSTFLAGS, reflecting the positions
where the variables are put and the mode they're used in.


why do we need LTCOMPILE_POSTFLAGS ?  isn't that just after the compile
command ?  $obj_compile expands into e.g.
\$(CC) @cpplike_flags \$(AM_CFLAGS) \$(CFLAGS)

so if someone wants to add flags to C/etc..., they already have knobs
to turn.

which means this would simplify by only having one variable right ?
AM_LTCOMPILE_FLAGS


Seems so, at least for now. At least for C compilers. At least until
$obj_compile becomes something else in the future or something more,
or even now contains (or will contain) other options after $(CFLAGS)
on the command line when using other compilers.
For simplicity - yes, one flag like AM_LTCOMPILE_FLAGS should
suffice, at least now, as it seems. I've made pre- and post- flags for
better flexibility, to be future-proof.


i don't see there ever being a future need here.  libtool's design is that
it stops processing after the first non-argument after --mode=compile, and
everything else is a wrapped command which libtool blindly executes.  those
commands should have their own set of flags, and libtool is irrelevant at
that point, so giving it a libtool-centric name that is used regardless of
the wrapped command will never make sense.


   And that's probably something I wasn't aware of. If it's
dead/useless code, feel free to remove this part. The fact that I made
a patch doesn't mean that it must be applied as a whole and never changed.


the point of posting patches for review is to review and discuss and learn.
maybe you saw something or an angle that i missed.  i don't know everything.
-mike



 No problem. I hope I didn't sound rude or something, because that
wasn't the purpose. My mail was (supposed to be) completely neutral. I
don't get angry or something if someone reviews my patch, or modifies
it, or even completely rejects it.
 I don't know everything either and I my only purpose with adding 2
flags was to be just-in-case future-proof (so that we don't get a
similar report some time later, saying "can you make a flag like that,
because I need one after the invocation as well?", and not to support
something that already exists.

--
Regards - Bogdan ('bogdro') D. (GNU/Linux & FreeDOS)
X86 assembly (DOS, GNU/Linux):http://bogdro.evai.pl/index-en.php
Soft(EN): http://bogdro.evai.pl/soft  http://bogdro.evai.pl/soft4asm
www.Xiph.org  www.TorProject.org  www.LibreOffice.org  www.GnuPG.org