bug#54020: Impossible to pass `-no-suppress` to `libtool` via automake files
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.
for example:
$ echo 'main(){}' > test.c
$ libtool --tag=CC --mode=compile gcc -c -Wall test.c -no-suppress
libtool: compile: gcc -c -Wall -Wextra test.c -fPIC -DPIC -o .libs/test.o
test.c:1:1: warning: return type defaults to 'int' [-Wimplicit-int]
1 | main(){}
| ^~~~
libtool: compile: gcc -c -Wall -Wextra test.c -o test.o
test.c:1:1: warning: return type defaults to 'int' [-Wimplicit-int]
1 | main(){}
| ^~~~
-mike
signature.asc
Description: PGP signature
bug#54020: Allow user-defined libtool options
On 16 Jan 2024 22:43, Roumen Petrov wrote: > Mike Frysinger wrote: > > 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. > > [SNIP] > > Libtool support options that allows user to pass flags either or compiler or > linker. > I cannot see needs for more flags and variables. sorry, but i'm not following what you're trying to say here -mike signature.asc Description: PGP signature
bug#54020: Allow user-defined libtool options
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 signature.asc Description: PGP signature
bug#68274: automake 1.16j nonnumerical version confuses scripts
"Zack Weinberg" writes:
> On Sun, Jan 14, 2024, at 1:49 AM, Mike Frysinger wrote:
>> On 13 Jan 2024 15:58, Karl Berry wrote:
>>> Another alternative: when this came up 30-odd years ago, rms changed the
>>> GNU maintainers doc to suggest x.y.90, .91, etc. for pretests. Doing
>>> that would at least have the benefit of following a recommendation, and
>>> as a side effect, would also fix jami's assumption (poor practice though
>>> it is, IMHO).
>>> https://gnu.org/prep/maintain/html_node/Test-Releases.html#Test-Releases
>>>
>>> Doing an ls -R on alpha (fp:/srv/data/ftp-mirror/alpha/gnu), it seems
>>> (rough guess with some grep counting) the .90 convention is by far the
>>> most common approach (a couple thousand), followed by the suffix letter
>>> a la automake (~750 releases), followed by -rc (~360). -hexid and -date
>>> are both trailing the field. Other random conventions also present.
>>>
>>> It all feels like bikeshedding to me, so my inclination is to do
>>> nothing. If we do change, I think we should use .90. --best, karl.
>>
>> using .90 is certainly better than single-letters. if you're fine with
>> it, then let's switch.
>
> For what it's worth, I had planned to switch Autoconf, starting with the
> next release, to use *some* version numbering scheme for beta releases
> that sorts correctly according to things like strverscmp() and
> dpkg --compare-versions. The "append a letter to the version number
> intended for the final release" convention makes these algorithms sort
> the betas *after* the release, which is backwards.
>
> My plan *was* to append letters to the version number for the *previous*
> release, with a gap (e.g. 2.72{j,k,...} would be prereleases for 2.73),
> which I think is what Automake is doing now) but I like .9x version numbers
> better because it's more common (as you observed) and therefore more likely
> to be understood at sight. I'd actually forgotten that .9x versions were
> an official GNU recommendation.
>
I was planning on finally filing a bug for this because I couldn't really
package the latest automake pre-release given it totally breaks our
sorting (and afaik sorting in every other PM too).
We're used to .9x and it works fine for us.
thanks,
sam
bug#68274: automake 1.16j nonnumerical version confuses scripts
On Sun, Jan 14, 2024, at 1:49 AM, Mike Frysinger wrote:
> On 13 Jan 2024 15:58, Karl Berry wrote:
>> Another alternative: when this came up 30-odd years ago, rms changed the
>> GNU maintainers doc to suggest x.y.90, .91, etc. for pretests. Doing
>> that would at least have the benefit of following a recommendation, and
>> as a side effect, would also fix jami's assumption (poor practice though
>> it is, IMHO).
>> https://gnu.org/prep/maintain/html_node/Test-Releases.html#Test-Releases
>>
>> Doing an ls -R on alpha (fp:/srv/data/ftp-mirror/alpha/gnu), it seems
>> (rough guess with some grep counting) the .90 convention is by far the
>> most common approach (a couple thousand), followed by the suffix letter
>> a la automake (~750 releases), followed by -rc (~360). -hexid and -date
>> are both trailing the field. Other random conventions also present.
>>
>> It all feels like bikeshedding to me, so my inclination is to do
>> nothing. If we do change, I think we should use .90. --best, karl.
>
> using .90 is certainly better than single-letters. if you're fine with
> it, then let's switch.
For what it's worth, I had planned to switch Autoconf, starting with the
next release, to use *some* version numbering scheme for beta releases
that sorts correctly according to things like strverscmp() and
dpkg --compare-versions. The "append a letter to the version number
intended for the final release" convention makes these algorithms sort
the betas *after* the release, which is backwards.
My plan *was* to append letters to the version number for the *previous*
release, with a gap (e.g. 2.72{j,k,...} would be prereleases for 2.73),
which I think is what Automake is doing now) but I like .9x version numbers
better because it's more common (as you observed) and therefore more likely
to be understood at sight. I'd actually forgotten that .9x versions were
an official GNU recommendation.
zw
bug#54020: Allow user-defined libtool options
Mike Frysinger wrote: 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. [SNIP] Libtool support options that allows user to pass flags either or compiler or linker. I cannot see needs for more flags and variables. Regards, Roumen Petrov
