Re: [PATCH] libtool.m4: Handle "/" as a sysroot more correctly

[Roumen Petrov]

Hi All,

Mike Frysinger wrote:

On 16 Jan 2024 21:47, Richard Purdie wrote:

If $CC has --sysroot=/, it is a valid configuration however libtool will
then set lt_sysroot to "/".

This means references like $lt_sysroot$libdir become //usr/lib instead
of the more normally expected /usr/lib. This may or may not break something
but certainly is confusing to the user and gives confusing output. Making
"/" simply unset lt_sysroot is much cleaner.

could the same argument be made if the returned value is "/opt/sysroot/"
and not just "/opt/sysroot" ?  not sure if gcc forces normalization on its
side.  but we could "simplify" this with:


I cannot see reason /path/ vs /path1 to be considered as critical.

But / vs empty is another story.
Prefix // means UNC name in some build environments.


# Trim trailing / since we'll always append absolute paths and we want
# to avoid //, if only for less confusing output for the user.
lt_sysroot=`$CC --print-sysroot 2>/dev/null | $SED 's:/\+$::'`


May be issues is from cygwin build environment.


-mike


Regards,
Roumen

[PATCH] libtool.m4: drop AC_PROG_SED fallback

[Mike Frysinger]

We require autoconf 2.62 which includes this macro so we don't need
this fallback logic anymore.

* m4/libtool.m4 (AC_PROG_SED): Delete.
---
 m4/libtool.m4 | 67 ---
 1 file changed, 67 deletions(-)

diff --git a/m4/libtool.m4 b/m4/libtool.m4
index 4b60d27c0ec2..6172662c7a1f 100644
--- a/m4/libtool.m4
+++ b/m4/libtool.m4
@@ -8230,73 +8230,6 @@ _LT_DECL([], [SED], [1], [A sed program that does not 
truncate output])
 _LT_DECL([], [Xsed], ["\$SED -e 1s/^X//"],
 [Sed that helps us avoid accidentally triggering echo(1) options like -n])
 ])# _LT_DECL_SED
-
-m4_ifndef([AC_PROG_SED], [
-
-# NOTE: This macro has been submitted for inclusion into   #
-#  GNU Autoconf as AC_PROG_SED.  When it is available in   #
-#  a released version of Autoconf we should remove this#
-#  macro and use it instead.   #
-
-
-m4_defun([AC_PROG_SED],
-[AC_MSG_CHECKING([for a sed that does not truncate output])
-AC_CACHE_VAL(lt_cv_path_SED,
-[# Loop through the user's path and test for sed and gsed.
-# Then use that list of sed's as ones to test for truncation.
-as_save_IFS=$IFS; IFS=$PATH_SEPARATOR
-for as_dir in $PATH
-do
-  IFS=$as_save_IFS
-  test -z "$as_dir" && as_dir=.
-  for lt_ac_prog in sed gsed; do
-for ac_exec_ext in '' $ac_executable_extensions; do
-  if $as_executable_p "$as_dir/$lt_ac_prog$ac_exec_ext"; then
-lt_ac_sed_list="$lt_ac_sed_list $as_dir/$lt_ac_prog$ac_exec_ext"
-  fi
-done
-  done
-done
-IFS=$as_save_IFS
-lt_ac_max=0
-lt_ac_count=0
-# Add /usr/xpg4/bin/sed as it is typically found on Solaris
-# along with /bin/sed that truncates output.
-for lt_ac_sed in $lt_ac_sed_list /usr/xpg4/bin/sed; do
-  test ! -f "$lt_ac_sed" && continue
-  cat /dev/null > conftest.in
-  lt_ac_count=0
-  echo $ECHO_N "0123456789$ECHO_C" >conftest.in
-  # Check for GNU sed and select it if it is found.
-  if "$lt_ac_sed" --version 2>&1 < /dev/null | grep 'GNU' > /dev/null; then
-lt_cv_path_SED=$lt_ac_sed
-break
-  fi
-  while true; do
-cat conftest.in conftest.in >conftest.tmp
-mv conftest.tmp conftest.in
-cp conftest.in conftest.nl
-echo >>conftest.nl
-$lt_ac_sed -e 's/a$//' < conftest.nl >conftest.out || break
-cmp -s conftest.out conftest.nl || break
-# 1 chars as input seems more than enough
-test 10 -lt "$lt_ac_count" && break
-lt_ac_count=`expr $lt_ac_count + 1`
-if test "$lt_ac_count" -gt "$lt_ac_max"; then
-  lt_ac_max=$lt_ac_count
-  lt_cv_path_SED=$lt_ac_sed
-fi
-  done
-done
-])
-SED=$lt_cv_path_SED
-AC_SUBST([SED])
-AC_MSG_RESULT([$SED])
-])#AC_PROG_SED
-])#m4_ifndef
-
-# Old name:
-AU_ALIAS([LT_AC_PROG_SED], [AC_PROG_SED])
 dnl aclocal-1.4 backwards compatibility:
 dnl AC_DEFUN([LT_AC_PROG_SED], [])
 
-- 
2.43.0

Re: [PATCH] libtool: remove OpenBSD support for non-shared and a.out archs

[Roumen Petrov]

Hi All

Mike Frysinger wrote:

On 16 Jan 2024 21:11, Brad Smith wrote:

libtool: remove OpenBSD support for non-shared and a.out archs

OpenBSD stopped supporting the last non-shared arch 8 years ago
and stopped supporting a.out 10.5 years ago.

This cannot be reason to drop support.
For instance RHEL was release in 2011 and is still supported.


i'm on the fence here, and i don't know what historical guidance/policy
libtool has had.  i looked through HACKING & the manual and didn't find
anything relevant.

Some projects still support c89.
How long to support a functionality is good question.
When hardware die some legacy system have no other options  expect to switch to 
new releases. If exist one ...


yeah, that's an old target, but libtool supports things older than that.
-mike


Regards,
Roumen Petrov

Re: [PATCH 1/3] libtool.m4: augment symcode for Solaris 11

[Mike Frysinger]

this should be fixed in git now.  i merged the one posted previously:
https://savannah.gnu.org/patch/?9086
-mike


signature.asc
Description: PGP signature

