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

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



be any better?

I'm open to other ideas.



Reply via email to