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.

--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,

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.

> 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_MSG_CHECKING([for sysroot])
   [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.

Attachment: signature.asc
Description: PGP signature

Reply via email to