[patch #9086] Fix support for Solaris 11 build

[Mike Frysinger]

Update of patch#9086 (group libtool):

  Status:None => Done   
 Open/Closed:Open => Closed 

___

Follow-up Comment #1:

thanks, merged now
https://git.savannah.gnu.org/cgit/libtool.git/commit/?h=b67d1a2db842c01c051c7e90d7f4c18928d8b555

in the future, please attach git formatted patches instead, and write proper
commit messages


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

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

[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] libtool: remove OpenBSD support for non-shared and a.out archs

[Mike Frysinger]

On 16 Jan 2024 21:11, Brad Smith wrote:
> libtool: remove OpenBSD support for non-shared and a.out archs
> 
> OpenBSD stopped supporting the last non-shared arch 8 years ago
> and stopped supporting a.out 10.5 years ago.

i'm on the fence here, and i don't know what historical guidance/policy
libtool has had.  i looked through HACKING & the manual and didn't find
anything relevant.

yeah, that's an old target, but libtool supports things older than that.
-mike


signature.asc
Description: PGP signature

[PATCH] HACKING: minor formatting tweaks

[Mike Frysinger]

* HACKING: Tweak style.
---
 HACKING | 18 +-
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/HACKING b/HACKING
index 92292d1d023d..664251e680a9 100644
--- a/HACKING
+++ b/HACKING
@@ -13,7 +13,7 @@ and is not part of a release distribution.
 * If you incorporate a change from somebody on the net:
   If it is a large change, you must make sure they have signed the
   appropriate paperwork, and be sure to add their name and email
-  address to THANKS
+  address to THANKS.
 
 * If a change fixes a test, mention the test in the git log entry.
 
@@ -45,7 +45,7 @@ and is not part of a release distribution.
   gnulib is up-to-date, and running 'bootstrap' to recheck the links are
   correct.
 
-* Changes other than bug fixes must be mentioned in NEWS
+* Changes other than bug fixes must be mentioned in NEWS.
 
 
 3. Test Suite
@@ -58,7 +58,7 @@ and is not part of a release distribution.
 * Use
 make -k check
   liberally, on as many platforms as you can.  Use as many compilers and
-  linkers you can.  To run old and new testsuites separately, use
+  linkers you can.  To run old and new testsuites separately, use:
 make check TESTSUITEFLAGS=-V
 make check-local
 
@@ -130,7 +130,7 @@ and is not part of a release distribution.
 6. Editing '.am' Files
 ==
 
-* Always use $(...) and not ${...}
+* Always use $(...) and not ${...}.
 
 * Use ':', not 'true'.  Use 'exit 1', not 'false'.
 
@@ -180,7 +180,7 @@ and is not part of a release distribution.
 
 
 8. Abstraction layers in libltdl
-=
+
 
 * The libltdl API uses a layered approach to differentiate internal and
   external interfaces, among other things.  To keep the abstraction
@@ -283,10 +283,10 @@ and is not part of a release distribution.
 9. Licensing Rules
 ==
 
-GNU Libtool uses 3 different licenses for various of the files distributed
-herein, with several variations on license text.  It is important that
-you use the correct license text in each new file added.  Here are the
-texts along with some notes on when each is appropriate.  Appropriate
+GNU Libtool uses 3 different licenses for the files distributed herein,
+with several variations on license text.  It is important that you use
+the correct license text in each new file added.  Here are the texts
+along with some notes on when each is appropriate.  Appropriate
 commenting (shell, C etc) and decoration (m4 etc) assumed throughout.
 
 
-- 
2.43.0

Re: [PATCH 2/3] ltmain.in: Parse additional clang options

[Sam James]

Richard Purdie  writes:

> clang uses -rtlib and --unwindlib to select proper compiler runtime in
> some cases. Therefore pass these options to linker when found in
> ldflags

Thanks, I was planning on sending this one too.

>
> * build-aux/ltmain.in: Handle clang linker options
> ---
>  build-aux/ltmain.in | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/build-aux/ltmain.in b/build-aux/ltmain.in
> index 34784c8c..cf6dc13a 100644
> --- a/build-aux/ltmain.in
> +++ b/build-aux/ltmain.in
> @@ -5412,12 +5412,14 @@ func_mode_link ()
># -shared-libsan   Link with shared sanitizer runtimes (Clang)
># -static-libsan   Link with static sanitizer runtimes (Clang)
># -fuse-ld=*   Linker select flags for GCC
> +  # -rtlib=* select c runtime lib with clang
> +  # --unwindlib=*select unwinder library with clang
># -f{file|debug|macro}-prefix-map* needed for lto linking
># -Wa,*Pass flags directly to the assembler
># -Werror, -Werror=*   Report (specified) warnings as errors
>-64|-mips[0-9]|-r[0-9][0-9]*|-xarch=*|-xtarget=*|+DA*|+DD*|-q*|-m*| \
>
> -t[45]*|-txscale*|-p|-pg|--coverage|-fprofile-*|-F*|@*|-tp=*|--sysroot=*| \
> -  
> -O*|-g*|-flto*|-fwhopr*|-fuse-linker-plugin|-fstack-protector*|-stdlib=*| \
> +  
> -O*|-g*|-flto*|-fwhopr*|-fuse-linker-plugin|-fstack-protector*|-stdlib=*|-rtlib=*|--unwindlib=*|
>  \
>-specs=*|-fsanitize=*|-fno-sanitize*|-shared-libsan|-static-libsan| \
>-ffile-prefix-map*|-fdebug-prefix-map*|-fmacro-prefix-map*| \
>-fdiagnostics-color*|-frecord-gcc-switches| \

Re: pass_all for z/OS

[Mike Frysinger]

On 17 Jan 2024 02:41, Igor Todorovski wrote:
> I’ve attached the git patch based on the master branch.

can you write a proper git commit and send it with send-email ?
or at least format it with `git format-patch` ?

the first version did:
openedition)

the new one does:
*openedition*)

isn't it always going to be "openedition" exactly ?  no need for globs ?
-mike


signature.asc
Description: PGP signature

RE: pass_all for z/OS

[Igor Todorovski]

Hi Mike,

I’ve attached the git patch based on the master branch.

Thanks,
Igor

On 2024-01-14, 1:57 AM, "Mike Frysinger"  wrote:
On 24 Nov 2023 15:19, Igor Todorovski wrote:
> diff --git a/libltdl/m4/libtool.m4 b/libltdl/m4/libtool.m4
> index d812584..f959bae 100644
> --- a/libltdl/m4/libtool.m4
> +++ b/libltdl/m4/libtool.m4

this file doesn't exist.  i don't know what git tree you're working against,
but it isn't the latest libtool one.  please rebase onto the latest version,
and send a proper git patch.  hand written ones like what you've posted here
are a pain to merge as it forces us to do a lot of manual work.
-mike



zos.patch
Description: zos.patch

Re: [PATCH] libtool.m4: Handle "/" as a sysroot more correctly

[Mike Frysinger]

On 16 Jan 2024 21:47, Richard Purdie wrote:
> If $CC has --sysroot=/, it is a valid configuration however libtool will
> then set lt_sysroot to "/".
> 
> This means references like $lt_sysroot$libdir become //usr/lib instead
> of the more normally expected /usr/lib. This may or may not break something
> but certainly is confusing to the user and gives confusing output. Making
> "/" simply unset lt_sysroot is much cleaner.

could the same argument be made if the returned value is "/opt/sysroot/"
and not just "/opt/sysroot" ?  not sure if gcc forces normalization on its
side.  but we could "simplify" this with:

# Trim trailing / since we'll always append absolute paths and we want
# to avoid //, if only for less confusing output for the user.
lt_sysroot=`$CC --print-sysroot 2>/dev/null | $SED 's:/\+$::'`
-mike


signature.asc
Description: PGP signature

[PATCH] libtool: remove OpenBSD support for non-shared and a.out archs

[Brad Smith]

libtool: remove OpenBSD support for non-shared and a.out archs

OpenBSD stopped supporting the last non-shared arch 8 years ago
and stopped supporting a.out 10.5 years ago.

* m4/libtool.m4: Remove support for a.out and non-shared archs.
---
 m4/libtool.m4 | 59 ---
 1 file changed, 18 insertions(+), 41 deletions(-)

diff --git a/m4/libtool.m4 b/m4/libtool.m4
index 4b84ce96..371c2250 100644
--- a/m4/libtool.m4
+++ b/m4/libtool.m4
@@ -2948,11 +2948,7 @@ openbsd*)
   version_type=sunos
   sys_lib_dlsearch_path_spec=/usr/lib
   need_lib_prefix=no
-  if test -z "`echo __ELF__ | $CC -E - | $GREP __ELF__`"; then
-need_version=no
-  else
-need_version=yes
-  fi
+  need_version=no
   library_names_spec='$libname$release$shared_ext$versuffix 
$libname$shared_ext$versuffix'
   finish_cmds='PATH="\$PATH:/sbin" ldconfig -m $libdir'
   shlibpath_var=LD_LIBRARY_PATH
@@ -3585,11 +3581,7 @@ newos6*)
   ;;
 
 openbsd*)
-  if test -z "`echo __ELF__ | $CC -E - | $GREP __ELF__`"; then
-lt_cv_deplibs_check_method='match_pattern 
/lib[[^/]]+(\.so\.[[0-9]]+\.[[0-9]]+|\.so|_pic\.a)$'
-  else
-lt_cv_deplibs_check_method='match_pattern 
/lib[[^/]]+(\.so\.[[0-9]]+\.[[0-9]]+|_pic\.a)$'
-  fi
+  lt_cv_deplibs_check_method='match_pattern 
/lib[[^/]]+(\.so\.[[0-9]]+\.[[0-9]]+|\.so|_pic\.a)$'
   ;;
 
 osf3* | osf4* | osf5*)
@@ -5844,22 +5836,13 @@ _LT_EOF
   ;;
 
 openbsd*)
