In Gentoo and probably other downstream distributions we let package management to manage the flags
Signed-off-by: Alon Bar-Lev alon.barlev@gmail.com --- configure.ac | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/configure.ac b/configure.ac index 00d2bf5d..379c021c 100644 --- a/configure.ac +++ b/configure.ac @@ -949,13 +949,16 @@ LIBS="$old_LIBS"
AC_SUBST(BENCH_LIBS)
+AC_ARG_VAR([GCC_DEBUG_FLAGS], [GCC debug flags]) +test -z "${GCC_DEBUG_FLAGS}" && GCC_DEBUG_FLAGS="-ggdb3" + # Set these flags *last*, or else the test programs won't compile if test x$GCC = xyes ; then # Using -ggdb3 makes (some versions of) Redhat's gcc-2.96 dump core if $CC --version | grep '^2.96$' 1>/dev/null 2>&1; then true else - CFLAGS="$CFLAGS -ggdb3" + CFLAGS="$CFLAGS ${GCC_DEBUG_FLAGS}" fi # FIXME: It would be better to actually test if this option works and/or is needed. # Or perhaps use -funsigned-char.
opt out overriding the libdir, in most cases downstream distribution is providing the correct one
Signed-off-by: Alon Bar-Lev alon.barlev@gmail.com --- configure.ac | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/configure.ac b/configure.ac index 379c021c..fb0b3c8c 100644 --- a/configure.ac +++ b/configure.ac @@ -339,7 +339,11 @@ case "$host_cpu" in ;; esac
-if test "x$ABI" != xstandard ; then +AC_ARG_ENABLE(libdir-abi-detection, + AC_HELP_STRING([--disable-libdir-abi-detection], [Disable libdir ABI detection]),, + [enable_libdir_abi_detection=yes]) + +if test "x$ABI" != xstandard -a "x${enable_libdir_abi_detection}" = "yes" ; then AC_MSG_NOTICE([Compiler uses $ABI-bit ABI. To change, set CC.]) if test "$libdir" = '${exec_prefix}/lib' ; then # Try setting a better default
Alon Bar-Lev alon.barlev@gmail.com writes:
opt out overriding the libdir, in most cases downstream distribution is providing the correct one
Signed-off-by: Alon Bar-Lev alon.barlev@gmail.com
configure.ac | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/configure.ac b/configure.ac index 379c021c..fb0b3c8c 100644 --- a/configure.ac +++ b/configure.ac @@ -339,7 +339,11 @@ case "$host_cpu" in ;; esac
-if test "x$ABI" != xstandard ; then +AC_ARG_ENABLE(libdir-abi-detection,
- AC_HELP_STRING([--disable-libdir-abi-detection], [Disable libdir ABI detection]),,
- [enable_libdir_abi_detection=yes])
+if test "x$ABI" != xstandard -a "x${enable_libdir_abi_detection}" = "yes" ; then AC_MSG_NOTICE([Compiler uses $ABI-bit ABI. To change, set CC.]) if test "$libdir" = '${exec_prefix}/lib' ; then # Try setting a better default
Isn't it clearer to use
./configure --prefix=/usr --libdir=/usr/lib
rather than
./configure --prefix=/usr --disable-libdir-abi-detection
The above if test "$libdir" = '${exec_prefix}/lib' disables the automatic choice if you use --libdir=foo, with foo different from the magic string '${exec_prefix}/lib'.
Alon Bar-Lev alon.barlev@gmail.com writes:
Signed-off-by: Alon Bar-Lev alon.barlev@gmail.com
configure.ac | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/configure.ac b/configure.ac index fb0b3c8c..5f2bf170 100644 --- a/configure.ac +++ b/configure.ac @@ -654,13 +654,13 @@ case "$host_os" in LIBNETTLE_FORLINK=libnettle.dylib LIBNETTLE_SONAME='libnettle.$(LIBNETTLE_MAJOR).dylib' LIBNETTLE_FILE='libnettle.$(LIBNETTLE_MAJOR).$(LIBNETTLE_MINOR).dylib'
- LIBNETTLE_LINK='$(CC) $(CFLAGS) -dynamiclib $(LDFLAGS) -install_name ${libdir}/$(LIBNETTLE_SONAME) -compatibility_version $(LIBNETTLE_MAJOR) -current_version $(LIBNETTLE_MAJOR).$(LIBNETTLE_MINOR)'
- LIBNETTLE_LINK='$(CC) $(CFLAGS) -dynamiclib $(LDFLAGS) -install_name $(libdir)/$(LIBNETTLE_SONAME) -compatibility_version $(LIBNETTLE_MAJOR) -current_version $(LIBNETTLE_MAJOR).$(LIBNETTLE_MINOR)' LIBNETTLE_LIBS=''
I don't understand this change. $(foo) and ${foo} have the same meaning in make (and this is quoted from the shell). A think it's an improvement to change ${} to $() here, for consistency with other nerby make references, but I take it you intend to do something more than an aesthetic change? Am I missing something?
Regards, /Niels
On Wed, Jun 26, 2019 at 2:40 PM Niels Möller nisse@lysator.liu.se wrote:
Alon Bar-Lev alon.barlev@gmail.com writes:
opt out overriding the libdir, in most cases downstream distribution is providing the correct one
Signed-off-by: Alon Bar-Lev alon.barlev@gmail.com
configure.ac | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/configure.ac b/configure.ac index 379c021c..fb0b3c8c 100644 --- a/configure.ac +++ b/configure.ac @@ -339,7 +339,11 @@ case "$host_cpu" in ;; esac
-if test "x$ABI" != xstandard ; then +AC_ARG_ENABLE(libdir-abi-detection,
- AC_HELP_STRING([--disable-libdir-abi-detection], [Disable libdir ABI detection]),,
- [enable_libdir_abi_detection=yes])
+if test "x$ABI" != xstandard -a "x${enable_libdir_abi_detection}" = "yes" ; then AC_MSG_NOTICE([Compiler uses $ABI-bit ABI. To change, set CC.]) if test "$libdir" = '${exec_prefix}/lib' ; then # Try setting a better default
Isn't it clearer to use
./configure --prefix=/usr --libdir=/usr/lib
rather than
./configure --prefix=/usr --disable-libdir-abi-detection
The above if test "$libdir" = '${exec_prefix}/lib' disables the automatic choice if you use --libdir=foo, with foo different from the magic string '${exec_prefix}/lib'.
You should not do this in autoconf, autoconf is already detecting everything that is required, having this code is highly non-standard and damage the default detection in many setups. No package should override any of the default directories.
Having said that, and to avoid backward compatibility, I would like to add a switch to disable this behavior completely and relay on the default logic of autoconf as expected.
Thanks!
Alon Bar-Lev alon.barlev@gmail.com writes:
You should not do this in autoconf, autoconf is already detecting everything that is required,
From which autoconf version? I'd be happy to require a recent autoconf
and drop this code if it's no longer needed. When this hack was added, it was the case that one or the other of
./configure CC='gcc -m32' && make && make install
or
./configure CC='gcc -m64' && make && make install
would install library files in the wrong directory, overwriting and damaging any correctly installed library previously installed in that place. On some systems, even
./configure && make && make install
would cause damage. Systems affected included any x86_64 gnu/linux system that (i) adhered to the linux hierarchy standard with 32-bit x86 libraries in /usr/local/lib (including gentoo, but not debian), and had a gcc installation defaulting to generating code for x86_64 (which I'd guess gentoo did too).
So the libdir detection is intended to help the user to not shot him/herself in the foot.
I don't know what current gentoo does. Debian's way of doing multiarch makes a lot of sense to me. You can then configure any autoconfed library, including nettle, with something like
--prefix=/usr --libdir='${prefix}/lib/${host}'
and nettle's special libdir default is not used.
Does recent autoconf do anything like that by default?
Having said that, and to avoid backward compatibility, I would like to add a switch to disable this behavior completely and relay on the default logic of autoconf as expected.
Would it make sense to have this automatic detection apply only when also the prefix is the default /usr/local? (Unfortunately, I don't know how a configure script can find out authoritatively if --prefix or --libdir were present on the command line, which is why I compare libdir to the default value instead.
And I really don't understand why you'd prefer a nettle specific --disable-... argument over the GNU standard --libdir=/usr/lib/whatever.
Regards, /Niels
On Wed, Jun 26, 2019 at 9:45 AM Niels Möller nisse@lysator.liu.se wrote:
... From which autoconf version? I'd be happy to require a recent autoconf and drop this code if it's no longer needed. When this hack was added, it was the case that one or the other of
Please NO. Don't require an updated Autotools version.
It is impossible to update Autotools on existing systems. I've never been able to do it on Linux, OS X and Solaris. The GCC Compile Farm maintainers were not able to do it on compile farm machines like AIX.
Stay with the basics. Things already work well. Allow a user to override libdir using standard options. Don't do fancy things that break builds.
Also see https://www.gnu.org/prep/standards/html_node/Directory-Variables.html.
Jeff
On Wed, Jun 26, 2019 at 4:53 PM Jeffrey Walton noloader@gmail.com wrote:
On Wed, Jun 26, 2019 at 9:45 AM Niels Möller nisse@lysator.liu.se wrote:
... From which autoconf version? I'd be happy to require a recent autoconf and drop this code if it's no longer needed. When this hack was added, it was the case that one or the other of
Please NO. Don't require an updated Autotools version.
It is impossible to update Autotools on existing systems. I've never been able to do it on Linux, OS X and Solaris. The GCC Compile Farm maintainers were not able to do it on compile farm machines like AIX.
Stay with the basics. Things already work well. Allow a user to override libdir using standard options. Don't do fancy things that break builds.
Also see https://www.gnu.org/prep/standards/html_node/Directory-Variables.html.
Since ever, packages should not have modified any of the system autoconf variables. I believe that nettle is one of the few that attempt to override the autoconf detection. I do not want to enter philosophical argument, just to kindly ask to have the option to disable this proprietary logic.
ср, 26 июн. 2019 г. в 17:00, Alon Bar-Lev alon.barlev@gmail.com:
On Wed, Jun 26, 2019 at 4:53 PM Jeffrey Walton noloader@gmail.com wrote:
On Wed, Jun 26, 2019 at 9:45 AM Niels Möller nisse@lysator.liu.se wrote:
... From which autoconf version? I'd be happy to require a recent autoconf and drop this code if it's no longer needed. When this hack was added, it was the case that one or the other of
Please NO. Don't require an updated Autotools version.
It is impossible to update Autotools on existing systems. I've never been able to do it on Linux, OS X and Solaris. The GCC Compile Farm maintainers were not able to do it on compile farm machines like AIX.
Stay with the basics. Things already work well. Allow a user to override libdir using standard options. Don't do fancy things that break builds.
Also see https://www.gnu.org/prep/standards/html_node/Directory-Variables.html.
Since ever, packages should not have modified any of the system autoconf variables. I believe that nettle is one of the few that attempt to override the autoconf detection. I do not want to enter philosophical argument, just to kindly ask to have the option to disable this proprietary logic.
What about just checking if libdir was overwritten via argument and not touching it if it was the case? Will that work for you?
On Wed, Jun 26, 2019 at 6:08 PM Dmitry Eremin-Solenikov dbaryshkov@gmail.com wrote:
ср, 26 июн. 2019 г. в 17:00, Alon Bar-Lev alon.barlev@gmail.com:
On Wed, Jun 26, 2019 at 4:53 PM Jeffrey Walton noloader@gmail.com wrote:
On Wed, Jun 26, 2019 at 9:45 AM Niels Möller nisse@lysator.liu.se wrote:
... From which autoconf version? I'd be happy to require a recent autoconf and drop this code if it's no longer needed. When this hack was added, it was the case that one or the other of
Please NO. Don't require an updated Autotools version.
It is impossible to update Autotools on existing systems. I've never been able to do it on Linux, OS X and Solaris. The GCC Compile Farm maintainers were not able to do it on compile farm machines like AIX.
Stay with the basics. Things already work well. Allow a user to override libdir using standard options. Don't do fancy things that break builds.
Also see https://www.gnu.org/prep/standards/html_node/Directory-Variables.html.
Since ever, packages should not have modified any of the system autoconf variables. I believe that nettle is one of the few that attempt to override the autoconf detection. I do not want to enter philosophical argument, just to kindly ask to have the option to disable this proprietary logic.
What about just checking if libdir was overwritten via argument and not touching it if it was the case? Will that work for you?
This patch is very simple... it have explicit --disable-... to disable the behavior, default leaving the current behavior. All explicit, no magic.
Dmitry Eremin-Solenikov dbaryshkov@gmail.com writes:
What about just checking if libdir was overwritten via argument and not touching it if it was the case? Will that work for you?
That's exactly how it has worked ever since this detection was added back in 2010. Which is why I suggest that packagers who find that the automatic detection is inappropriate simply use the standard --libdir= command line option.
With the only caveat that since I didn't find a way to really check if --libdir was provided or not, I compare $libdir to the default value, the literal string '${exec_prefix}/lib', which is somewhat unlikely to be used on the command line.
Regards, /Niels
Jeffrey Walton noloader@gmail.com writes:
From which autoconf version? I'd be happy to require a recent autoconf and drop this code if it's no longer needed. When this hack was added, it was the case that one or the other of
Please NO. Don't require an updated Autotools version.
Huh? The configure script is included in the release tarball. You *don't* need to even have autoconf installed to build the library. That's half of the point of using autoconf at all.
Requirement on autoconf only matters for those who want to modify configure.ac, or build from a git repo.
(And also, please don't use the term "autotools" if you want to say anything specific; autotools is a very loose term refering to a couple of very different tools each with their own particular quirks).
Regards, /Niels
On Wed, Jun 26, 2019 at 12:43 PM Niels Möller nisse@lysator.liu.se wrote:
Jeffrey Walton noloader@gmail.com writes:
From which autoconf version? I'd be happy to require a recent autoconf and drop this code if it's no longer needed. When this hack was added, it was the case that one or the other of
Please NO. Don't require an updated Autotools version.
Huh? The configure script is included in the release tarball. You *don't* need to even have autoconf installed to build the library. That's half of the point of using autoconf at all.
Requirement on autoconf only matters for those who want to modify configure.ac, or build from a git repo.
Yes, we often have to patch and then autoreconf. See, for example, https://github.com/noloader/Build-Scripts/blob/master/build-nettle.sh .
Jeff
Signed-off-by: Alon Bar-Lev alon.barlev@gmail.com --- configure.ac | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/configure.ac b/configure.ac index fb0b3c8c..5f2bf170 100644 --- a/configure.ac +++ b/configure.ac @@ -654,13 +654,13 @@ case "$host_os" in LIBNETTLE_FORLINK=libnettle.dylib LIBNETTLE_SONAME='libnettle.$(LIBNETTLE_MAJOR).dylib' LIBNETTLE_FILE='libnettle.$(LIBNETTLE_MAJOR).$(LIBNETTLE_MINOR).dylib' - LIBNETTLE_LINK='$(CC) $(CFLAGS) -dynamiclib $(LDFLAGS) -install_name ${libdir}/$(LIBNETTLE_SONAME) -compatibility_version $(LIBNETTLE_MAJOR) -current_version $(LIBNETTLE_MAJOR).$(LIBNETTLE_MINOR)' + LIBNETTLE_LINK='$(CC) $(CFLAGS) -dynamiclib $(LDFLAGS) -install_name $(libdir)/$(LIBNETTLE_SONAME) -compatibility_version $(LIBNETTLE_MAJOR) -current_version $(LIBNETTLE_MAJOR).$(LIBNETTLE_MINOR)' LIBNETTLE_LIBS=''
LIBHOGWEED_FORLINK=libhogweed.dylib LIBHOGWEED_SONAME='libhogweed.$(LIBHOGWEED_MAJOR).dylib' LIBHOGWEED_FILE='libhogweed.$(LIBHOGWEED_MAJOR).$(LIBHOGWEED_MINOR).dylib' - LIBHOGWEED_LINK='$(CC) $(CFLAGS) -dynamiclib -L. $(LDFLAGS) -install_name ${libdir}/$(LIBHOGWEED_SONAME) -compatibility_version $(LIBHOGWEED_MAJOR) -current_version $(LIBHOGWEED_MAJOR).$(LIBHOGWEED_MINOR)' + LIBHOGWEED_LINK='$(CC) $(CFLAGS) -dynamiclib -L. $(LDFLAGS) -install_name $(libdir)/$(LIBHOGWEED_SONAME) -compatibility_version $(LIBHOGWEED_MAJOR) -current_version $(LIBHOGWEED_MAJOR).$(LIBHOGWEED_MINOR)' LIBHOGWEED_LIBS='-lnettle $(LIBS)' ;; solaris*)
Alon Bar-Lev alon.barlev@gmail.com writes:
In Gentoo and probably other downstream distributions we let package management to manage the flags
This is a bit tricky. One can already pass CFLAGS= to configure. But I think the intention is that should override configure's automatic selection of flags (I haven't tested that though). But usually, one wants the package's configure have some say, and e.g., enable warnings that are expected to be silent.
So I'd rather have something more general like APPEND_CFLAGS added after CFLAGS to make it possible to override selected flags, and with some consistency with other packages using autoconf.
Regards, /Niels
On Wed, Jun 26, 2019 at 2:30 PM Niels Möller nisse@lysator.liu.se wrote:
Alon Bar-Lev alon.barlev@gmail.com writes:
In Gentoo and probably other downstream distributions we let package management to manage the flags
This is a bit tricky. One can already pass CFLAGS= to configure. But I think the intention is that should override configure's automatic selection of flags (I haven't tested that though). But usually, one wants the package's configure have some say, and e.g., enable warnings that are expected to be silent.
So I'd rather have something more general like APPEND_CFLAGS added after CFLAGS to make it possible to override selected flags, and with some consistency with other packages using autoconf.
I do not understand... In practice a package should not add by itself optimization or debug flags without consent (some --enable- argument), the fact that nettle is doing that is unexpected... the problem is how to tell build system to avoid adding these flags, not adding additional or keeping tack of what is added and try to suppress... up until now we patched the package to meet guidelines, can you please tell me what solution would you accept? Maybe --disable-custom-flags argument?
Thanks!
Alon Bar-Lev alon.barlev@gmail.com writes:
I do not understand... In practice a package should not add by itself optimization or debug flags without consent (some --enable- argument), the fact that nettle is doing that is unexpected...
I'm open to discuss how to deal with CFLAGS. Currently, Nettle sets -ggdb3, various warning flags (if compiling with gcc), and it kind-of adds -fPIC, but via different autoconf and make variables.
I think GNU standard is to use something like -g -O by default.
As a developer, I find it convenient to have stricter warning flags and more debug info by default, but that could be tied to an explicit configure argument and disabled by default. When suggesting improvements, please consider recommendations in the GNU coding standards.
Also keep in mind that ./configure defaults are intended primarily to make life easy for the user that runs ./configure manually, perhaps to try out a modification of her own. If you have a packaging framework that runs configure for you, it's expected that package configuration needs to add a couple of explicit arguments to override the defaults.
Regards, /Niels
On Wed, Jun 26, 2019 at 4:22 PM Niels Möller nisse@lysator.liu.se wrote:
Alon Bar-Lev alon.barlev@gmail.com writes:
I do not understand... In practice a package should not add by itself optimization or debug flags without consent (some --enable- argument), the fact that nettle is doing that is unexpected...
I'm open to discuss how to deal with CFLAGS. Currently, Nettle sets -ggdb3, various warning flags (if compiling with gcc), and it kind-of adds -fPIC, but via different autoconf and make variables.
I think GNU standard is to use something like -g -O by default.
As a developer, I find it convenient to have stricter warning flags and more debug info by default, but that could be tied to an explicit configure argument and disabled by default. When suggesting improvements, please consider recommendations in the GNU coding standards.
Also keep in mind that ./configure defaults are intended primarily to make life easy for the user that runs ./configure manually, perhaps to try out a modification of her own. If you have a packaging framework that runs configure for you, it's expected that package configuration needs to add a couple of explicit arguments to override the defaults.
Hi, I do not want to take anything from you, just for you to support disabling this behavior. I manage vast number of packages, and the well behaved ones are not manipulate flags. However, as I wrote, I do not want to take anything from your environment or default behavior, just to allow formal method (vs patching) to make this package live correctly within downstream by disabling these behaviors. Thanks!
On Wed, Jun 26, 2019 at 9:22 AM Niels Möller nisse@lysator.liu.se wrote:
Alon Bar-Lev alon.barlev@gmail.com writes:
I do not understand... In practice a package should not add by itself optimization or debug flags without consent (some --enable- argument), the fact that nettle is doing that is unexpected...
I'm open to discuss how to deal with CFLAGS. Currently, Nettle sets -ggdb3, various warning flags (if compiling with gcc), and it kind-of adds -fPIC, but via different autoconf and make variables.
I think GNU standard is to use something like -g -O by default.
As a developer, I find it convenient to have stricter warning flags and more debug info by default, but that could be tied to an explicit configure argument and disabled by default. When suggesting improvements, please consider recommendations in the GNU coding standards.
Also keep in mind that ./configure defaults are intended primarily to make life easy for the user that runs ./configure manually, perhaps to try out a modification of her own. If you have a packaging framework that runs configure for you, it's expected that package configuration needs to add a couple of explicit arguments to override the defaults.
One small nit... The user owns CFLAGS, and they should not be touched. The place to add library flags is AM_CLFAGS. Later, the Automake machinery will build a recipe like:
some_obj.o : ... $(CC) $(CPPFLAGS) $(AM_CLFAGS) $(CFLAGS) -c $<
The user's CFLAGS always overrides the library AM_CFLAGS to honor the user's freedom.
IF you have a flag that must be present to build an object, then it always gets added to the object. This would show up when building, say, x86 AES source file because the source file must have flags like "-msse4.1 -maes".
AES_FLAGS = -msse4.1 -maes aes.o : aes.c $(CC) $(CPPFLAGS) $(AM_CLFAGS) $(CFLAGS) $(AES_CFLAGS) -c $<
Some folks get quite upset when the freedom is not respected.
Also see https://www.gnu.org/prep/standards/html_node/Command-Variables.html .
Jeff
Hi Niels: Which way do you prefer to avoid adding this flag? having environment variable or --disable-xxx? Thanks!
On Wed, Jun 26, 2019 at 4:33 PM Jeffrey Walton noloader@gmail.com wrote:
On Wed, Jun 26, 2019 at 9:22 AM Niels Möller nisse@lysator.liu.se wrote:
Alon Bar-Lev alon.barlev@gmail.com writes:
I do not understand... In practice a package should not add by itself optimization or debug flags without consent (some --enable- argument), the fact that nettle is doing that is unexpected...
I'm open to discuss how to deal with CFLAGS. Currently, Nettle sets -ggdb3, various warning flags (if compiling with gcc), and it kind-of adds -fPIC, but via different autoconf and make variables.
I think GNU standard is to use something like -g -O by default.
As a developer, I find it convenient to have stricter warning flags and more debug info by default, but that could be tied to an explicit configure argument and disabled by default. When suggesting improvements, please consider recommendations in the GNU coding standards.
Also keep in mind that ./configure defaults are intended primarily to make life easy for the user that runs ./configure manually, perhaps to try out a modification of her own. If you have a packaging framework that runs configure for you, it's expected that package configuration needs to add a couple of explicit arguments to override the defaults.
One small nit... The user owns CFLAGS, and they should not be touched. The place to add library flags is AM_CLFAGS. Later, the Automake machinery will build a recipe like:
some_obj.o : ... $(CC) $(CPPFLAGS) $(AM_CLFAGS) $(CFLAGS) -c $<The user's CFLAGS always overrides the library AM_CFLAGS to honor the user's freedom.
IF you have a flag that must be present to build an object, then it always gets added to the object. This would show up when building, say, x86 AES source file because the source file must have flags like "-msse4.1 -maes".
AES_FLAGS = -msse4.1 -maes aes.o : aes.c $(CC) $(CPPFLAGS) $(AM_CLFAGS) $(CFLAGS) $(AES_CFLAGS) -c $<Some folks get quite upset when the freedom is not respected.
Also see https://www.gnu.org/prep/standards/html_node/Command-Variables.html .
Jeff
Alon Bar-Lev alon.barlev@gmail.com writes:
Which way do you prefer to avoid adding this flag? having environment variable or --disable-xxx?
You've brought up two different issues. For CFLAGS, I agree it could be improved. Not sure what's the best way is, but the main thing is to let CFLAGS be a user setting, following the coding standard. There could be an option to enable or disable the maintainer's (i.e. my) choice of additional warning flags.
The libdir issue is a different thing. The automatic hack only affects the *default* libdir, and is already overridable with the standard option --libdir=... In that case, I see little point in a new special option to disable the current behavior. What might make sense, if you convince me that the automatic selection really is an inappropriate default, is to enable it explicitly by using --libdir=auto.
And I'd still like to know if the there's been any related multiarch improvements in autoconf's default behavior recently.
Regards, /Niels
On Wed, Jun 26, 2019 at 11:44 PM Niels Möller nisse@lysator.liu.se wrote:
Alon Bar-Lev alon.barlev@gmail.com writes:
Which way do you prefer to avoid adding this flag? having environment variable or --disable-xxx?
You've brought up two different issues. For CFLAGS, I agree it could be improved. Not sure what's the best way is, but the main thing is to let CFLAGS be a user setting, following the coding standard. There could be an option to enable or disable the maintainer's (i.e. my) choice of additional warning flags.
Warnings are ok... I am talking about the -ggdb3 addition which affects the output. What do you prefer, this patch that enables me to have GCC_DEBUG_FLAGS=" " or add --disable-maintainer-flags or something like this?
The libdir issue is a different thing. The automatic hack only affects
We discuss this libdir at the different thread... I can workaround this by explicit parameters, however the CFLAGS forces me to patch.
Thanks!
nettle-bugs@lists.lysator.liu.se
-
Alon Bar-Lev -
Dmitry Eremin-Solenikov -
Jeffrey Walton -
nisse＠lysator.liu.se