bug#54020: Allow user-defined libtool options
Hi, Mike Frysinger wrote: 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 In automake we could use target_ or AM_ to define flags. Patch does not add new if I understand properly. It is just to wrap "compile command". Simplified version of command when libtool is integrated with automake is LTCOMPILE=$(LIBTOOL) ... $(LIBTOOLFLAGS) --mode=compile $(CC) ... Patch propose more complex syntax i.e. ... --mode=compile $(PRE-FLAG) $(CC) ... $(POST-FLAGS) For flags supported by libtool mode we could use command ./libtool--mode=compile --help Some of arguments are controlled by configuration as goal of libtool is to hide complexity of library build and build of position independent code. The user may break this with unsuitable values in PRE-FLAG. What are other options : -no-suppress (1) i.e. do not redirect subsequent compilations to null device -Wc,... (2) Case (1) This is exceptional case. Remark: usual compilation is shared and static i.e. libtool shows errors from first. (a) With LIBTOOLFLAGS=-verbose flag we will could see commands. If second (static) build fail we could just copy & paste without redirection. (b) Also we could update Makefile and to set -no-suppress and to debug compilation failure. (c) We could configure with --disable-shared. As result static compilation is only one i.e. first and libtool will shows errors. So (a) or (b) or (c) ? Case (2) We could always run CC='cc my-flags' make -e or to use updated CFLAGS or This is also valid for linker. So what to do with $(POST-FLAGS) as we could pass flags at build time? It is not only for -Wc,... Also -Xcompiler should work fine. Regards, Roumen P.S. With other words CFLAGS='-Wall -W -W' ./configure --disable-shared ... replaces patch.
bug#54020: Allow user-defined libtool options
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
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#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
bug#54020: Allow user-defined libtool options
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.
-mike
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.
--
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
bug#54020: Allow user-defined libtool options
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. -mike signature.asc Description: PGP signature
bug#54020: Allow user-defined libtool options
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
-mike
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.
--
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
bug#54020: Allow user-defined libtool options
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 -mike signature.asc Description: PGP signature
bug#54020: Allow user-defined libtool options
Hi, Automakers!
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.
--
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.orgFrom 907c8b7913d1c577b722a24b24cdf9cd8e97755e Mon Sep 17 00:00:00 2001
From: Bogdan Drozdowski <>
Date: Wed, 15 Mar 2023 17:21:52 +0100
Subject: [PATCH] Add support for compile-mode extra libtool options
---
bin/automake.in| 6 +++--
doc/automake.texi | 8 +++
t/list-of-tests.mk | 1 +
t/lt_extraopts.sh | 55 ++
4 files changed, 68 insertions(+), 2 deletions(-)
create mode 100644 t/lt_extraopts.sh
diff --git a/bin/automake.in b/bin/automake.in
index f249064d5..c9e235938 100644
--- a/bin/automake.in
+++ b/bin/automake.in
@@ -1474,7 +1474,7 @@ sub handle_languages ()
my $ltverbose = define_verbose_libtool ();
my $obj_ltcompile =
"\$(LIBTOOL) $ltverbose $libtool_tag\$($ptltflags) \$(LIBTOOLFLAGS) "
- . "--mode=compile $obj_compile";
+ . "--mode=compile \$(LTCOMPILE_PREFLAGS) $obj_compile \$(LTCOMPILE_POSTFLAGS)";
# We _need_ '-o' for per object rules.
my $output_flag = $lang->output_flag || '-o';
@@ -6331,7 +6331,9 @@ sub define_compiler_variable
my $verbose = define_verbose_libtool ();
define_variable ("LT$var",
"\$(LIBTOOL) $verbose $libtool_tag\$(AM_LIBTOOLFLAGS)"
- . " \$(LIBTOOLFLAGS) --mode=compile $value",
+ . " \$(LIBTOOLFLAGS) --mode=compile "
+ . "\$(LTCOMPILE_PREFLAGS) $value "
+ . '$(LTCOMPILE_POSTFLAGS)',
INTERNAL);
}
define_verbose_tagvar ($lang->ccer || 'GEN');
diff --git a/doc/automake.texi b/doc/automake.texi
index ec14c5c4c..7138758dd 100644
--- a/doc/automake.texi
+++ b/doc/automake.texi
@@ -5607,6 +5607,14 @@ LIBTOOLFLAGS=--silent}, for instance. Note that the verbosity of
@command{libtool} can also be influenced by the Automake support
for silent rules (@pxref{Automake Silent Rules}).
+The @samp{LTCOMPILE_PREFLAGS} variable is the place to list
+additional libtool compile flags to be put right after
+@option{--mode=compile} on the command line (only when compiling).
+
+Similarly, the @samp{LTCOMPILE_POSTFLAGS} variable is the place to list
+additional libtool compile flags to be put at the end of the command line
+(only when compiling).
+
@node LTLIBOBJS, Libtool Issues, Libtool Flags, A Shared Library
@subsection @code{LTLIBOBJS} and @code{LTALLOCA}
@cindex @code{LTLIBOBJS}, special handling
diff --git a/t/list-of-tests.mk b/t/list-of-tests.mk
index 6f25f0494..2bff2771c 100644
--- a/t/list-of-tests.mk
+++ b/t/list-of-tests.mk
@@ -685,6 +685,7 @@ t/ltinstloc.sh \
t/ltlibobjs.sh \
t/ltlibsrc.sh \
t/ltorder.sh \
+t/lt_extraopts.sh \
t/m4-inclusion.sh \
t/maintclean.sh \
t/maintclean-vpath.sh \
diff --git a/t/lt_extraopts.sh b/t/lt_extraopts.sh
new file mode 100644
index 0..d26f4e689
--- /dev/null
+++ b/t/lt_extraopts.sh
@@ -0,0 +1,55 @@
+#! /bin/sh
+# Copyright (C) 2023 Free Software Foundation, Inc.
+#
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 2, or (at your option)
+# any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program. If not, see
