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? He's the one who sucks!" f) backdoor _LT_SET_OPTIONS with an override flag just for gcc/downstream if the only projects affected are gcc (and its downstream like binutils/gdb), then we could backdoor _LT_WITH_SYSROOT such that gcc could rename the option to whatever it wanted. AC_DEFUN([_LT_WITH_SYSROOT], [m4_require([_LT_DECL_SED])dnl +m4_ifndef([_LT_WITH_SYSROOT_NAME], [AC_DEFUN([_LT_WITH_SYSROOT_NAME], [sysroot])]) AC_MSG_CHECKING([for sysroot]) -AC_ARG_WITH([sysroot], -[AS_HELP_STRING([--with-sysroot@<:@=DIR@:>@], +AC_ARG_WITH(_LT_WITH_SYSROOT_NAME, +[AS_HELP_STRING([--with-]_LT_WITH_SYSROOT_NAME[@<:@=DIR@:>@], [Search for dependent libraries within DIR (or the compiler's sysroot would have to move the rest of the code in that macro that reads $with_sysroot into the 3rd arg of AC_ARG_WITH so it can read $withval and avoid dealing with diff named $with_xxx vars. > 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. it sounds like you're not using the "build" and "target" terms the way the GNU project has defined them. please see the autoconf doc i linked above. > Would: > > --with-sysroot-libtool > > be any better? no. this is (a) above. -mike
signature.asc
Description: PGP signature
