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
