Re: [PATCH 02/12] libtool.m4: Rename the --with-sysroot option to avoid conflict with gcc/binutils
On 16 Jan 2024 12:21, Richard Purdie wrote: > On Mon, 2024-01-15 at 20:08 -0500, Mike Frysinger wrote: > > On 25 Oct 2021 15:33, Richard Purdie wrote: > > > This patch renames the --with-sysroot option to --with-libtool-sysroot > > > to avoid namespace conflict with binutils, gcc and other toolchain > > > components since these componets also add that option to configure > > > and this becomes confusing and conflicting otherwise. > > > > we're talking like 3 projects ? libtool is used & included in way more > > projects than that. it seems like --with-sysroot as a standard name to > > propagate out into the wider ecosystem makes more sense. > > You're saying binutils and gcc should change? I'm fairly sure they'll > decline to do that. Their options are encoded into quite a few cross > compiling documents and build systems. and there are even more packages out there using libtool. these are all GNU projects working in the toolchain space to make the GNU system coherent & better under the FSF. it is not one GNU project working in isolation and not caring about anyone else. decisions should be made with the long term outlook in mind, especially when we aren't talking about runtime ABI that would break/blow up everywhere. these are development and build scripts ... they aren't immutable. > > i agree there's confusion between "use this path as a sysroot to compile > > and link against" and "have the compile tools target this sysroot". the > > same problem exists with host selection which is why we have the build, > > host, and target options. sounds like we want names that can align with > > these somehow. > > FWIW gcc and binutils have gone with --with-sysroot and --with-build- > sysroot to differentiate. Unfortunately that doesn't really help > libtool (see below). i would argue --with-build-sysroot is not aligned with the other conventions used in configure scripts. https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.72/html_node/Hosts-and-Cross_002dCompilation.html --build is the system doing the compilation and controls settings for the build tools themselves, not for the toolchain specified via --host. instead the "host" part is omitted since it's the default. c.f. BUILD_CC & CC, BUILD_CFLAGS & CFLAGS, etc... which makes --with-sysroot the original sin as it fills that gap already. which is how libtool is using it now. really it seems like --with-sysroot should be renamed to --with-target-sysroot since it's controlling the target output behavior ... which is what gcc et al already use --target for. you can see that with the various libs it builds and the use of xxx_FOR_TARGET variables. ignoring the mismatch in conventions, i can't say that i would see much use of a sysroot setting for the build tools themselves, so it isn't like gcc has squatted in a space that would cause issues. although that kind of thinking is why we're in this situation in the first place. > > --with-libtool-sysroot doesn't make sense as it isn't an internal libtool > > setting, it's changing how executables are linked, and users (who run the > > configure scripts) don't know or care about this "libtool" thing. > > I think it partly depends upon how you view it. Most of the time > libtool uses `$CC --print-sysroot` to set this and therefore most users > wouldn't use the commandline option. In general you do want the > compiler/linker and libtool to be working the same way. > > The challenge is that binutils/gcc and libtool have adopted different > meanings for the same option and if/as/where the commandline options > get passed around, things can become quite broken when cross compiling. i understand the conflict, and how it only applies to building the toolchain source projects (gcc and its downstream like binutils & gdb). > My ask is to try and find a way to avoid the confusion (and the need > for Yocto Project to have to patch one set of components to make things > work). > > The options as I see it are: > > a) Use a libtool specific option (as per the patch under review) no. libtool is an internal implementation detail. there should be no exposure/leakage of the name to people configuring+building. it's like saying we should call --with-pic --with-libtool-pic because it's libtool creating the position independent code. > b) Stop providing a commandline option for libtool and rely on the > compiler query. no, it is in active use as intended already. this is like saying most people don't set LDFLAGS, so just delete it. while it's uncommon, it can serve a pretty critical and irreplaceable function. > c) Switch to --with-build-sysroot not the worst option, but certainly not preferable as outlined above. > d) Switch to --sysroot does not align with GNU standards on naming. https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.72/html_node/External-Software.html > e) Ask gcc/binutils to change in the immortal words of Michael Bolton, "Why should I change?
Re: [PATCH 02/12] libtool.m4: Rename the --with-sysroot option to avoid conflict with gcc/binutils
Hi, Richard Purdie wrote: [SNIP] FWIW gcc and binutils have gone with --with-sysroot and --with-build- sysroot to differentiate. Unfortunately that doesn't really help libtool (see below). Sure but we when use libtool argument --with-sysroot we expect to work as is designed and documented . --with-libtool-sysroot doesn't make sense as it isn't an internal libtool setting, it's changing how executables are linked, and users (who run the configure scripts) don't know or care about this "libtool" thing. I think it partly depends upon how you view it. Most of the time libtool uses `$CC --print-sysroot` to set this and therefore most users wouldn't use the commandline option. In general you do want the compiler/linker and libtool to be working the same way. Hmm If I remember well this is GCC specific option. Android does not use GCC i.e., it cannot find default paths. More over include and library directories are different i.e. option does not make sense for Android cross-builds. Remark: --with-sysroot should point to "library" in my cross-builds and another way is used to specify paths to headers. [SNIP] Regards, Roumen
Re: [PATCH 02/12] libtool.m4: Rename the --with-sysroot option to avoid conflict with gcc/binutils
Somehow my original reply ended up blank, sorry. I've retyped it from memory as best I can. On Mon, 2024-01-15 at 20:08 -0500, Mike Frysinger wrote: > On 25 Oct 2021 15:33, Richard Purdie wrote: > > This patch renames the --with-sysroot option to --with-libtool-sysroot > > to avoid namespace conflict with binutils, gcc and other toolchain > > components since these componets also add that option to configure > > and this becomes confusing and conflicting otherwise. > > we're talking like 3 projects ? libtool is used & included in way more > projects than that. it seems like --with-sysroot as a standard name to > propagate out into the wider ecosystem makes more sense. You're saying binutils and gcc should change? I'm fairly sure they'll decline to do that. Their options are encoded into quite a few cross compiling documents and build systems. > i agree there's confusion between "use this path as a sysroot to compile > and link against" and "have the compile tools target this sysroot". the > same problem exists with host selection which is why we have the build, > host, and target options. sounds like we want names that can align with > these somehow. FWIW gcc and binutils have gone with --with-sysroot and --with-build- sysroot to differentiate. Unfortunately that doesn't really help libtool (see below). > --with-libtool-sysroot doesn't make sense as it isn't an internal libtool > setting, it's changing how executables are linked, and users (who run the > configure scripts) don't know or care about this "libtool" thing. I think it partly depends upon how you view it. Most of the time libtool uses `$CC --print-sysroot` to set this and therefore most users wouldn't use the commandline option. In general you do want the compiler/linker and libtool to be working the same way. The challenge is that binutils/gcc and libtool have adopted different meanings for the same option and if/as/where the commandline options get passed around, things can become quite broken when cross compiling. My ask is to try and find a way to avoid the confusion (and the need for Yocto Project to have to patch one set of components to make things work). The options as I see it are: a) Use a libtool specific option (as per the patch under review) b) Stop providing a commandline option for libtool and rely on the compiler query. c) Switch to --with-build-sysroot d) Switch to --sysroot e) Ask gcc/binutils to change I can't see gcc/binutils changing. Using c/d would likely have a different set of issues. For example in some cases you do want the build sysroot and sometimes the target with libtool so c swaps one set of problems for another. Since most of the time users never need to care about setting this option and we couldn't find an alternative, changing it as per the patch seemed like the least worst solution and was why we end up with a). Would: --with-sysroot-libtool be any better? I'm open to other ideas. Cheers, Richard
Re: [PATCH 02/12] libtool.m4: Rename the --with-sysroot option to avoid conflict with gcc/binutils
Re: [PATCH 02/12] libtool.m4: Rename the --with-sysroot option to avoid conflict with gcc/binutils
On 25 Oct 2021 15:33, Richard Purdie wrote: > This patch renames the --with-sysroot option to --with-libtool-sysroot > to avoid namespace conflict with binutils, gcc and other toolchain > components since these componets also add that option to configure > and this becomes confusing and conflicting otherwise. we're talking like 3 projects ? libtool is used & included in way more projects than that. it seems like --with-sysroot as a standard name to propagate out into the wider ecosystem makes more sense. i agree there's confusion between "use this path as a sysroot to compile and link against" and "have the compile tools target this sysroot". the same problem exists with host selection which is why we have the build, host, and target options. sounds like we want names that can align with these somehow. --with-libtool-sysroot doesn't make sense as it isn't an internal libtool setting, it's changing how executables are linked, and users (who run the configure scripts) don't know or care about this "libtool" thing. -mike signature.asc Description: PGP signature
[PATCH 02/12] libtool.m4: Rename the --with-sysroot option to avoid conflict with gcc/binutils
From: Khem Raj This patch renames the --with-sysroot option to --with-libtool-sysroot to avoid namespace conflict with binutils, gcc and other toolchain components since these componets also add that option to configure and this becomes confusing and conflicting otherwise. Signed-off-by: Richard Purdie --- m4/libtool.m4| 12 ++-- tests/sysroot.at | 6 +++--- 2 files changed, 9 insertions(+), 9 deletions(-) diff --git a/m4/libtool.m4 b/m4/libtool.m4 index f2d1f398..de2f1ebf 100644 --- a/m4/libtool.m4 +++ b/m4/libtool.m4 @@ -1246,28 +1246,28 @@ _LT_DECL([], [ECHO], [1], [An echo program that protects backslashes]) # AC_DEFUN([_LT_WITH_SYSROOT], [AC_MSG_CHECKING([for sysroot]) -AC_ARG_WITH([sysroot], -[AS_HELP_STRING([--with-sysroot@<:@=DIR@:>@], +AC_ARG_WITH([libtool-sysroot], +[AS_HELP_STRING([--with-libtool-sysroot@<:@=DIR@:>@], [Search for dependent libraries within DIR (or the compiler's sysroot if not specified).])], -[], [with_sysroot=no]) +[], [with_libtool_sysroot=no]) dnl lt_sysroot will always be passed unquoted. We quote it here dnl in case the user passed a directory name. lt_sysroot= -case $with_sysroot in #( +case $with_libtool_sysroot in #( yes) if test yes = "$GCC"; then lt_sysroot=`$CC --print-sysroot 2>/dev/null` fi ;; #( /*) - lt_sysroot=`echo "$with_sysroot" | sed -e "$sed_quote_subst"` + lt_sysroot=`echo "$with_libtool_sysroot" | sed -e "$sed_quote_subst"` ;; #( no|'') ;; #( *) - AC_MSG_RESULT([$with_sysroot]) + AC_MSG_RESULT([$with_libtool_sysroot]) AC_MSG_ERROR([The sysroot must be an absolute path.]) ;; esac diff --git a/tests/sysroot.at b/tests/sysroot.at index 05faa13d..7a1f9567 100644 --- a/tests/sysroot.at +++ b/tests/sysroot.at @@ -64,7 +64,7 @@ while read file; do done]) LDFLAGS="$LDFLAGS --sysroot=$sysroot -no-undefined" -configure_options="$configure_options --with-sysroot=$sysroot --prefix=$prefix" +configure_options="$configure_options --with-libtool-sysroot=$sysroot --prefix=$prefix" #??? if test PATH = "$shlibpath_var"; then @@ -114,7 +114,7 @@ AM_INIT_AUTOMAKE([foreign]) AC_PROG_CC AC_CONFIG_SRCDIR([lib2.c]) LT_INIT -sysroot=$with_sysroot +sysroot=$with_libtool_sysroot AC_SUBST([sysroot]) AC_OUTPUT(Makefile) ]]) @@ -155,7 +155,7 @@ AM_INIT_AUTOMAKE([foreign]) AC_PROG_CC AC_CONFIG_SRCDIR([prog.c]) LT_INIT -sysroot=$with_sysroot +sysroot=$with_libtool_sysroot AC_SUBST([sysroot]) AC_OUTPUT(Makefile) ]]) -- 2.25.1
