Re: [PATCH 02/12] libtool.m4: Rename the --with-sysroot option to avoid conflict with gcc/binutils

2024-01-16 Thread Mike Frysinger
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

2024-01-16 Thread Roumen Petrov

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

2024-01-16 Thread Richard Purdie
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

2024-01-16 Thread Richard Purdie





Re: [PATCH 02/12] libtool.m4: Rename the --with-sysroot option to avoid conflict with gcc/binutils

2024-01-15 Thread Mike Frysinger
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