-  if test -f /usr/libexec/ld.so; then
-   _LT_TAGVAR(hardcode_direct, $1)=yes
-   _LT_TAGVAR(hardcode_shlibpath_var, $1)=no
-   _LT_TAGVAR(hardcode_direct_absolute, $1)=yes
-   if test -z "`echo __ELF__ | $CC -E - | $GREP __ELF__`"; then
- _LT_TAGVAR(archive_cmds, $1)='$CC -shared $pic_flag -o $lib $libobjs 
$deplibs $compiler_flags'
- _LT_TAGVAR(archive_expsym_cmds, $1)='$CC -shared $pic_flag -o $lib 
$libobjs $deplibs $compiler_flags $wl-retain-symbols-file,$export_symbols'
- _LT_TAGVAR(hardcode_libdir_flag_spec, $1)='$wl-rpath,$libdir'
- _LT_TAGVAR(export_dynamic_flag_spec, $1)='$wl-E'
-   else
- _LT_TAGVAR(archive_cmds, $1)='$CC -shared $pic_flag -o $lib $libobjs 
$deplibs $compiler_flags'
- _LT_TAGVAR(hardcode_libdir_flag_spec, $1)='$wl-rpath,$libdir'
-   fi
-  else
-   _LT_TAGVAR(ld_shlibs, $1)=no
-  fi
+  _LT_TAGVAR(archive_cmds, $1)='$CC -shared $pic_flag -o $lib $libobjs 
$deplibs $compiler_flags'
+  _LT_TAGVAR(archive_expsym_cmds, $1)='$CC -shared $pic_flag -o $lib 
$libobjs $deplibs $compiler_flags $wl-retain-symbols-file,$export_symbols'
+  _LT_TAGVAR(hardcode_direct, $1)=yes
+  _LT_TAGVAR(hardcode_shlibpath_var, $1)=no
+  _LT_TAGVAR(hardcode_direct_absolute, $1)=yes
+  _LT_TAGVAR(hardcode_libdir_flag_spec, $1)='$wl-rpath,$libdir'
+  _LT_TAGVAR(export_dynamic_flag_spec, $1)='$wl-E'
   ;;
 
 os2*)
@@ -7137,21 +7120,15 @@ if test yes != "$_lt_caught_CXX_error"; then
;;
 
   openbsd*)
-   if test -f /usr/libexec/ld.so; then
- _LT_TAGVAR(hardcode_direct, $1)=yes
- _LT_TAGVAR(hardcode_shlibpath_var, $1)=no
- _LT_TAGVAR(hardcode_direct_absolute, $1)=yes
- _LT_TAGVAR(archive_cmds, $1)='$CC -shared $pic_flag $predep_objects 
$libobjs $deplibs $postdep_objects $compiler_flags -o $lib'
- _LT_TAGVAR(hardcode_libdir_flag_spec, $1)='$wl-rpath,$libdir'
- if test -z "`echo __ELF__ | $CC -E - | grep __ELF__`"; then
-   _LT_TAGVAR(archive_expsym_cmds, $1)='$CC -shared $pic_flag 
$predep_objects $libobjs $deplibs $postdep_objects $compiler_flags 
$wl-retain-symbols-file,$export_symbols -o $lib'
-   _LT_TAGVAR(export_dynamic_flag_spec, $1)='$wl-E'
-   _LT_TAGVAR(whole_archive_flag_spec, 
$1)=$wlarc'--whole-archive$convenience '$wlarc'--no-whole-archive'
- fi
- output_verbose_link_cmd=func_echo_all
-   else
- _LT_TAGVAR(ld_shlibs, $1)=no
-   fi
+_LT_TAGVAR(archive_cmds, $1)='$CC -shared $pic_flag $predep_objects 
$libobjs $deplibs $postdep_objects $compiler_flags -o $lib'
+_LT_TAGVAR(archive_expsym_cmds, $1)='$CC -shared $pic_flag 
$predep_objects $libobjs $deplibs $postdep_objects $compiler_flags 
$wl-retain-symbols-file,$export_symbols -o $lib'
+_LT_TAGVAR(hardcode_direct, $1)=yes
+_LT_TAGVAR(hardcode_shlibpath_var, $1)=no
+_LT_TAGVAR(hardcode_direct_absolute, $1)=yes
+_LT_TAGVAR(hardcode_libdir_flag_spec, $1)='$wl-rpath,$libdir'
+_LT_TAGVAR(export_dynamic_flag_spec, $1)='$wl-E'
+_LT_TAGVAR(whole_archive_flag_spec, 
$1)=$wlarc'--whole-archive$convenience '$wlarc'--no-whole-archive'
+output_verbose_link_cmd=func_echo_all
;;
 
   osf3* | osf4* | osf5*)
-- 
2.43.0

Re: [PATCH 05/12] ltmain.in: Don't encode RATHS which match default linker paths

[Mike Frysinger]

On 25 Oct 2021 15:33, Richard Purdie wrote:
> We don't want to add RPATHS which match default linker search paths, they're
> a waste of space. This patch filters libtools list of paths to encoode and
> removes the ones we don't need.
> 
> Libtool may be passed link paths of the form "/usr/lib/../lib" so normalize
> the paths before comparision.

add a bit more detail to the commit message, add the changelog, and fix the
typo in the subject line ("RATHS").

> --- a/build-aux/ltmain.in
> +++ b/build-aux/ltmain.in
> @@ -7672,8 +7672,16 @@ EOF
> esac
>   fi
> else
> - eval flag=\"$hardcode_libdir_flag_spec\"
> - func_append dep_rpath " $flag"
> +# We only want to hardcode in an rpath if it isn't in the
> +# default dlsearch path.
> +func_normal_abspath "$libdir"
> +libdir_norm=$func_normal_abspath_result
> + case " $sys_lib_dlsearch_path " in
> + *" $libdir_norm "*) ;;
> + *) eval flag=\"$hardcode_libdir_flag_spec\"
> +   func_append dep_rpath " $flag"
> +   ;;
> + esac

this is a non-trivial amount of boiler plate that you're pasting in here.
can we introduce a func to make this more readable ?  something like this
untested code.

# func_is_in_list   [separator]
# blah blah blah
func_is_in_list ()
{
case "${3:- }$2${3:- }" in
*"${3:- }$1${3:- }"*) return 0;;
esac
return 1
}

then you could write:
  func_normal_abspath "$libdir"
  if ! func_is_in_list "$func_normal_abspath_result" "$sys_lib_dlsearch_path"; 
then
eval flag=\"$hardcode_libdir_flag_spec\"
func_append dep_rpath " $flag"
  fi

and there's 2 other places where $sys_lib_dlsearch_path is checked that could
be converted over to this helper.
-mike


signature.asc
Description: PGP signature

Re: [PATCH] libtool: remove OpenBSD specific performance hack for ranlib

[Mike Frysinger]

On 16 Jan 2024 16:30, Brad Smith wrote:
> The -t flag was used as a performance hack for ranlib. The flag was
> supported by the GNU toolchain, but is a no-op with the LLVM toolchain.

merged, thx
-mike


signature.asc
Description: PGP signature

Re: [PATCH 3/3] libtool: Fix support for NIOS2 processor

[Mike Frysinger]

On 16 Jan 2024 15:14, Richard Purdie wrote:
> The name of the system contains the string "nios2". This string
> is caught by the some of the greedy checks for OS/2 in libtool,
> in particular the *os2* branches of switch statements match for
> the nios2 string, which results in incorrect behavior of libtool.
> 
> Switch to use $host_os instead of $host and tweak the patterns to
> match to avoid this problem for nios2.

merged, thx
-mike


signature.asc
Description: PGP signature

Re: [PATCH 1/3] ltmain.in: Handle prefix-map compiler options correctly

[Mike Frysinger]

On 16 Jan 2024 15:14, Richard Purdie wrote:
> --- a/build-aux/ltmain.in
> +++ b/build-aux/ltmain.in
> @@ -7,7 +7,6 @@
>  # Copyright (C) 1996-2019, 2021-2024 Free Software Foundation, Inc.
>  # This is free software; see the source for copying conditions.  There is NO
>  # warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
> -
>  # GNU Libtool is free software; you can redistribute it and/or modify
>  # it under the terms of the GNU General Public License as published by
>  # the Free Software Foundation; either version 2 of the License, or

let's leave unrelated changes out please

> @@ -5413,12 +5412,14 @@ func_mode_link ()
># -shared-libsan   Link with shared sanitizer runtimes (Clang)
># -static-libsan   Link with static sanitizer runtimes (Clang)
># -fuse-ld=*   Linker select flags for GCC
> +  # -f{file|debug|macro}-prefix-map* needed for lto linking

these take the form of -ffile-prefix-map=xxx right ?
so we'd want to put a = before the glob at the end ?
-mike


signature.asc
Description: PGP signature

Re: [PATCH 1/2] libtool: replace : with $PATH_SEPARATOR

[Mike Frysinger]

On 16 Jan 2024 23:44, KO Myung-Hun wrote:
> Some OSes such as OS/2, uses ';' as a path separator. So using
> $PATH_SEPARATOR instead of hard-coded ':' is more proper.

so we're on the same page, we're talking about the separator that is used in
the $PATH environment variable.  it doesn't show up in other places -- it is
not used to separate e.g. rpath entries right ?  what about LD_LIBRARY_PATH
and similar vars ?  i guess we assume the separator used by PATH is also used
with that var ?
-mike


signature.asc
Description: PGP signature

[PATCH] bootstrap: sync to latest version

[Mike Frysinger]

* gl-mod/bootstrap: Update.
* bootstrap: Likewise.
---
 bootstrap| 34 +-
 gl-mod/bootstrap |  2 +-
 2 files changed, 18 insertions(+), 18 deletions(-)

diff --git a/bootstrap b/bootstrap
index 8e0b5e83218d..e57ec940db68 100755
--- a/bootstrap
+++ b/bootstrap
@@ -9,11 +9,11 @@
 # This is free software.  There is NO warranty; not even for
 # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
 #
-# Copyright (C) 2010-2019, 2021 Bootstrap Authors
+# Copyright (C) 2010-2019, 2021, 2023 Bootstrap Authors
 #
 # This file is dual licensed under the terms of the MIT license
-# , and GPL version 2 or later
-# .  You must apply one of
+# , and GPL version 2 or later
+# .  You must apply one of
 # these licenses when using or redistributing this software or any of
 # the files within it.  See the URLs above, or the file `LICENSE`
 # included in the Bootstrap distribution for the full license texts.
@@ -48,7 +48,7 @@
 #   gl/build-aux/inline-source gl/build-aux/bootstrap.in > bootstrap
 #
 # You should then store than script in version control for other
-# developers in you project.  It will give you instructions about
+# developers in your project.  It will give you instructions about
 # how to keep it up to date if the sources change.
 #
 # See gl/doc/bootstrap.texi for documentation on how to write
@@ -235,11 +235,11 @@ scriptversion=2019-02-19.15; # UTC
 # This is free software.  There is NO warranty; not even for
 # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
 #
-# Copyright (C) 2004-2019, 2021 Bootstrap Authors
+# Copyright (C) 2004-2019, 2021, 2023 Bootstrap Authors
 #
 # This file is dual licensed under the terms of the MIT license
-# , and GPL version 2 or later
-# .  You must apply one of
+# , and GPL version 2 or later
+# .  You must apply one of
 # these licenses when using or redistributing this software or any of
 # the files within it.  See the URLs above, or the file `LICENSE`
 # included in the Bootstrap distribution for the full license texts.
@@ -306,7 +306,7 @@ nl='
 '
 IFS="$sp   $nl"
 
-# There are apparently some retarded systems that use ';' as a PATH separator!
+# There are apparently some systems that use ';' as a PATH separator!
 if test "${PATH_SEPARATOR+set}" != set; then
   PATH_SEPARATOR=:
   (PATH='/bin;/bin'; FPATH=$PATH; sh -c :) >/dev/null 2>&1 && {
@@ -1699,11 +1699,11 @@ func_lt_ver ()
 # This is free software.  There is NO warranty; not even for
 # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
 #
-# Copyright (C) 2010-2019, 2021 Bootstrap Authors
+# Copyright (C) 2010-2019, 2021, 2023 Bootstrap Authors
 #
 # This file is dual licensed under the terms of the MIT license
-# , and GPL version 2 or later
-# .  You must apply one of
+# , and GPL version 2 or later
+# .  You must apply one of
 # these licenses when using or redistributing this software or any of
 # the files within it.  See the URLs above, or the file `LICENSE`
 # included in the Bootstrap distribution for the full license texts.
@@ -2384,11 +2384,11 @@ func_version ()
 # This is free software.  There is NO warranty; not even for
 # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
 #
-# Copyright (C) 2010-2019, 2021 Bootstrap Authors
+# Copyright (C) 2010-2019, 2021, 2023 Bootstrap Authors
 #
 # This file is dual licensed under the terms of the MIT license
-# , and GPL version 2 or later
-# .  You must apply one of
+# , and GPL version 2 or later
+# .  You must apply one of
 # these licenses when using or redistributing this software or any of
 # the files within it.  See the URLs above, or the file `LICENSE`
 # included in the Bootstrap distribution for the full license texts.
@@ -3832,7 +3832,7 @@ for tool in autoconf libtoolize autopoint; do
   _G_version=$func_extract_trace_result
   test -n "$_G_version" && {
 func_append buildreq "\
-'$tool' $_G_version http://www.gnu.org/s/'$b'
+'$tool' $_G_version https://www.gnu.org/s/'$b'
 "
 func_verbose \
 "auto-adding '\'$tool'-$_G_version'\'' to build requirements"
@@ -3865,7 +3865,7 @@ func_require_buildreq_automake ()
 test -n "$automake_version" || automake_version=-
 
 func_append buildreq "\
-automake $automake_version http://www.gnu.org/s/automake
+automake $automake_version 

Re: [PATCH 1/3] Fix typos

[Mike Frysinger]

On 16 Jan 2024 17:59, Mike Frysinger wrote:
> merged, but please write ChangeLog entries in the commit message

i had to revert the changes to "bootstrap" as that isn't maintained here.
you'll want to send those fixes to that upstream:
https://github.com/gnulib-modules/bootstrap
-mike


signature.asc
Description: PGP signature

Re: [patch #10393] Fix shared library support on Android

[Bruno Haible]

Roumen Petrov wrote:
> Android and Microsoft windows must not encode any paths.

You probably mean to say: Shared libraries packaged in Android .apk
files are mentioned in the Android manifest file (elements 
and ) [1] and therefore don't need a RUNPATH.

But shared libraries created in the Termux environment are a different
case, and they do need a RUNPATH, as I explained in the previous mail.

> When I build PKIX-SSH and OpenSSL binaries I must ensure that those libraries 
> and executable could run in any Android profile.
> The packages are "SecureBox Pro" or SecureBox as add-on to "TermOne Plus".
> PKIX-SSH binaries use ldns as resolver library. This library uses libtool.

Again: If you want a certain binary that you build to have no RUNPATH, use the
Android SDK, not Termux and not libtool. Or use libtool outside of Termux
and don't provide a -R option.

> Also to ensure that binaries runs on support API levels elf-cleaner is should 
> be run to "strip" certain sections.

You mean [2] or [3]? I think this is out of scope for libtool, because:
  - As far as I understand, it applies to both shared libraries and
executables, and since executables can be created without using libtool,
the right place to invoke these tools are not in libtool.
  - As you say, it depends on the minimum supported Android API level, which
is a priori known to the Makefile and to the compiler (via '-target'
options), but not known to libtool.

Bruno

[1] https://developer.android.com/guide/topics/manifest/manifest-intro
[2] https://github.com/kost/android-elf-cleaner
[3] https://github.com/termux/termux-elf-cleaner

Re: [PATCH 1/3] Fix typos

[Mike Frysinger]

merged, but please write ChangeLog entries in the commit message
-mike


signature.asc
Description: PGP signature

[PATCH] cfg.mk: update old NEWS hash

[Mike Frysinger]

The recent change to change http:// to https:// updated old NEWS
entries.  This isn't exactly against the spirit of the "don't
change old NEWS", so update the hash to match.

* cfg.mk (old_NEWS_hash): Update.
---
 cfg.mk | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/cfg.mk b/cfg.mk
index fcf43e34d142..8bec8813353b 100644
--- a/cfg.mk
+++ b/cfg.mk
@@ -31,8 +31,8 @@ update-release-year:
-e "/^Copyright/ {s:[0-9][0-9][0-9][0-9]:$$year:} " \
m4/libtool.m4
 
-# Set format of NEWS
-old_NEWS_hash := 68e21416d15e517576ce749b131f
+# Set format of NEWS.
+old_NEWS_hash := 3e6638705e1c1ac7104260815a46c7bd
 
 manual_title = Portable Dynamic Shared Object Management
 
-- 
2.43.0

[PATCH] ChangeLog.old: Convert ISO-8859-1 to UTF-8

[Mike Frysinger]

From: Antonin D??cimo 

This file is mostly UTF-8 already, but some old entries were using
ISO-8859-1.  Change them to UTF-8 entirely.

* ChangeLog.old: Change ISO-8859-1 to UTF-8.

Copyright-paperwork-exempt: Yes
---
 ChangeLog.old | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/ChangeLog.old b/ChangeLog.old
index 8e2b51caad46..bb84e8047d0b 100644
--- a/ChangeLog.old
+++ b/ChangeLog.old
@@ -15551,7 +15551,7 @@
 
* libltdl/ltdl.c (foreach_dirinpath): Ensure that filename is '\0'
terminated by all code paths.
-   Reported by Lutz M?ller 
+   Reported by Lutz M??ller 
 
 2002-06-20  Gary V. Vaughan  
 
@@ -18669,7 +18669,7 @@
  and file_magic_cmd
 
* README: use 'libtool --version' instead of 'ltconfig --version'
- (suggested by Francios Pinard 
+ (suggested by Fran??ois Pinard 
 
 2000-01-10  Gary V. Vaughan  
 
@@ -19442,7 +19442,7 @@
 
* ltconfig.in: Support new GNU ld --help output format.
* NEWS:  Likewise.
-   Reported by Ga?l Qu?ri  and
+   Reported by Ga??l Qu??ri  and
H.J. Lu .
 
 1999-06-05  Mark Kettenis  
@@ -23515,7 +23515,7 @@ Thu May 28 18:59:08 1998  Ian Lance Taylor  

ld's.  From Eiichi Takamori.
 
* ltmain.in (install): Don't print silly `library stripping'
-   warnings.  Reported by Fran?ois Pinard.
+   warnings.  Reported by Fran??ois Pinard.
 
 1997-12-19  Gordon Matzigkeit  
 
@@ -23650,7 +23650,7 @@ Thu May 28 18:59:08 1998  Ian Lance Taylor  

because we need it for quoting substitutions.  For most of the
script, though, use the default echo, just like Autoconf does.
Without this patch, character \001 ends up in global_symbol_pipe.
-   Reported by Lars Hecking and J?rgen Fluk.
+   Reported by Lars Hecking and J??rgen Fluk.
 
* ltmain.in (echo): Set default to `echo=echo'.  Ooops.  That's
what you get for testing obscure code paths and forgetting to
-- 
2.43.0

Re: [PATCH 06/12] libtool.m4: Handle "/" as a sysroot correctly

[Richard Purdie]

On Mon, 2024-01-15 at 17:00 -0500, Mike Frysinger wrote:
> On 25 Oct 2021 15:33, Richard Purdie wrote:
> > Update libtool.m4 to resolve a problem with lt_sysroot not being properly
> > updated if the option '--with[-libtool]-sysroot' is not provided when
> > running the 'configure' script for a package so that "/" as a sysroot
> > is handled correctly by libtool.
> 
> this is a long sentence, and there's no concrete examples, so i'm having a
> bit of trouble extrapolating the bug.  can you tweak this a bit to make it
> more clear ?

I've resent with part of that patch and a clearer explanation of what
the issue is. I need to look into what the other bit of the patch is
doing, it looks a bit like two different changes became intertwined.

Cheers,

Richard

[PATCH] libtool.m4: Handle "/" as a sysroot more correctly

[Richard Purdie]

If $CC has --sysroot=/, it is a valid configuration however libtool will
then set lt_sysroot to "/".

This means references like $lt_sysroot$libdir become //usr/lib instead
of the more normally expected /usr/lib. This may or may not break something
but certainly is confusing to the user and gives confusing output. Making
"/" simply unset lt_sysroot is much cleaner.

* m4/libtool.m4: Improve '/' sysroot handling
---
 m4/libtool.m4 | 4 
 1 file changed, 4 insertions(+)

diff --git a/m4/libtool.m4 b/m4/libtool.m4
index 695ccac4..1c8ea182 100644
--- a/m4/libtool.m4
+++ b/m4/libtool.m4
@@ -1256,6 +1256,10 @@ case $with_sysroot in #(
  yes)
if test yes = "$GCC"; then
  lt_sysroot=`$CC --print-sysroot 2>/dev/null`
+ # Treat "/" the same a an unset sysroot to avoid ugly // expansion for 
$lt_sysroot$libdir
+ if test "$lt_sysroot" = /; then
+   lt_sysroot=
+ fi
fi
;; #(
  /*)
-- 
2.39.2

[PATCH] libtool: remove OpenBSD specific performance hack for ranlib

[Brad Smith]

libtool: remove OpenBSD specific performance hack for ranlib

The -t flag was used as a performance hack for ranlib. The flag was
supported by the GNU toolchain, but is a no-op with the LLVM toolchain.

* m4/libtool.m4: Remove use of -t flag with ranlib.
---
 m4/libtool.m4 | 9 +
 1 file changed, 1 insertion(+), 8 deletions(-)

diff --git a/m4/libtool.m4 b/m4/libtool.m4
index 4b84ce96..7ab5fe57 100644
--- a/m4/libtool.m4
+++ b/m4/libtool.m4
@@ -1555,15 +1555,8 @@ old_postinstall_cmds='chmod 644 $oldlib'
 old_postuninstall_cmds=
 
 if test -n "$RANLIB"; then
-  case $host_os in
-  openbsd*)
-old_postinstall_cmds="$old_postinstall_cmds~\$RANLIB -t \$tool_oldlib"
-;;
-  *)
-old_postinstall_cmds="$old_postinstall_cmds~\$RANLIB \$tool_oldlib"
-;;
-  esac
   old_archive_cmds="$old_archive_cmds~\$RANLIB \$tool_oldlib"
+  old_postinstall_cmds="$old_postinstall_cmds~\$RANLIB \$tool_oldlib"
 fi
 
 case $host_os in
-- 
2.43.0

Re: [patch #10393] Fix shared library support on Android

[Roumen Petrov]

Bruno Haible wrote:

Roumen Petrov wrote:

Android and Microsoft windows libraries must not use hard coded paths! 
Nevertheless what is supported by linker or loader.


Why do you mention Microsoft Windows? The commit 
47c71f61df9ace4956cc943f291480315174726b
has no effect on Microsoft Windows.


When I read commit I agree that is correct do not have RUNPATH!
The problem is that commit message is not so clear. Actually commit uses rpath 
flag!
NO! NO! NO!


Why do you want that executables never have RUNPATH on Android? Just saying
"NO! NO! NO!" is not a justification, and your arguments in [2] were not
sensible either.

If you want a certain binary that you build to have no RUNPATH, use the
Android SDK, not Termux and not libtool. Or use libtool outside of Termux
and don't provide a -R option. It's that easy.
[SNIP]


Android and Microsoft windows must not encode any paths.
When I build PKIX-SSH and OpenSSL binaries I must ensure that those libraries 
and executable could run in any Android profile.
The packages are "SecureBox Pro" or SecureBox as add-on to "TermOne Plus".
PKIX-SSH binaries use ldns as resolver library. This library uses libtool.

Also to ensure that binaries runs on support API levels elf-cleaner is should be run to 
"strip" certain sections.


Roumen

Re: [patch #10393] Fix shared library support on Android

[Bruno Haible]

Roumen Petrov wrote:
> Android and Microsoft windows libraries must not use hard coded paths! 
> Nevertheless what is supported by linker or loader.

Why do you mention Microsoft Windows? The commit 
47c71f61df9ace4956cc943f291480315174726b
has no effect on Microsoft Windows.

> When I read commit I agree that is correct do not have RUNPATH!
> The problem is that commit message is not so clear. Actually commit uses 
> rpath flag!
> NO! NO! NO!

Why do you want that executables never have RUNPATH on Android? Just saying
"NO! NO! NO!" is not a justification, and your arguments in [2] were not
sensible either.

If you want a certain binary that you build to have no RUNPATH, use the
Android SDK, not Termux and not libtool. Or use libtool outside of Termux
and don't provide a -R option. It's that easy.

The problem I was encountering, as described in [1], is in the Termux
environment, which uses absolute file names everywhere. In this environment,
the use of RUNPATH is mandatory. Without RUNPATH no executable that uses
a shared library would run. That's why the Termux people added a RUNPATH
value:

$ readelf -d /data/data/com.termux/files/usr/bin/cp | grep '\(RUNPATH\|NEEDED\)'
 0x001d (RUNPATH)Library runpath: 
[/data/data/com.termux/files/usr/lib]
 0x0001 (NEEDED) Shared library: [libandroid-support.so]
 0x0001 (NEEDED) Shared library: [libgmp.so]
 0x0001 (NEEDED) Shared library: [libiconv.so]
 0x0001 (NEEDED) Shared library: [libc.so]

$ readelf -d /data/data/com.termux/files/usr/bin/emacs | grep 
'\(RUNPATH\|NEEDED\)'
 0x001d (RUNPATH)Library runpath: 
[/data/data/com.termux/files/usr/lib]
 0x0001 (NEEDED) Shared library: [libxml2.so]
 0x0001 (NEEDED) Shared library: [libncursesw.so.6]
 0x0001 (NEEDED) Shared library: [libgnutls.so]
 0x0001 (NEEDED) Shared library: [libm.so]
 0x0001 (NEEDED) Shared library: [libz.so.1]
 0x0001 (NEEDED) Shared library: [libdl.so]
 0x0001 (NEEDED) Shared library: [libjansson.so]
 0x0001 (NEEDED) Shared library: [libgmp.so]
 0x0001 (NEEDED) Shared library: [libc.so]

The main remaining problem was that if a Termux user configures a
package with a non-default --prefix and that package installs a shared
library, the Termux-provided RUNPATH is insufficient: The program
would always only see the Termux-provided shared libraries. That's
where libtool support for -rpath is necessary.

Bruno

[1] https://lists.gnu.org/archive/html/libtool-patches/2023-09/msg0.html
[2] https://lists.gnu.org/archive/html/libtool-patches/2023-09/msg1.html

[PATCH] use https:// with more gnu.org sites

[Mike Frysinger]

* NEWS: Change http:// to https:// for some URIs.
* bootstrap.conf, build-aux/ltmain.in, configure.ac, libtoolize.in: Likewise.
---
 NEWS| 2 +-
 bootstrap.conf  | 8 
 build-aux/ltmain.in | 2 +-
 configure.ac| 2 +-
 libtoolize.in   | 2 +-
 5 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/NEWS b/NEWS
index 39a35e605488..5c0b614e6d55 100644
--- a/NEWS
+++ b/NEWS
@@ -1069,7 +1069,7 @@ New in 1.2d: 1998-12-16; CVS version 1.2c, Libtool team:
 * We now have anonymous CVS access to GNU libtool.  CVSROOT is
   :pserver:anon...@anoncvs.gnu.org:/gd/gnu/anoncvsroot.  The password
   is empty.  The directory is libtool.  Check our home-page at
-  http://www.gnu.org/software/libtool/libtool.html for details.
+  https://www.gnu.org/software/libtool/libtool.html for details.
 * Alexandre Oliva, Thomas Tanner and Gary V. Vaughan have taken over
   the maintenance of libtool.
 * Arguments to ltconfig have been changed to allow creation of a
diff --git a/bootstrap.conf b/bootstrap.conf
index 68295f640e90..bc91a67f8096 100644
--- a/bootstrap.conf
+++ b/bootstrap.conf
@@ -44,10 +44,10 @@ checkout_only_file=HACKING
 # List of programs (and minimum versions) required to bootstrap, maintain
 # and release Libtool.
 buildreq="
-help2man   1.29http://www.gnu.org/s/help2man
-make   3.81http://www.gnu.org/s/make
-makeinfo   4.8 http://www.gnu.org/s/texinfo
-xz 4.999.8beta http://tukaani.org/xz
+help2man   1.29https://www.gnu.org/s/help2man
+make   3.81https://www.gnu.org/s/make
+makeinfo   4.8 https://www.gnu.org/s/texinfo
+xz 4.999.8beta https://tukaani.org/xz
 "
 
 # Instructions on how to install packages in $buildreq.
diff --git a/build-aux/ltmain.in b/build-aux/ltmain.in
index d996f7986993..f2cede828049 100644
--- a/build-aux/ltmain.in
+++ b/build-aux/ltmain.in
@@ -162,7 +162,7 @@ include the following information:
 
 Report bugs to <@PACKAGE_BUGREPORT@>.
 GNU @PACKAGE@ home page: <@PACKAGE_URL@>.
-General help using GNU software: ."
+General help using GNU software: ."
 exit 0
 }
 
diff --git a/configure.ac b/configure.ac
index cc8113154d54..9aef55d3712e 100644
--- a/configure.ac
+++ b/configure.ac
@@ -35,7 +35,7 @@ AC_INIT([GNU Libtool],
m4_esyscmd([build-aux/git-version-gen .tarball-version]),
[bug-libt...@gnu.org])
 m4_ifndef([AC_PACKAGE_URL],
- [AC_SUBST([PACKAGE_URL], [http://www.gnu.org/s/libtool/])])
+ [AC_SUBST([PACKAGE_URL], [https://www.gnu.org/s/libtool/])])
 
 # Remove this when a released Autoconf is capable of bootstrapping
 # Libtool without it (probably after autoconf-2.70).
diff --git a/libtoolize.in b/libtoolize.in
index ecdf07f8af63..4c0c6cfbcf81 100644
--- a/libtoolize.in
+++ b/libtoolize.in
@@ -125,7 +125,7 @@ include the following information:
 
 Report bugs to <@PACKAGE_BUGREPORT@>.
 GNU @PACKAGE@ home page: <@PACKAGE_URL@>.
-General help using GNU software: ."
+General help using GNU software: ."
 exit 0
 }
 
-- 
2.43.0

Re: [patch #9442] Add flang (LLVM-based compiler) support

[Roumen Petrov]

Hi,


Mike Frysinger wrote:

Update of patch#9442 (group libtool):

   Status:None => Done
  Open/Closed:Open => Closed

 ___

Follow-up Comment #1:

i dropped the -DPIC part as no other target does it, and i think we handle
that in common code already.  feel free to follow up if you disagree.


Please note that by default libtool build shared and static objects .
When is build shared object -DPIC is set internally for shared build.
So to remove -DPIC looks harmless.

I guess that reporter could check this. See libtool manual:
...

Notice that the second run of GCC has its output discarded. This is done so 
that compiler warnings aren’t annoyingly duplicated. If you need to see both 
sets of warnings (you might have conditional code inside ‘#ifdef PIC’ for 
example), you can turn off suppression with the -no-suppress option to 
libtool’s compile mode:

burger$libtool --mode=compile gcc -no-suppress -g -O -c hello.c
gcc -g -O -c hello.c  -fPIC -DPIC -o .libs/hello.o
gcc -g -O -c hello.c -o hello.o
burger$





Regards,
Roumen Petrov

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

[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] libtool: remove bitrig support.

[Mike Frysinger]

On 16 Jan 2024 01:49, Brad Smith wrote:
> libtool: remove bitrig support.
> 
> Bitrig has been defunct for 7 years.

pushed, thanks
-mike


signature.asc
Description: PGP signature

Re: [PATCH 05/12] ltmain.in: Don't encode RATHS which match default linker paths

[Roumen Petrov]

Hi All

Information below is not enough to understand details.

Richard Purdie wrote:

On Mon, 2024-01-15 at 20:10 -0500, Mike Frysinger wrote:

On 25 Oct 2021 15:33, Richard Purdie wrote:

We don't want to add RPATHS which match default linker search paths, they're
a waste of space. This patch filters libtools list of paths to encoode and
removes the ones we don't need.


Libtool try to avoid search path used by run-time loader.
Note FSF version! Debian patched is know to be broken since decades.

There is a way to adapt old releases on Unix/Linux like build systems.
This is autoconf cache variable . I cannot remember exact name by is like 
lt_cv..dlsearch...path... (1)

If I remember well libtool release 2.4.7  adds configuration variable that 
allows default search path (2) to be set.


In my cross-builds scripts I use model (1) to exclude not only path passed to 
libtool with --with-sysroot argument but additional path.



how are you defining "linker" ?  are you talking about the runtime linker
(i.e. ld.so) or the build time linker (i.e. `ld`) ?

I meant the runtime linker/loader ld.so.


the commit message also doesn't really explain in concrete details the
scenario you're running into.

We were seeing binaries with RPATHS like /usr/lib in them which
basically doesn't do anything useful since it is a default for ld.so.
We were therefore trying to remove those to improve the efficiency of
the binaries slightly.

Cheers,

Richard


Regards,
Roumen Petrov

Re: [patch #10393] Fix shared library support on Android

[Roumen Petrov]

Hello,

When I read commit I agree that is correct do not have RUNPATH!
The problem is that commit message is not so clear. Actually commit uses rpath 
flag!
NO! NO! NO!

Android and Microsoft windows libraries must not use hard coded paths! 
Nevertheless what is supported by linker or loader.


Ileana Dumitrescu wrote:

Update of patch#10393 (group libtool):

   Status:None => Done
  Open/Closed:Open => Closed



[SNIP]

Regards,
Roumen Petrov

[patch #10417] Avoid deprecation warning with MSVC

[Ileana Dumitrescu]

Update of patch#10417 (group libtool):

  Status:None => Done   
 Open/Closed:Open => Closed 

___

Follow-up Comment #1:

Thank you for the patch! libtool went through a bit of a slow period where not
much was merged in, but I'm hoping to clean it up.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

[patch #10411] libtool: fix empty "-L" in compiler_lib_search_path

[Ileana Dumitrescu]

Update of patch#10411 (group libtool):

  Status:None => Done   
 Open/Closed:Open => Closed 

___

Follow-up Comment #1:

Thanks for finding the issue and submitting a patch! I'm surprised this string
check was incorrect for so long, without anyone noticing. 


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

Re: [PATCH 05/12] ltmain.in: Don't encode RATHS which match default linker paths

[Richard Purdie]

On Mon, 2024-01-15 at 20:10 -0500, Mike Frysinger wrote:
> On 25 Oct 2021 15:33, Richard Purdie wrote:
> > We don't want to add RPATHS which match default linker search paths, they're
> > a waste of space. This patch filters libtools list of paths to encoode and
> > removes the ones we don't need.
> 
> how are you defining "linker" ?  are you talking about the runtime linker
> (i.e. ld.so) or the build time linker (i.e. `ld`) ?

I meant the runtime linker/loader ld.so.

> the commit message also doesn't really explain in concrete details the
> scenario you're running into.

We were seeing binaries with RPATHS like /usr/lib in them which
basically doesn't do anything useful since it is a default for ld.so.
We were therefore trying to remove those to improve the efficiency of
the binaries slightly.

Cheers,

Richard

[PATCH 1/3] ltmain.in: Handle prefix-map compiler options correctly

[Richard Purdie]

If lto is enabled, we need the prefix-map variables to be passed to the linker
to correctly link the objects using correctly mapped paths.

Add these to the list of options libtool passes through.

* build-aux/ltmain.in: Handle prefix-map compiler options
---
 build-aux/ltmain.in | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/build-aux/ltmain.in b/build-aux/ltmain.in
index d5157a8d..34784c8c 100644
--- a/build-aux/ltmain.in
+++ b/build-aux/ltmain.in
@@ -7,7 +7,6 @@
 # Copyright (C) 1996-2019, 2021-2024 Free Software Foundation, Inc.
 # This is free software; see the source for copying conditions.  There is NO
 # warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
-
 # GNU Libtool is free software; you can redistribute it and/or modify
 # it under the terms of the GNU General Public License as published by
 # the Free Software Foundation; either version 2 of the License, or
@@ -5413,12 +5412,14 @@ func_mode_link ()
   # -shared-libsan   Link with shared sanitizer runtimes (Clang)
   # -static-libsan   Link with static sanitizer runtimes (Clang)
   # -fuse-ld=*   Linker select flags for GCC
+  # -f{file|debug|macro}-prefix-map* needed for lto linking
   # -Wa,*Pass flags directly to the assembler
   # -Werror, -Werror=*   Report (specified) warnings as errors
   -64|-mips[0-9]|-r[0-9][0-9]*|-xarch=*|-xtarget=*|+DA*|+DD*|-q*|-m*| \
   
-t[45]*|-txscale*|-p|-pg|--coverage|-fprofile-*|-F*|@*|-tp=*|--sysroot=*| \
   
-O*|-g*|-flto*|-fwhopr*|-fuse-linker-plugin|-fstack-protector*|-stdlib=*| \
   -specs=*|-fsanitize=*|-fno-sanitize*|-shared-libsan|-static-libsan| \
+  -ffile-prefix-map*|-fdebug-prefix-map*|-fmacro-prefix-map*| \
   -fdiagnostics-color*|-frecord-gcc-switches| \
   -fuse-ld=*|-Wa,*|-Werror|-Werror=*)
 func_quote_arg pretty "$arg"
-- 
2.39.2

[PATCH 2/3] ltmain.in: Parse additional clang options

[Richard Purdie]

clang uses -rtlib and --unwindlib to select proper compiler runtime in
some cases. Therefore pass these options to linker when found in
ldflags

* build-aux/ltmain.in: Handle clang linker options
---
 build-aux/ltmain.in | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/build-aux/ltmain.in b/build-aux/ltmain.in
index 34784c8c..cf6dc13a 100644
--- a/build-aux/ltmain.in
+++ b/build-aux/ltmain.in
@@ -5412,12 +5412,14 @@ func_mode_link ()
   # -shared-libsan   Link with shared sanitizer runtimes (Clang)
   # -static-libsan   Link with static sanitizer runtimes (Clang)
   # -fuse-ld=*   Linker select flags for GCC
+  # -rtlib=* select c runtime lib with clang
+  # --unwindlib=*select unwinder library with clang
   # -f{file|debug|macro}-prefix-map* needed for lto linking
   # -Wa,*Pass flags directly to the assembler
   # -Werror, -Werror=*   Report (specified) warnings as errors
   -64|-mips[0-9]|-r[0-9][0-9]*|-xarch=*|-xtarget=*|+DA*|+DD*|-q*|-m*| \
   
-t[45]*|-txscale*|-p|-pg|--coverage|-fprofile-*|-F*|@*|-tp=*|--sysroot=*| \
-  
-O*|-g*|-flto*|-fwhopr*|-fuse-linker-plugin|-fstack-protector*|-stdlib=*| \
+  
-O*|-g*|-flto*|-fwhopr*|-fuse-linker-plugin|-fstack-protector*|-stdlib=*|-rtlib=*|--unwindlib=*|
 \
   -specs=*|-fsanitize=*|-fno-sanitize*|-shared-libsan|-static-libsan| \
   -ffile-prefix-map*|-fdebug-prefix-map*|-fmacro-prefix-map*| \
   -fdiagnostics-color*|-frecord-gcc-switches| \
-- 
2.39.2

[PATCH 3/3] libtool: Fix support for NIOS2 processor

[Richard Purdie]

The name of the system contains the string "nios2". This string
is caught by the some of the greedy checks for OS/2 in libtool,
in particular the *os2* branches of switch statements match for
the nios2 string, which results in incorrect behavior of libtool.

Switch to use $host_os instead of $host and tweak the patterns to
match to avoid this problem for nios2.

* build-aux/ltmain.in: Fix NIOS2 support
---
 build-aux/ltmain.in | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/build-aux/ltmain.in b/build-aux/ltmain.in
index cf6dc13a..ac11b7ae 100644
--- a/build-aux/ltmain.in
+++ b/build-aux/ltmain.in
@@ -517,10 +517,10 @@ libtool_validate_options ()
 # preserve --debug
 test : = "$debug_cmd" || func_append preserve_args " --debug"
 
-case $host in
+case $host_os in
   # Solaris2 added to fix 
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=16452
   # see also: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59788
-  *cygwin* | *mingw* | *windows* | *pw32* | *cegcc* | *solaris2* | *os2*)
+  cygwin* | mingw* | windows* | pw32* | cegcc* | solaris2* | os2*)
 # don't eliminate duplications in $postdeps and $predeps
 opt_duplicate_compiler_generated_deps=:
 ;;
@@ -6279,8 +6279,8 @@ func_mode_link ()
fi
if test -n "$library_names" &&
   { test no = "$use_static_libs" || test -z "$old_library"; }; then
- case $host in
- *cygwin* | *mingw* | *windows* | *cegcc* | *os2*)
+ case $host_os in
+ cygwin* | mingw* | windows* | cegcc* | os2*)
  # No point in relinking DLLs because paths are not encoded
  func_append notinst_deplibs " $lib"
  need_relink=no
@@ -6349,8 +6349,8 @@ func_mode_link ()
  soname=$dlname
elif test -n "$soname_spec"; then
  # bleh windows
- case $host in
- *cygwin* | mingw* | *windows* | *cegcc* | *os2*)
+ case $host_os in
+ cygwin* | mingw* | windows* | cegcc* | os2*)
func_arith $current - $age
major=$func_arith_result
versuffix=-$major
-- 
2.39.2

Re: [PATCH 1/2] libtool: replace : with $PATH_SEPARATOR

[KO Myung-Hun]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi/2.

Mike Frysinger wrote:
> On 15 Jan 2024 21:15, KO Myung-Hun wrote:
>> Mike Frysinger wrote:
>>> On 15 Oct 2023 02:04, KO Myung-Hun wrote:
 Some OSes such as OS/2, uses ';' as a path separator. So
 using $PATH_SEPARATOR instead of hard-coded ':' is more
 proper.
 
 * build-aux-ltmain.in: replace : with $PATH_SEPARATOR. * 
 m4/libtool.m4: Likewise.
>>> 
>>> this doesn't work for me
>>> 
>>> 544675d6b538 2024-01-14 18:06:03 -0500 gnulib: update submodule
>>> to current versions
>>> 
>>> $ ./bootstrap $ ./configure ... checking for mt... no checking
>>> if : is a manifest tool... no ./configure: 1: Syntax error:
>>> Unterminated quoted string $ -mike
>> 
>> How about this?
> 
> it passes configure, but fails `make check` & `make syntax-check`. 
> -mike

Another try.

- -- 
KO Myung-Hun

Korean OS/2 User Community : https://www.os2.kr/
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (OS/2)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iD8DBQFlppZFE9YstvghgroRAjFKAJ0fQTTh4qTJtgRvd/pI2TSeFIf4xgCeNEWF
mWoDIYiA2aMRvGaFs3ES9cE=
=fXIc
-END PGP SIGNATURE-
From 11d5ba83c5211ec7e149f3170bbaf7d49e6448da Mon Sep 17 00:00:00 2001
From: KO Myung-Hun 
Date: Thu, 3 Nov 2022 23:32:37 +0900
Subject: [PATCH v3 1/2] libtool: replace : with $PATH_SEPARATOR

Some OSes such as OS/2, uses ';' as a path separator. So using
$PATH_SEPARATOR instead of hard-coded ':' is more proper.

* Makefile.am (TESTS_ENVIRONMENT): Pass $PATH_SEPARATOR.
* build-aux-ltmain.in: Replace : with $PATH_SEPARATOR.
* m4/libtool.m4: Likewise.
---
 Makefile.am |  1 +
 build-aux/ltmain.in | 76 ++---
 m4/libtool.m4   | 16 +-
 3 files changed, 47 insertions(+), 46 deletions(-)

diff --git a/Makefile.am b/Makefile.am
index 904f3d73..d2838ad2 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -745,6 +745,7 @@ TESTS_ENVIRONMENT = MAKE="$(MAKE)" CC="$(CC)" CFLAGS="$(CFLAGS)" \
 	F77="$(F77)" FFLAGS="$(FFLAGS)" \
 	FC="$(FC)" FCFLAGS="$(FCFLAGS)" \
 	GCJ="$(GCJ)" GCJFLAGS="$(GCJFLAGS)" \
+	PATH_SEPARATOR="$(PATH_SEPARATOR)" \
 	lt_cv_with_aix_soname="$(with_aix_soname)" \
 	lt_cv_to_host_file_cmd="$(to_host_file_cmd)" \
 	lt_cv_to_tool_file_cmd="$(to_tool_file_cmd)"
diff --git a/build-aux/ltmain.in b/build-aux/ltmain.in
index d5157a8d..8e596847 100644
--- a/build-aux/ltmain.in
+++ b/build-aux/ltmain.in
@@ -733,8 +733,8 @@ func_resolve_sysroot ()
 # store the result into func_replace_sysroot_result.
 func_replace_sysroot ()
 {
-  case $lt_sysroot:$1 in
-  ?*:"$lt_sysroot"*)
+  case $lt_sysroot$PATH_SEPARATOR$1 in
+  ?*$PATH_SEPARATOR$lt_sysroot*)
 func_stripname "$lt_sysroot" '' "$1"
 func_replace_sysroot_result='='$func_stripname_result
 ;;
@@ -2007,7 +2007,7 @@ func_mode_execute ()
   if eval "test -z \"\$$shlibpath_var\""; then
 	eval "$shlibpath_var=\"\$dir\""
   else
-	eval "$shlibpath_var=\"\$dir:\$$shlibpath_var\""
+	eval "$shlibpath_var=\"\$dir\$PATH_SEPARATOR\$$shlibpath_var\""
   fi
 done
 
@@ -3579,7 +3579,7 @@ func_exec_program ()
 	if test -n "$dllsearchpath"; then
 	  $ECHO "\
 # Add the dll search path components to the executable PATH
-PATH=$dllsearchpath:\$PATH
+PATH=\"$dllsearchpath$PATH_SEPARATOR\$PATH\"
 "
 	fi
 
@@ -3591,7 +3591,7 @@ func_exec_program ()
 
 # Some systems cannot cope with colon-terminated $shlibpath_var
 # The second colon is a workaround for a bug in BeOS R4 sed
-$shlibpath_var=\`\$ECHO \"\$$shlibpath_var\" | $SED 's/::*\$//'\`
+$shlibpath_var=\`\$ECHO \"\$$shlibpath_var\" | $SED 's/$PATH_SEPARATOR$PATH_SEPARATOR*\$//'\`
 
 export $shlibpath_var
 "
@@ -3802,7 +3802,7 @@ EOF
 	fi
 
 	if test -n "$dllsearchpath"; then
-  func_to_host_path "$dllsearchpath:"
+  func_to_host_path "$dllsearchpath$PATH_SEPARATOR"
 	  cat 

Re: [PATCH 2/3] Fix ChangeLog.old encoding

[Antonin Décimo]

Le dim. 14 janv. 2024 à 06:34, Mike Frysinger  a écrit :
>
> On 23 Nov 2023 09:44, Antonin Décimo wrote:
> > Copyright-paperwork-exempt: Yes
> > ---
> >  ChangeLog.old | 10 +-
> >  1 file changed, 5 insertions(+), 5 deletions(-)
> >
> > diff --git a/ChangeLog.old b/ChangeLog.old
> > index 8e2b51ca..51d7859d 100644
> > --- a/ChangeLog.old
> > +++ b/ChangeLog.old
> > @@ -15551,7 +15551,7 @@
> >
> >   * libltdl/ltdl.c (foreach_dirinpath): Ensure that filename is '\0'
> >   terminated by all code paths.
> > - Reported by Lutz M?ller 
> > + Reported by Lutz M?ller 
>
> not sure what you mean by "fix" here.  were you trying to convert the
> various ISO-8859-1 sequences with UTF-8 ?  your patch didn't come across
> the mailing list correctly if so.  can you compress + resend ?  and put
> a little more detail into the commit message ?
> -mike

Indeed, I was trying to convert the file to UTF-8. I think it was
either git or my editor or some tool in the middle which raised
warnings. Sorry for the problem that appeared with the email… Once
it's gone, there's no catching back.
May I suggest that, if you have direct write access to the repository,
it might be easier as a maintainer to convert the file to UTF-8?
Thanks for merging the other patches.
-- Antonin

[patch #10393] Fix shared library support on Android

[Ileana Dumitrescu]

Update of patch#10393 (group libtool):

  Status:None => Done   
 Open/Closed:Open => Closed 

___

Follow-up Comment #1:

I went ahead and merged this in. Thanks for the patch!


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

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

[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

[Richard Purdie]