[PATCH] Fix mingw _putenv warning

[Jonathan Yong]

This was breaking mpg123 if CFLAGS has -pedantic -Werror.

Refresh of the patch from:
https://lists.gnu.org/archive/html/libtool/2011-06/msg00040.html

_putenv is always __cdecl and is always dllimported from the OS C 
runtime DLL.From 74bae2bbd96cf38eeda3495bedfcd7f5b90680fb Mon Sep 17 00:00:00 2001
From: Jonathan Yong <10wa...@gmail.com>
Date: Sun, 19 Mar 2023 12:03:33 +
Subject: [PATCH] libtool: fix long standing mingw _putenv warning

Fixes build if -Werror -pendantic is enabled in CFLAGS.
The MS specific _putenv in MinGW* will always be __cdecl and
will always be coming from the OS C runtime DLL, with no plans
for a static reimplementation.

Signed-off-by: Jonathan Yong <10wa...@gmail.com>
---
 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 3b76bd08..21330576 100644
--- a/build-aux/ltmain.in
+++ b/build-aux/ltmain.in
@@ -3662,7 +3662,8 @@ EOF
 /* declarations of non-ANSI functions */
 #if defined __MINGW32__
 # ifdef __STRICT_ANSI__
-int _putenv (const char *);
+/* mingw _putenv is always from the C runtime DLL, and it is always __cdecl ABI */
+_CRTIMP int __cdecl _putenv (const char *);
 # endif
 #elif defined __CYGWIN__
 # ifdef __STRICT_ANSI__
-- 
2.40.0

Patch to set correct compiler flags for 'armflang' on 'aarch64'

[Francois Coppens]

Dear libtool-patches,

On Linux on 'aarch64' using the 'armflang' compiler I got the following 
error:


  FCLD src/libqmckl.la
clang-13: error: unknown argument: '-soname'
clang-13: error: no such file or directory: 'libqmckl.so.0'
make[2]: *** [Makefile:1203: src/libqmckl.la] Error 1
make[2]: Leaving directory '/users/m23005/scemama/qmckl'
make[1]: *** [Makefile:1520: all-recursive] Error 1
make[1]: Leaving directory '/users/m23005/scemama/qmckl'
make: *** [Makefile:1046: all] Error 2

John C. Linford  from ARM suggested the following 
workaround for end users:


$ ./configure ...
$ sed -i -e 's#wl=""#wl="-Wl,"#g' libtool
$ sed -i -e 's#pic_flag=""#pic_flag=" -fPIC -DPIC"#g' libtool
$ make

This works, so I patched the 'libtool.m4' file to include  the correct 
flags for the 'armflang' compiler:


$ git format-patch --stdout origin/master

From 3657095457c4a311f3e775c6267b11c575e7c245 Mon Sep 17 00:00:00 2001
From: Francois Coppens 
Date: Fri, 10 Feb 2023 15:36:16 +0100
Subject: [PATCH] armflang patch
---
 m4/libtool.m4 | 6 ++
 1 file changed, 6 insertions(+)
diff --git a/m4/libtool.m4 b/m4/libtool.m4
index 79a2451e..df1a7860 100644
--- a/m4/libtool.m4
+++ b/m4/libtool.m4
@@ -4719,6 +4719,12 @@ m4_if([$1], [CXX], [
_LT_TAGVAR(lt_prog_compiler_pic, $1)='-fPIC'P
_LT_TAGVAR(lt_prog_compiler_static, $1)='-static'
 ;;
+  # ARM flang
+  armflang*)
+_LT_TAGVAR(lt_prog_compiler_wl, $1)='-Wl,'
+_LT_TAGVAR(lt_prog_compiler_pic, $1)='-fPIC'
+_LT_TAGVAR(lt_prog_compiler_static, $1)='-static
+;;
   # Lahey Fortran 8.1.
   lf95*)
_LT_TAGVAR(lt_prog_compiler_wl, $1)='-Wl,'


This works as well and the end user does no longer have to use the 
proposed workaround.


I remain at your disposal for more inforation if needed.

With kind regards,
Francois Coppens

[patch #9467] Fix -export-symbols and -export-symbols-regex support on Solaris 11.3

[Bruno Haible]

Follow-up Comment #1, patch #9467 (project libtool):

This patch is also needed for Solaris 11.4.


___

Reply to this item at:

  

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

[PATCH] libtool.m4: fix typos

[Jakub Wilk]

---
 m4/libtool.m4 | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/m4/libtool.m4 b/m4/libtool.m4
index 79a2451e..f14114cf 100644
--- a/m4/libtool.m4
+++ b/m4/libtool.m4
@@ -15,7 +15,7 @@ m4_define([_LT_COPYING], [dnl
 
 # 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 of the License, or
+# the Free Software Foundation; either version 2 of the License, or
 # (at your option) any later version.
 #
 # As a special exception to the GNU General Public License, if you
@@ -616,7 +616,7 @@ m4_popdef([AS_MESSAGE_LOG_FD])])])# _LT_GENERATED_FILE_INIT
 # LT_OUTPUT
 # -
 # This macro allows early generation of the libtool script (before
-# AC_OUTPUT is called), incase it is used in configure for compilation
+# AC_OUTPUT is called), in case it is used in configure for compilation
 # tests.
 AC_DEFUN([LT_OUTPUT],
 [: ${CONFIG_LT=./config.lt}
@@ -653,7 +653,7 @@ configured by $[0], generated by m4_PACKAGE_STRING.
 
 Copyright (C) 2011 Free Software Foundation, Inc.
 This config.lt script is free software; the Free Software Foundation
-gives unlimited permision to copy, distribute and modify it."
+gives unlimited permission to copy, distribute and modify it."
 
 while test 0 != $[#]
 do
@@ -1495,7 +1495,7 @@ _LT_DECL([], [AR], [1], [The archiver])
 
 # Use ARFLAGS variable as AR's operation code to sync the variable naming with
 # Automake.  If both AR_FLAGS and ARFLAGS are specified, AR_FLAGS should have
-# higher priority because thats what people were doing historically (setting
+# higher priority because that's what people were doing historically (setting
 # ARFLAGS for automake and AR_FLAGS for libtool).  FIXME: Make the AR_FLAGS
 # variable obsoleted/removed.
 
@@ -2887,7 +2887,7 @@ linux* | k*bsd*-gnu | kopensolaris*-gnu | gnu*)
   # before this can be enabled.
   hardcode_into_libs=yes
 
-  # Ideally, we could use ldconfig to report *all* directores which are
+  # Ideally, we could use ldconfig to report *all* directories which are
   # searched for libraries, however this is still not possible.  Aside from not
   # being certain /sbin/ldconfig is available, command
   # 'ldconfig -N -X -v | grep ^/' on 64bit Fedora does not report /usr/lib64,
@@ -6174,7 +6174,7 @@ _LT_TAGDECL([], [hardcode_direct], [0],
 _LT_TAGDECL([], [hardcode_direct_absolute], [0],
 [Set to "yes" if using DIR/libNAME$shared_ext during linking hardcodes
 DIR into the resulting binary and the resulting library dependency is
-"absolute", i.e impossible to change by setting $shlibpath_var if the
+"absolute", i.e. impossible to change by setting $shlibpath_var if the
 library is relocated])
 _LT_TAGDECL([], [hardcode_minus_L], [0],
 [Set to "yes" if using the -LDIR flag during linking hardcodes DIR
-- 
2.39.0

[PATCH] testsuite: Fix C99 compatibility issue in lt_dlopen_a.at

[Florian Weimer]

Include  for the strcmp function.  This improves C99
compiler compatibility because it avoids an implicit function
declaration.

---
 tests/lt_dlopen_a.at | 1 +
 1 file changed, 1 insertion(+)

diff --git a/tests/lt_dlopen_a.at b/tests/lt_dlopen_a.at
index 95f18a0d..d3948738 100644
--- a/tests/lt_dlopen_a.at
+++ b/tests/lt_dlopen_a.at
@@ -27,6 +27,7 @@ AT_KEYWORDS([libltdl lt_dlopen_a])
 AT_DATA([main.c],
 [[#include 
 #include 
+#include 
 
 /* This dlopen() in the main executable should override any dlopen()s in
shared libraries etc.

base-commit: 1ec8fa28dcb29500d485c136db28315671ec4c3b

GCC Patch Tracking [https://lists.gnu.org/archive/html/libtool-patches/2011-01/msg00026.html]

[Shinde, Yash]

https://lists.gnu.org/archive/html/libtool-patches/2011-01/msg00026.html
Submission Date- Sun, 16 Jan 2011
Upstream-Status: Submitted

The given Libtool patch is with it’s current status as ‘Submitted’ but still is 
not taken to the upstream. Please let us know about why the patch is not taken 
to the upstream or let us know if there is any problem in including it in 
upstream.


Regards,
Yash.

[PATCH] tests: Fix grep warning about stray \ before /

[Frederic Berat]

From: Frédéric Bérat 

Recent version of grep emit a warning if stray \ is found before /.
This leads to the link-order test failure.

 * tests/link-order.at: Remove unneeded \ before /
---
 tests/link-order.at | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/tests/link-order.at b/tests/link-order.at
index 3f01a00d..a145347f 100644
--- a/tests/link-order.at
+++ b/tests/link-order.at
@@ -99,12 +99,12 @@ aix* | interix*) ;;  # These systems have different path 
syntax
   case $hardcode_direct$hardcode_direct_absolute in
   yesno)
 AT_CHECK([if $EGREP relinking stderr; then
- $EGREP " .*\/new\/lib/libb$shared_ext .*\/old\/lib/libcee$shared_ext" 
stdout
+ $EGREP " .*/new/lib/libb$shared_ext .*/old/lib/libcee$shared_ext" 
stdout
else :; fi], [0], [ignore], [], [echo "wrong link order"])
 ;;
   *)
 AT_CHECK([if $EGREP relinking stderr; then
- $EGREP " -L.*\/new\/lib -lb -L.*\/old\/lib -lcee" stdout
+ $EGREP " -L.*/new/lib -lb -L.*/old/lib -lcee" stdout
else :; fi], [0], [ignore], [], [echo "wrong link order"])
 ;;
   esac
-- 
2.38.1

[PATCH] Support "-fno-sanitize*" options.

[Manoj Gupta]

"-fno-sanitize*" options e.g. -fno-sanitize=alignment
or -fno-sanitize-recover=all are used to tune the behvior of
sanitizers in GCC/clang. Let libtool pass these options
to compiler similar to fsanitize=*.

Signed-off-by: Manoj Gupta 
---
 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 a5f21a1d..d7b96d35 100644
--- a/build-aux/ltmain.in
+++ b/build-aux/ltmain.in
@@ -5406,12 +5406,13 @@ func_mode_link ()
   # -specs=* GCC specs files
   # -stdlib=*select c++ std lib with clang
   # -fsanitize=* Clang/GCC memory and address sanitizer
+  # -fno-sanitize*   Clang/GCC memory and address sanitizer
   # -fuse-ld=*   Linker select flags for GCC
   # -Wa,*Pass flags directly to the assembler
   -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=*|-fuse-ld=*|-Wa,*)
+  -specs=*|-fsanitize=*|-fno-sanitize*|-fuse-ld=*|-Wa,*)
 func_quote_arg pretty "$arg"
arg=$func_quote_arg_result
 func_append compile_command " $arg"
-- 
2.39.0.314.g84b9a713c41-goog

Re: [PATCH] Allow -Werror and -Werror=* through flag filtering

[Alex Ameen]

Merged. Thank you for your contribution.

https://git.savannah.gnu.org/cgit/libtool.git/commit/?id=1ec8fa28dcb29500d485c136db28315671ec4c3b

On 12/9/22 20:33, Sam James wrote:

* build-aux/ltmain.in (func_mode_link): allow -Werror and -Werror=* through
   flat filtering at link time.

   This is needed for detecting likely-runtime problems with LTO using
   e.g. -Werror=odr or -Werror=lto-type-mismatch.

Bug: https://bugs.gentoo.org/884767
Signed-off-by: Sam James 
---
  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 a5f21a1d..3b76bd08 100644
--- a/build-aux/ltmain.in
+++ b/build-aux/ltmain.in
@@ -5408,10 +5408,11 @@ func_mode_link ()
# -fsanitize=* Clang/GCC memory and address sanitizer
# -fuse-ld=*   Linker select flags for GCC
# -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=*|-fuse-ld=*|-Wa,*)
+  -specs=*|-fsanitize=*|-fuse-ld=*|-Wa,*|-Werror|-Werror=*)
  func_quote_arg pretty "$arg"
arg=$func_quote_arg_result
  func_append compile_command " $arg"

Re: [PATCH] Allow -Werror and -Werror=* through flag filtering

[Alex Ameen]

Thanks I'll take this for a spin and keep you in the loop.

On 12/9/22 20:33, Sam James wrote:

* build-aux/ltmain.in (func_mode_link): allow -Werror and -Werror=* through
   flat filtering at link time.

   This is needed for detecting likely-runtime problems with LTO using
   e.g. -Werror=odr or -Werror=lto-type-mismatch.

Bug: https://bugs.gentoo.org/884767
Signed-off-by: Sam James 
---
  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 a5f21a1d..3b76bd08 100644
--- a/build-aux/ltmain.in
+++ b/build-aux/ltmain.in
@@ -5408,10 +5408,11 @@ func_mode_link ()
# -fsanitize=* Clang/GCC memory and address sanitizer
# -fuse-ld=*   Linker select flags for GCC
# -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=*|-fuse-ld=*|-Wa,*)
+  -specs=*|-fsanitize=*|-fuse-ld=*|-Wa,*|-Werror|-Werror=*)
  func_quote_arg pretty "$arg"
arg=$func_quote_arg_result
  func_append compile_command " $arg"

[PATCH] Allow -Werror and -Werror=* through flag filtering

[Sam James]

* build-aux/ltmain.in (func_mode_link): allow -Werror and -Werror=* through
  flat filtering at link time.

  This is needed for detecting likely-runtime problems with LTO using
  e.g. -Werror=odr or -Werror=lto-type-mismatch.

Bug: https://bugs.gentoo.org/884767
Signed-off-by: Sam James 
---
 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 a5f21a1d..3b76bd08 100644
--- a/build-aux/ltmain.in
+++ b/build-aux/ltmain.in
@@ -5408,10 +5408,11 @@ func_mode_link ()
   # -fsanitize=* Clang/GCC memory and address sanitizer
   # -fuse-ld=*   Linker select flags for GCC
   # -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=*|-fuse-ld=*|-Wa,*)
+  -specs=*|-fsanitize=*|-fuse-ld=*|-Wa,*|-Werror|-Werror=*)
 func_quote_arg pretty "$arg"
arg=$func_quote_arg_result
 func_append compile_command " $arg"
-- 
2.38.1

Re: [PATCH v2 00/12] Rebased version of Yocto patches

[Alex Ameen]

Apologies for being unreachable, I'll revisit these today.


On Sun, Nov 20, 2022 at 5:30 AM Richard Purdie <
richard.pur...@linuxfoundation.org> wrote:

> On Sat, 2022-11-19 at 18:32 +, Sam James wrote:
> >
> > > On 16 Apr 2022, at 18:58, Sam James  wrote:
> > >
> > > Done after discussion w/ Alex (thanks!). Rebased on master after
> > > 2.4.7 release.
> >
> > Ping. Could we maybe get the easy ones in and then revisit
> > the bits which received comments (unclear to me what we need
> > to do for those)?
>
> I'd second that, I'd love to get the easy ones sorted and am happy to
> try and help with the others, just not quite sure where we stand at the
> moment.
>
> Cheers,
>
> Richard
>


-- 
Alex Ameen
Tel: (832) 341-9270

Re: [PATCH v2 00/12] Rebased version of Yocto patches

[Richard Purdie]

On Sat, 2022-11-19 at 18:32 +, Sam James wrote:
> 
> > On 16 Apr 2022, at 18:58, Sam James  wrote:
> > 
> > Done after discussion w/ Alex (thanks!). Rebased on master after
> > 2.4.7 release.
> 
> Ping. Could we maybe get the easy ones in and then revisit
> the bits which received comments (unclear to me what we need
> to do for those)?

I'd second that, I'd love to get the easy ones sorted and am happy to
try and help with the others, just not quite sure where we stand at the
moment.

Cheers,

Richard

Re: [PATCH v2 00/12] Rebased version of Yocto patches

[Sam James]

> On 16 Apr 2022, at 18:58, Sam James  wrote:
> 
> Done after discussion w/ Alex (thanks!). Rebased on master after
> 2.4.7 release.

Ping. Could we maybe get the easy ones in and then revisit
the bits which received comments (unclear to me what we need
to do for those)?


signature.asc
Description: Message signed with OpenPGP

[patch #10275] link-order.at: fix tests with GNU grep 3.8

[Santiago Ruano Rincón]

Follow-up Comment #2, patch #10275 (project libtool):

[comment #1 comment #1:]
> Oh, I see I independently reported the bug and proposed a more-complete
patch in patch #10202. Sorry about the duplication.

JFTR, the correct number is patch #10282


___

Reply to this item at:

  

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

[patch #10282] port libtool to grep 3.8 and to POSIX

[Paul Eggert]

Follow-up Comment #3, patch #10282 (project libtool):

[comment #2 comment #2:]

> Did you test to see if the new pattern still works with `grep` < 3.8 by any
chance?
Yes, it works.

> Just to check my understanding here: the intention of `[[-]]L` is to escape
`"[-]L"` in M4, taking advantage of the old `grep "[-]-not-an-option";` trick
to force grep to recognize argument 1 as a pattern rather than a flag?
Yes, that's right.

> The one I didn't totally understand was removing the `@<:@` handler; mostly
because I don't remember the context off hand. 
Without the patch, a test is generated that runs a shell command like this:


grep '\]'


This usage of grep is not portable, since POSIX says that the regular
expression \] has undefined effect (unlike \[ which is well defined to match
an opening square bracket). A failure of the test does not mean that grep is
broken; it means libtool is broken. To fix libtool, we should remove the
incorrect test.


___

Reply to this item at:

  

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

[patch #10282] port libtool to grep 3.8 and to POSIX

[Alex Ameen]

Follow-up Comment #2, patch #10282 (project libtool):

Thanks for the report and patch. 

Did you test to see if the new pattern still works with `grep` < 3.8 by any
chance?

Just to check my understanding here: the intention of `[[-]]L` is to escape
`"[-]L"` in M4, taking advantage of the old `grep "[-]-not-an-option";` trick
to force grep to recognize argument 1 as a pattern rather than a flag? This
one makes sense to me. 

The one I didn't totally understand was removing the `@<:@` handler; mostly
because I don't remember the context off hand. 




___

Reply to this item at:

  

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

[patch #10275] link-order.at: fix tests with GNU grep 3.8

[Paul Eggert]

Follow-up Comment #1, patch #10275 (project libtool):

Oh, I see I independently reported the bug and proposed a more-complete patch
in patch #10202. Sorry about the duplication.


___

Reply to this item at:

  

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

[patch #10282] port libtool to grep 3.8 and to POSIX

[Paul Eggert]

Follow-up Comment #1, patch #10282 (project libtool):

This patch partly duplicates patch #10275, but it is more complete as it fixes
more instances of the problem. Sorry I did not notice this earlier. I do not
know how to merge the patch requests.


___

Reply to this item at:

  

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

[patch #10282] port libtool to grep 3.8 and to POSIX

[Paul Eggert]

URL:
  

 Summary: port libtool to grep 3.8 and to POSIX
 Project: GNU Libtool
   Submitter: eggert
   Submitted: Mon 19 Sep 2022 01:27:13 PM PDT
Category: None
Priority: 5 - Normal
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any


___

Follow-up Comments:


---
Date: Mon 19 Sep 2022 01:27:13 PM PDT By: Paul Eggert 
GNU grep 3.8 warns about some regular expressions that POSIX says have
undefined effect, e.g., '\-'. Unfortunately Libtool uses regular expressions
of this form.

I'm attaching two proposed patches against libtool's current HEAD (commit
6132006b5fb6b95f31c30a972fbb829f93e1878b dated 2022-05-16). The first patch
should suffice to pacify GNU grep 3.8. The second patch fixes some other
regular expressions that GNU grep 3.8 does not warn about (I found them with
an even-pickier 'grep').

I did not look systematically for all portability bugs of this form.






___
File Attachments:


---
Date: Mon 19 Sep 2022 01:27:13 PM PDT  Name:
0001-libtool-port-to-GNU-grep-3.8.patch  Size: 5KiB   By: eggert
Patches to port libtool to GNU and POSIX grep

---
Date: Mon 19 Sep 2022 01:27:13 PM PDT  Name:
0002-libtool-port-better-to-POSIX-grep.patch  Size: 2KiB   By: eggert
Patches to port libtool to GNU and POSIX grep


___

Reply to this item at:

  

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

[PATCH] libtool: remove stray \ before -

[jspricke]

From: Jochen Sprickerhof 

grep 3.8 emits a warning for this.
---
 m4/libtool.m4 | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/m4/libtool.m4 b/m4/libtool.m4
index 79a2451e..23d093ba 100644
--- a/m4/libtool.m4
+++ b/m4/libtool.m4
@@ -6442,7 +6442,7 @@ if test yes != "$_lt_caught_CXX_error"; then
   # Commands to make compiler produce verbose output that lists
   # what "hidden" libraries, object files and flags are used when
   # linking a shared library.
-  output_verbose_link_cmd='$CC -shared $CFLAGS -v conftest.$objext 2>&1 | 
$GREP -v "^Configured with:" | $GREP "\-L"'
+  output_verbose_link_cmd='$CC -shared $CFLAGS -v conftest.$objext 2>&1 | 
$GREP -v "^Configured with:" | $GREP "-L"'
 
 else
   GXX=no
-- 
2.37.2

[patch #10275] link-order.at: fix tests with GNU grep 3.8

[Andreas Stieger]

URL:
  

 Summary: link-order.at: fix tests with GNU grep 3.8
 Project: GNU Libtool
   Submitter: andreasstieger
   Submitted: Sun 04 Sep 2022 08:37:51 PM UTC
Category: None
Priority: 5 - Normal
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any


___

Follow-up Comments:


---
Date: Sun 04 Sep 2022 08:37:51 PM UTC By: Andreas Stieger 
Tests fail with GNU grep 3.8 due to a new warning introduced to stderr:
Regular expressions with stray backslashes now cause warnings


[ 1902s] ./link-order.at:106: if $EGREP relinking stderr; then
[ 1902s]  $EGREP " -L.*\/new\/lib -lb -L.*\/old\/lib -lcee" stdout
[ 1902s]else :; fi
[ 1902s] --- /dev/null  2022-09-04 15:44:09.60800 +
[ 1902s] +++
/home/abuild/rpmbuild/BUILD/libtool-2.4.7/tests/testsuite.dir/at-groups/66/stderr
   2022-09-04
15:50:25.54800 +
[ 1902s] @@ -0,0 +1,4 @@
[ 1902s] +/usr/bin/grep: warning: stray \ before /
[ 1902s] +/usr/bin/grep: warning: stray \ before /
[ 1902s] +/usr/bin/grep: warning: stray \ before /
[ 1902s] +/usr/bin/grep: warning: stray \ before /
[ 1902s] stdout:
[ 1902s] libtool: warning: relinking 'src/liba.la'
[ 1902s] libtool: relink: gcc -shared  -fPIC -DPIC  src/.libs/a.o   -Wl,-rpath
-Wl,/home/abuild/rpmbuild/BUILD/libtool-2.4.7/tests/testsuite.dir/066/new/lib
-Wl,-rpath
-Wl,/home/abuild/rpmbuild/BUILD/libtool-2.4.7/tests/testsuite.dir/066/old/lib
-L/home/abuild/rpmbuild/BUILD/libtool-2.4.7/tests/testsuite.dir/066/new/lib
-lb
-L/home/abuild/rpmbuild/BUILD/libtool-2.4.7/tests/testsuite.dir/066/old/lib
-lcee  -O2 -fstack-protector-strong -g   -Wl,-soname -Wl,liba.so.0 -o
src/.libs/liba.so.0.0.0
[ 1902s] wrong link order
[ 1902s] 66. link-order.at:27: 66. Link order test (link-order.at:27): FAILED
(link-order.at:106)

Patch tested with 3.7 and 3.8:

>From 1e13a1944f725ccc24bce1a2fa6f9009ba8a2270 Mon Sep 17 00:00:00 2001
From: Andreas Stieger 
Date: Sun, 4 Sep 2022 22:24:41 +0200
Subject: [PATCH] tests/link-order.at: avoid warning and test failure with GNU
 grep 3.8

---
 tests/link-order.at | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/tests/link-order.at b/tests/link-order.at
index 3f01a00d..a145347f 100644
--- a/tests/link-order.at
+++ b/tests/link-order.at
@@ -99,12 +99,12 @@ aix* | interix*) ;;  # These systems have different path
syntax
   case $hardcode_direct$hardcode_direct_absolute in
   yesno)
 AT_CHECK([if $EGREP relinking stderr; then
- $EGREP " .*\/new\/lib/libb$shared_ext
.*\/old\/lib/libcee$shared_ext" stdout
+ $EGREP " .*/new/lib/libb$shared_ext .*/old/lib/libcee$shared_ext"
stdout
else :; fi], [0], [ignore], [], [echo "wrong link order"])
 ;;
   *)
 AT_CHECK([if $EGREP relinking stderr; then
- $EGREP " -L.*\/new\/lib -lb -L.*\/old\/lib -lcee" stdout
+ $EGREP " -L.*/new/lib -lb -L.*/old/lib -lcee" stdout
else :; fi], [0], [ignore], [], [echo "wrong link order"])
 ;;
   esac
-- 
2.37.2











___

Reply to this item at:

  

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

Re: [PATCH] Further update/simplify OpenBSD support

[Alex Ameen]

I wound up with a handful of regressions running on Darwin with BSD 
utils. I'm sending the diff here and attaching the full logs. The 
"expected failure" messages are something I'm investigating - I'm going 
to assume until I know for sure the "expected failure" vs "pass" is 
noteworthy.



3c3

< make[1]: Entering directory '/private/tmp/libtool-base'

---


make[1]: Entering directory '/private/tmp/libtool'


5c5

< make[2]: Entering directory '/private/tmp/libtool-base'

---


make[2]: Entering directory '/private/tmp/libtool'


7,10c7,10

< make[3]: Entering directory '/private/tmp/libtool-base'

< ## --- ##

< ## GNU Libtool 2.4.7.3-61320-dirty test suite. ##

< ## --- ##

---


make[3]: Entering directory '/private/tmp/libtool'



## -- ##



## GNU Libtool 2.4.7.4-b9a3-dirty test suite. ##



## -- ##


29,30c29,30

<  13: upgrading verbatim style aclocal.m4 ok

<  14: verbatim aclocal.m4 w/o AC_CONFIG_MACRO_DIRS    ok

---


  13: upgrading verbatim style aclocal.m4 expected failure 
(libtoolize.at:698)



  14: verbatim aclocal.m4 w/o AC_CONFIG_MACRO_DIRS    expected failure 
(libtoolize.at:789)


45c45

<  26: test LT_SUPPORTED_TAG interface ok

---


  26: test LT_SUPPORTED_TAG interface skipped (libtool.at:219)


49,61c49,61

<  27: link against a preloaded static library ok

<  28: build and dynamically load a module ok

<  29: preload static and dynamic module   ok

<  30: deplibs_check_method    ok

<  31: disable fast install    ok

<  32: force PIC objects   ok

<  33: force non-PIC objects   ok

<  34: hardcoding library path ok

<  35: binary relinking at install time    ok

<  36: uninstalled libraries have priority ok

<  37: linking with long file names    ok

<  38: override pic_flag at configure time ok

<  39: test --with-pic skipped (with-pic.at:40)

---


  27: link against a preloaded static library expected failure 
(demo.at:388)



  28: build and dynamically load a module expected failure 
(demo.at:405)



  29: preload static and dynamic module   expected failure 
(demo.at:422)



  30: deplibs_check_method    expected failure 
(demo.at:468)



  31: disable fast install    expected failure 
(demo.at:483)



  32: force PIC objects   expected failure 
(demo.at:501)



  33: force non-PIC objects   expected failure 
(demo.at:539)



  34: hardcoding library path expected failure 
(demo.at:612)



  35: binary relinking at install time    expected failure 
(demo.at:724)



  36: uninstalled libraries have priority expected failure 
(demo.at:795)



  37: linking with long file names    expected failure 
(demo.at:982)



  38: override pic_flag at configure time expected failure 
(pic_flag.at:52)



  39: test --with-pic expected failure 
(with-pic.at:31)


65,68c65,68

<  40: build and link against a static library ok

<  41: build and link against a dynamic library    ok

<  42: build both static and dynamic   ok

<  43: allow_undefined_flag    ok

---


  40: build and link against a static library expected failure 
(cdemo.at:140)



  41: build and link against a dynamic library    expected failure 
(cdemo.at:155)



  42: build both static and dynamic   expected failure 
(cdemo.at:170)



  43: allow_undefined_flag    expected failure 
(cdemo.at:185)


77,81c77,81

<  49: static library interdependencies    ok

<  50: shared library interdependencies    ok

<  51: shared and static interdependencies ok

<  52: disable fast install    ok

<  53: binary relinking at install time    ok

---


  49: static library interdependencies    expected failure 
(depdemo.at:290)



  50: shared library interdependencies    expected failure 
(depdemo.at:307)



  51: shared and static interdependencies expected failure 
(depdemo.at:324)



  52: disable fast install    expected failure 
(depdemo.at:341)



  53: binary relinking at install time    expected failure 
(depdemo.at:360)


136,137c136,137

<  99: AM_PROG_LIBTOOL ok

< 100: AC_WITH_LTDL    ok

---


  99: AM_PROG_LIBTOOL  

Re: [PATCH] Further update/simplify OpenBSD support

[Alex Ameen]

Yeah I didn't get time to work on it until today.

I've applied the patch and ran the test suite through my usual VMs; I'm 
setting up a fresh VM now with OpenBSD's utilities for a "more useful" 
test run but everything looks good so far.


On 8/20/22 14:51, Brad Smith wrote:

On 8/15/2022 10:47 AM, Alex Ameen wrote:
Thanks for your submission. I'll run it through the test suite this 
week and keep you posted.


Any update on this?

Re: [PATCH] Further update/simplify OpenBSD support

[Brad Smith]

On 8/15/2022 10:47 AM, Alex Ameen wrote:
Thanks for your submission. I'll run it through the test suite this 
week and keep you posted.


Any update on this?

Re: [PATCH] Further update/simplify OpenBSD support

[Alex Ameen]

Thanks for your submission. I'll run it through the test suite this week
and keep you posted.

On Sat, Aug 13, 2022, 5:06 PM Brad Smith  wrote:

> Further update/simplify OpenBSD support
>
> * m4/libtool.m4: Remove long obsolete support for a.out and support
> for archs not supporting shared libaries
> ---
>  m4/libtool.m4 | 61 ---
>  1 file changed, 19 insertions(+), 42 deletions(-)
>
> diff --git a/m4/libtool.m4 b/m4/libtool.m4
> index 79a2451e..fa424ec6 100644
> --- a/m4/libtool.m4
> +++ b/m4/libtool.m4
> @@ -1557,7 +1557,7 @@ old_postuninstall_cmds=
>
>  if test -n "$RANLIB"; then
>case $host_os in
> -  bitrig* | openbsd*)
> +  bitrig*)
>  old_postinstall_cmds="$old_postinstall_cmds~\$RANLIB -t \$tool_oldlib"
>  ;;
>*)
> @@ -2948,11 +2948,7 @@ openbsd* | bitrig*)
>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* | bitrig*)
> -  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*)
> @@ -5838,22 +5830,13 @@ _LT_EOF
>;;
>
>  openbsd* | bitrig*)
> -  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(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 -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--export-dynamic'
>;;
>
>  os2*)
> @@ -7132,21 +7115,15 @@ if test yes != "$_lt_caught_CXX_error"; then
> ;;
>
>openbsd* | bitrig*)
> -   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(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'
> +   _LT_TAGVAR(archive_expsym_cmds, $1)='$CC -shared $pic_flag
> $predep_objects $libobjs $deplibs $postdep_objects $compiler_flags
> 

[PATCH] Further update/simplify OpenBSD support

[Brad Smith]

Further update/simplify OpenBSD support

* m4/libtool.m4: Remove long obsolete support for a.out and support
for archs not supporting shared libaries
---
 m4/libtool.m4 | 61 ---
 1 file changed, 19 insertions(+), 42 deletions(-)

diff --git a/m4/libtool.m4 b/m4/libtool.m4
index 79a2451e..fa424ec6 100644
--- a/m4/libtool.m4
+++ b/m4/libtool.m4
@@ -1557,7 +1557,7 @@ old_postuninstall_cmds=
 
 if test -n "$RANLIB"; then
   case $host_os in
-  bitrig* | openbsd*)
+  bitrig*)
 old_postinstall_cmds="$old_postinstall_cmds~\$RANLIB -t \$tool_oldlib"
 ;;
   *)
@@ -2948,11 +2948,7 @@ openbsd* | bitrig*)
   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* | bitrig*)
-  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*)
@@ -5838,22 +5830,13 @@ _LT_EOF
   ;;
 
 openbsd* | bitrig*)
-  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(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 -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--export-dynamic'
   ;;
 
 os2*)
@@ -7132,21 +7115,15 @@ if test yes != "$_lt_caught_CXX_error"; then
;;
 
   openbsd* | bitrig*)
-   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(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'
+   _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--export-dynamic'
+   _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.37.1

Re: [PATCH v2 01/12] ltmain.sh: Fix sysroot paths being encoded into RPATHs

[Richard Purdie]

On Wed, 2022-04-20 at 01:12 +0100, Sam James wrote:
> 
> > On 17 Apr 2022, at 05:55, Alex Ameen  wrote:
> > 
> > This was all green down the line on the test suite on multiple systems (
> > don't get too excited yet ) until I found bugs in the testsuite...
> > 
> > I see how this flew under the radar previously though - currently there are
> > no tests which attempt to check RPATH or RUNPATH entries. I'll definitely be
> > working on that... I'm going to be working out some M4 macros to abstract
> > some functions like `lt_read_pheader([BIN], [ENTRY])',
> > `lt_read_rpath([BIN])', and `lt_read_runpath([BIN])', so that those can be
> > abstracted for handling non-ELF binaries.
> > 
> > I'll make a test case to the effect of `readelf -d -W BIN|grep -v
> > "$sysroot/";', if you have any additional input on new test cases let me
> > know.
> > 
> > You also helped me catch some bad regex in the existing sysroot tests that
> > would cause them to never be run on a system which used '/' as their GCC
> > sysroot ( all of dpkg's  cross compilers seem to... ).
> 
> Nice! I've found a *lot* of things don't respect this case, actually.
> 
> > 
> > So a big thank you for helping to catch all of these places that the tool
> > can be improved.
> > 
> > Naturally now that test cases aren't skipped they're red, so once I sanity
> > check that they fail on the mainline branch I can move forward. I'm ~99%
> > sure this patch will have no effect on those results.
> > 
> > 
> 
> FWIW, given the comments on the main libtool ML, I at least am happy to drop
> this one for now, and revisit later. Richard might feel differently though.

I think this one is ok, it would be "ltmain.in: Don't encode RATHS which match
default linker paths" which is being questioned. We see a awful lot of it and I
don't think we need them but I can see the concern others are raising even if it
what I think should be a more unusual use case. It may be something that could
be configured ultimately?

> I like incremental progress so the more easy stuff in, the better, even if it
> means we have to come back to some of the harder ones.

Definitely agreed. I'd rather we make progress on the things we can agree on
that block on that.

Cheers,

Richard

Re: [PATCH v2 01/12] ltmain.sh: Fix sysroot paths being encoded into RPATHs

[Sam James]

> On 17 Apr 2022, at 05:55, Alex Ameen  wrote:
> 
> This was all green down the line on the test suite on multiple systems ( 
> don't get too excited yet ) until I found bugs in the testsuite...
> 
> I see how this flew under the radar previously though - currently there are 
> no tests which attempt to check RPATH or RUNPATH entries. I'll definitely be 
> working on that... I'm going to be working out some M4 macros to abstract 
> some functions like `lt_read_pheader([BIN], [ENTRY])', 
> `lt_read_rpath([BIN])', and `lt_read_runpath([BIN])', so that those can be 
> abstracted for handling non-ELF binaries.
> 
> I'll make a test case to the effect of `readelf -d -W BIN|grep -v 
> "$sysroot/";', if you have any additional input on new test cases let me know.
> 
> You also helped me catch some bad regex in the existing sysroot tests that 
> would cause them to never be run on a system which used '/' as their GCC 
> sysroot ( all of dpkg's  cross compilers seem to... ).

Nice! I've found a *lot* of things don't respect this case, actually.

> 
> So a big thank you for helping to catch all of these places that the tool can 
> be improved.
> 
> Naturally now that test cases aren't skipped they're red, so once I sanity 
> check that they fail on the mainline branch I can move forward. I'm ~99% sure 
> this patch will have no effect on those results.
> 
> 

FWIW, given the comments on the main libtool ML, I at least am happy to drop 
this one for now, and revisit later. Richard might feel differently though.

I like incremental progress so the more easy stuff in, the better, even if it 
means we have to come back to some of the harder ones.


signature.asc
Description: Message signed with OpenPGP

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

[Bob Friesenhahn]

On Sat, 16 Apr 2022, Sam James wrote:


From: Richard Purdie 

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.


While cross-compiling some software ("Curl") for a target which 
already had an older install present, libtool ended up defeating me. 
I wanted to produce my own libcurl and have the apps specifically 
linking with it, use the libcurl that I had built.  I wanted to leave 
the libcurl that came with the system in place for the many other 
existing apps which needed it.  Unfortunately, the add-on software was 
already configured to install and use libraries in "/usr/lib" and the 
popular/default "/usr/local/lib" was included in the default linker 
path so that would not have worked either.


The libtool I was using (originating from Ubuntu Linux) stripped the 
rpath (which was provided like '-Wl,rpath=/usr/lib') so I was unable 
to embed an rpath in the libcurl I built so that applications linked 
with that libcurl would find it.


The end result was that apps linked with the new libcurl tried to use 
an older libcurl on the system, and failed to run.


I was unable to circumvent this issue caused by libtool.

It is useful if user-provided options have priority over built-in 
optimizations in libtool.


As a user, I strongly suggest that libtool honor user-supplied options 
to the configure script and provided to the libtool command line, even 
while it optimizes other unneeded options away.


Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt

Re: [PATCH v2 01/12] ltmain.sh: Fix sysroot paths being encoded into RPATHs

[Alex Ameen]

This was all green down the line on the test suite on multiple systems ( 
don't get too excited yet ) until I found bugs in the testsuite...


I see how this flew under the radar previously though - currently there 
are no tests which attempt to check RPATH or RUNPATH entries. I'll 
definitely be working on that... I'm going to be working out some M4 
macros to abstract some functions like `lt_read_pheader([BIN], 
[ENTRY])', `lt_read_rpath([BIN])', and `lt_read_runpath([BIN])', so that 
those can be abstracted for handling non-ELF binaries.


I'll make a test case to the effect of `readelf -d -W BIN|grep -v 
"$sysroot/";', if you have any additional input on new test cases let me 
know.


You also helped me catch some bad regex in the existing sysroot tests 
that would cause them to never be run on a system which used '/' as 
their GCC sysroot ( all of dpkg's  cross compilers seem to... ).


So a big thank you for helping to catch all of these places that the 
tool can be improved.


Naturally now that test cases aren't skipped they're red, so once I 
sanity check that they fail on the mainline branch I can move forward. 
I'm ~99% sure this patch will have no effect on those results.



On 4/16/22 12:58, Sam James wrote:

From: Richard Purdie 

There is a bug where RPATHs could end up containing sysroot values when
cross compiling which is obviously incorrect. Strip out sysroot components
from libdir when building RPATH values to avoid this.

Signed-off-by: Richard Purdie 
---
  build-aux/ltmain.in | 14 --
  1 file changed, 12 insertions(+), 2 deletions(-)

diff --git a/build-aux/ltmain.in b/build-aux/ltmain.in
index a5f21a1d..d3a03a53 100644
--- a/build-aux/ltmain.in
+++ b/build-aux/ltmain.in
@@ -7676,9 +7676,11 @@ EOF
  test relink = "$opt_mode" || rpath=$compile_rpath$rpath
  for libdir in $rpath; do
if test -n "$hardcode_libdir_flag_spec"; then
+ func_replace_sysroot "$libdir"
+ libdir=$func_replace_sysroot_result
+ func_stripname '=' '' "$libdir"
+ libdir=$func_stripname_result
  if test -n "$hardcode_libdir_separator"; then
-   func_replace_sysroot "$libdir"
-   libdir=$func_replace_sysroot_result
if test -z "$hardcode_libdirs"; then
  hardcode_libdirs=$libdir
else
@@ -8408,6 +8410,10 @@ EOF
hardcode_libdirs=
for libdir in $compile_rpath $finalize_rpath; do
if test -n "$hardcode_libdir_flag_spec"; then
+ func_replace_sysroot "$libdir"
+ libdir=$func_replace_sysroot_result
+ func_stripname '=' '' "$libdir"
+ libdir=$func_stripname_result
  if test -n "$hardcode_libdir_separator"; then
if test -z "$hardcode_libdirs"; then
  hardcode_libdirs=$libdir
@@ -8459,6 +8465,10 @@ EOF
hardcode_libdirs=
for libdir in $finalize_rpath; do
if test -n "$hardcode_libdir_flag_spec"; then
+ func_replace_sysroot "$libdir"
+ libdir=$func_replace_sysroot_result
+ func_stripname '=' '' "$libdir"
+ libdir=$func_stripname_result
  if test -n "$hardcode_libdir_separator"; then
if test -z "$hardcode_libdirs"; then
  hardcode_libdirs=$libdir

Re: [PATCH v2 00/12] Rebased version of Yocto patches

[Alex Ameen]

My bad I just saw the follow up emails. You're all good.

On Sat, Apr 16, 2022, 1:29 PM Alex Ameen  wrote:

> Can you separate the flag changes from the others?
> Since that's not backwards compatible it needs to be shelved for a future
> major release. There's similar flag changes I've been organizing into a
> pile.
>
> On Sat, Apr 16, 2022, 12:58 PM Sam James  wrote:
>
>> Done after discussion w/ Alex (thanks!). Rebased on master after
>> 2.4.7 release.
>>
>> Khem Raj (3):
>>   libtool.m4: Rename the --with-sysroot option to avoid conflict with
>> gcc/binutils
>>   libtool: Check for static libs for internal compiler libraries
>>   ltmain.in: Add missing sysroot to library path
>>
>> Marek Vasut (1):
>>   libtool: Fix support for NIOS2 processor
>>
>> Mingli Yu (2):
>>   Makefile.am: make sure autoheader run before autoconf
>>   Makefile.am: make sure autoheader run before automake
>>
>> Richard Purdie (6):
>>   ltmain.sh: Fix sysroot paths being encoded into RPATHs
>>   ltmain.in: Handle trailing slashes on install commands correctly
>>   libtool.m4: For reproducibility stop encoding hostname in libtool
>> script
>>   ltmain.in: Don't encode RATHS which match default linker paths
>>   libtool.m4: Handle "/" as a sysroot correctly
>>   ltmain.in: Handle prefix-map compiler options correctly
>>
>>  Makefile.am |  4 +--
>>  build-aux/ltmain.in | 81 +++--
>>  m4/libtool.m4   | 25 --
>>  tests/sysroot.at|  6 ++--
>>  4 files changed, 89 insertions(+), 27 deletions(-)
>>
>> --
>> 2.35.1
>>
>>

Re: [PATCH v2 00/12] Rebased version of Yocto patches

[Alex Ameen]

Can you separate the flag changes from the others?
Since that's not backwards compatible it needs to be shelved for a future
major release. There's similar flag changes I've been organizing into a
pile.

On Sat, Apr 16, 2022, 12:58 PM Sam James  wrote:

> Done after discussion w/ Alex (thanks!). Rebased on master after
> 2.4.7 release.
>
> Khem Raj (3):
>   libtool.m4: Rename the --with-sysroot option to avoid conflict with
> gcc/binutils
>   libtool: Check for static libs for internal compiler libraries
>   ltmain.in: Add missing sysroot to library path
>
> Marek Vasut (1):
>   libtool: Fix support for NIOS2 processor
>
> Mingli Yu (2):
>   Makefile.am: make sure autoheader run before autoconf
>   Makefile.am: make sure autoheader run before automake
>
> Richard Purdie (6):
>   ltmain.sh: Fix sysroot paths being encoded into RPATHs
>   ltmain.in: Handle trailing slashes on install commands correctly
>   libtool.m4: For reproducibility stop encoding hostname in libtool
> script
>   ltmain.in: Don't encode RATHS which match default linker paths
>   libtool.m4: Handle "/" as a sysroot correctly
>   ltmain.in: Handle prefix-map compiler options correctly
>
>  Makefile.am |  4 +--
>  build-aux/ltmain.in | 81 +++--
>  m4/libtool.m4   | 25 --
>  tests/sysroot.at|  6 ++--
>  4 files changed, 89 insertions(+), 27 deletions(-)
>
> --
> 2.35.1
>
>

[PATCH v2 12/12] libtool: Fix support for NIOS2 processor

[Sam James]

From: Marek Vasut 

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.

This patch adds an explicit check for *nios2* before the *os2*
checks to prevent the OS/2 check incorrectly trapping the nios2
as well.

Signed-off-by: Marek Vasut 
Signed-off-by: Richard Purdie 
---
 build-aux/ltmain.in | 20 
 1 file changed, 20 insertions(+)

diff --git a/build-aux/ltmain.in b/build-aux/ltmain.in
index 126b3097..2acf1178 100644
--- a/build-aux/ltmain.in
+++ b/build-aux/ltmain.in
@@ -519,6 +519,12 @@ libtool_validate_options ()
 test : = "$debug_cmd" || func_append preserve_args " --debug"
 
 case $host in
+  # For NIOS2, we want to make sure that it's not caught by the
+  # more general OS/2 check below. Otherwise, NIOS2 is the same
+  # as the default option.
+  *nios2*)
+opt_duplicate_compiler_generated_deps=$opt_preserve_dup_deps
+;;
   # 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* | *pw32* | *cegcc* | *solaris2* | *os2*)
@@ -6275,6 +6281,15 @@ func_mode_link ()
if test -n "$library_names" &&
   { test no = "$use_static_libs" || test -z "$old_library"; }; then
  case $host in
+ *nios2*)
+   # For NIOS2, we want to make sure that it's not caught by the
+   # more general OS/2 check below. Otherwise, NIOS2 is the same
+   # as the default option.
+   if test no = "$installed"; then
+ func_append notinst_deplibs " $lib"
+ need_relink=yes
+   fi
+   ;;
  *cygwin* | *mingw* | *cegcc* | *os2*)
  # No point in relinking DLLs because paths are not encoded
  func_append notinst_deplibs " $lib"
@@ -6345,6 +6360,11 @@ func_mode_link ()
elif test -n "$soname_spec"; then
  # bleh windows
  case $host in
+ *nios2*)
+   # For NIOS2, we want to make sure that it's not caught by the
+   # more general OS/2 check below. Otherwise, NIOS2 is the same
+   # as the default option.
+   ;;
  *cygwin* | mingw* | *cegcc* | *os2*)
func_arith $current - $age
major=$func_arith_result
-- 
2.35.1

[PATCH v2 09/12] libtool.m4: Handle "/" as a sysroot correctly

[Sam James]

From: Richard Purdie 

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.

Signed-off-by: Richard Purdie 
---
 m4/libtool.m4 | 10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/m4/libtool.m4 b/m4/libtool.m4
index 5eac9228..7d6a4564 100644
--- a/m4/libtool.m4
+++ b/m4/libtool.m4
@@ -1253,16 +1253,20 @@ dnl lt_sysroot will always be passed unquoted.  We 
quote it here
 dnl in case the user passed a directory name.
 lt_sysroot=
 case $with_libtool_sysroot in #(
- yes)
+ no)
if test yes = "$GCC"; then
  lt_sysroot=`$CC --print-sysroot 2>/dev/null`
+ # Treat "/" the same a an unset sysroot.
+ if test "$lt_sysroot" = /; then
+   lt_sysroot=
+ fi
fi
;; #(
+ yes|''|/)
+   ;; #(
  /*)
lt_sysroot=`echo "$with_libtool_sysroot" | $SED -e "$sed_quote_subst"`
;; #(
- no|'')
-   ;; #(
  *)
AC_MSG_RESULT([$with_libtool_sysroot])
AC_MSG_ERROR([The sysroot must be an absolute path.])
-- 
2.35.1

[PATCH v2 10/12] ltmain.in: Handle prefix-map compiler options correctly

[Sam James]

From: Richard Purdie 

If lto is enabled, we need the prefix-map variables to be passed to the linker.
Add these to the list of options libtool passes through.

Signed-off-by: Richard Purdie 
---
 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 2fa055ef..126b3097 100644
--- a/build-aux/ltmain.in
+++ b/build-aux/ltmain.in
@@ -5413,11 +5413,12 @@ func_mode_link ()
   # -stdlib=*select c++ std lib with clang
   # -fsanitize=* Clang/GCC memory and address sanitizer
   # -fuse-ld=*   Linker select flags for GCC
+  # -f*-prefix-map*  needed for lto linking
   # -Wa,*Pass flags directly to the assembler
   -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=*|-fuse-ld=*|-Wa,*)
+  -specs=*|-fsanitize=*|-fuse-ld=*|-f*-prefix-map*)
 func_quote_arg pretty "$arg"
arg=$func_quote_arg_result
 func_append compile_command " $arg"
-- 
2.35.1

[PATCH v2 06/12] Makefile.am: make sure autoheader run before autoconf

[Sam James]

From: Mingli Yu 

autoheader will update ../libtool-2.4.6/libltdl/config-h.in which
autoconf needs, so there comes a race sometimes as below:
 | configure.ac:45: error: required file 'config-h.in' not found
 | touch '../libtool-2.4.6/libltdl/config-h.in'

So make sure autoheader run before autoconf to avoid this race.

Signed-off-by: Mingli Yu 
Signed-off-by: Richard Purdie 
---
 Makefile.am | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Makefile.am b/Makefile.am
index 7bd7f728..16f7727e 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -370,7 +370,7 @@ lt_configure_deps = $(lt_aclocal_m4) $(lt_aclocal_m4_deps)
 $(lt_aclocal_m4): $(lt_aclocal_m4_deps)
$(AM_V_GEN)cd '$(srcdir)/$(ltdl_dir)' && $(ACLOCAL) -I ../m4
 
-$(lt_configure): $(lt_configure_deps)
+$(lt_configure): $(lt_configure_deps) $(lt_config_h_in)
$(AM_V_GEN)cd '$(srcdir)/$(ltdl_dir)' && $(AUTOCONF)
 
 $(lt_config_h_in): $(lt_configure_deps)
-- 
2.35.1

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

[Sam James]

From: Richard Purdie 

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.

Signed-off-by: Richard Purdie 
---
 build-aux/ltmain.in | 34 --
 1 file changed, 28 insertions(+), 6 deletions(-)

diff --git a/build-aux/ltmain.in b/build-aux/ltmain.in
index bc0a3950..a4175d99 100644
--- a/build-aux/ltmain.in
+++ b/build-aux/ltmain.in
@@ -7700,8 +7700,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
  fi
elif test -n "$runpath_var"; then
  case "$perm_rpath " in
@@ -8434,8 +8442,16 @@ EOF
  esac
fi
  else
-   eval flag=\"$hardcode_libdir_flag_spec\"
-   func_append 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\"
+   rpath+=" $flag"
+   ;;
+   esac
  fi
elif test -n "$runpath_var"; then
  case "$perm_rpath " in
@@ -8489,8 +8505,14 @@ EOF
  esac
fi
  else
-   eval flag=\"$hardcode_libdir_flag_spec\"
-   func_append rpath " $flag"
+# We only want to hardcode in an rpath if it isn't in the
+# default dlsearch path.
+   case " $sys_lib_dlsearch_path " in
+   *" $libdir "*) ;;
+   *) eval flag=\"$hardcode_libdir_flag_spec\"
+   func_append rpath " $flag"
+   ;;
+   esac
  fi
elif test -n "$runpath_var"; then
  case "$finalize_perm_rpath " in
-- 
2.35.1

[PATCH v2 11/12] Makefile.am: make sure autoheader run before automake

[Sam James]

From: Mingli Yu 

When use automake to generate Makefile.in from Makefile.am, there
comes below race:
 | configure.ac:45: error: required file 'config-h.in' not found

It is because the file config-h.in in updating process by autoheader,
so make automake run after autoheader to avoid the above race.

Signed-off-by: Mingli Yu 
Signed-off-by: Richard Purdie 
---
 Makefile.am | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Makefile.am b/Makefile.am
index 16f7727e..eae4987e 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -333,7 +333,7 @@ EXTRA_DIST += $(lt_aclocal_m4) \
  $(lt_obsolete_m4) \
  $(stamp_mk)
 
-$(lt_Makefile_in): $(lt_Makefile_am) $(lt_aclocal_m4)
+$(lt_Makefile_in): $(lt_Makefile_am) $(lt_aclocal_m4) $(lt_config_h_in)
$(AM_V_GEN)cd '$(srcdir)/$(ltdl_dir)' && $(AUTOMAKE) Makefile
 
 # Don't let unused scripts leak into the libltdl Makefile
-- 
2.35.1

[PATCH v2 07/12] libtool: Check for static libs for internal compiler libraries

[Sam James]

From: Khem Raj 

Libtool checks only for libraries linked as -l* when trying to
find internal compiler libraries. Clang, however uses the absolute
path to link its internal libraries e.g. compiler_rt. This patch
handles clang's statically linked libraries when finding internal
compiler libraries.

Signed-off-by: Khem Raj 
Signed-off-by: Richard Purdie 
---
 m4/libtool.m4 | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/m4/libtool.m4 b/m4/libtool.m4
index d89a892f..5eac9228 100644
--- a/m4/libtool.m4
+++ b/m4/libtool.m4
@@ -7553,7 +7553,7 @@ if AC_TRY_EVAL(ac_compile); then
   for p in `eval "$output_verbose_link_cmd"`; do
 case $prev$p in
 
--L* | -R* | -l*)
+-L* | -R* | -l* | */libclang_rt.*.a)
# Some compilers place space between "-{L,R}" and the path.
# Remove the space.
if test x-L = "$p" ||
-- 
2.35.1

[PATCH v2 08/12] ltmain.in: Add missing sysroot to library path

[Sam James]

From: Khem Raj 

When using a sysroot we should append it to libdir, which is helpful in
cross builds as the system is staged in the sysroot. For normal builds,
i.e. when lt_sysroot is not set, it will still behave the same and add
-L/usr/lib to the relink command.

Signed-off-by: Richard Purdie 
---
 build-aux/ltmain.in | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/build-aux/ltmain.in b/build-aux/ltmain.in
index a4175d99..2fa055ef 100644
--- a/build-aux/ltmain.in
+++ b/build-aux/ltmain.in
@@ -6503,7 +6503,7 @@ func_mode_link ()
  fi
else
  # We cannot seem to hardcode it, guess we'll fake it.
- add_dir=-L$libdir
+ add_dir="-L$lt_sysroot$libdir"
  # Try looking first in the location we're being installed to.
  if test -n "$inst_prefix_dir"; then
case $libdir in
-- 
2.35.1

[PATCH v2 01/12] ltmain.sh: Fix sysroot paths being encoded into RPATHs

[Sam James]

From: Richard Purdie 

There is a bug where RPATHs could end up containing sysroot values when
cross compiling which is obviously incorrect. Strip out sysroot components
from libdir when building RPATH values to avoid this.

Signed-off-by: Richard Purdie 
---
 build-aux/ltmain.in | 14 --
 1 file changed, 12 insertions(+), 2 deletions(-)

diff --git a/build-aux/ltmain.in b/build-aux/ltmain.in
index a5f21a1d..d3a03a53 100644
--- a/build-aux/ltmain.in
+++ b/build-aux/ltmain.in
@@ -7676,9 +7676,11 @@ EOF
  test relink = "$opt_mode" || rpath=$compile_rpath$rpath
  for libdir in $rpath; do
if test -n "$hardcode_libdir_flag_spec"; then
+ func_replace_sysroot "$libdir"
+ libdir=$func_replace_sysroot_result
+ func_stripname '=' '' "$libdir"
+ libdir=$func_stripname_result
  if test -n "$hardcode_libdir_separator"; then
-   func_replace_sysroot "$libdir"
-   libdir=$func_replace_sysroot_result
if test -z "$hardcode_libdirs"; then
  hardcode_libdirs=$libdir
else
@@ -8408,6 +8410,10 @@ EOF
   hardcode_libdirs=
   for libdir in $compile_rpath $finalize_rpath; do
if test -n "$hardcode_libdir_flag_spec"; then
+ func_replace_sysroot "$libdir"
+ libdir=$func_replace_sysroot_result
+ func_stripname '=' '' "$libdir"
+ libdir=$func_stripname_result
  if test -n "$hardcode_libdir_separator"; then
if test -z "$hardcode_libdirs"; then
  hardcode_libdirs=$libdir
@@ -8459,6 +8465,10 @@ EOF
   hardcode_libdirs=
   for libdir in $finalize_rpath; do
if test -n "$hardcode_libdir_flag_spec"; then
+ func_replace_sysroot "$libdir"
+ libdir=$func_replace_sysroot_result
+ func_stripname '=' '' "$libdir"
+ libdir=$func_stripname_result
  if test -n "$hardcode_libdir_separator"; then
if test -z "$hardcode_libdirs"; then
  hardcode_libdirs=$libdir
-- 
2.35.1

[PATCH v2 03/12] libtool.m4: For reproducibility stop encoding hostname in libtool script

[Sam James]

From: Richard Purdie 

For reproducibilty, stop encoding the hostname into the libtool script, this 
isn't
really adding much to debugging and most distros are carrying such a patch now 
as
reproducibility is important.

Signed-off-by: Richard Purdie 
---
 m4/libtool.m4 | 1 -
 1 file changed, 1 deletion(-)

diff --git a/m4/libtool.m4 b/m4/libtool.m4
index 79a2451e..717e7697 100644
--- a/m4/libtool.m4
+++ b/m4/libtool.m4
@@ -730,7 +730,6 @@ _LT_CONFIG_SAVE_COMMANDS([
 cat <<_LT_EOF >> "$cfgfile"
 #! $SHELL
 # Generated automatically by $as_me ($PACKAGE) $VERSION
-# Libtool was configured on host `(hostname || uname -n) 2>/dev/null | sed 1q`:
 # NOTE: Changes made to this file will be lost: look at ltmain.sh.
 
 # Provide generalized library-building support services.
-- 
2.35.1

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

[Sam James]

From: Khem Raj 

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.

Signed-off-by: Richard Purdie 
---
 m4/libtool.m4| 12 ++--
 tests/sysroot.at |  6 +++---
 2 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/m4/libtool.m4 b/m4/libtool.m4
index 717e7697..d89a892f 100644
--- a/m4/libtool.m4
+++ b/m4/libtool.m4
@@ -1243,28 +1243,28 @@ _LT_DECL([], [ECHO], [1], [An echo program that 
protects backslashes])
 AC_DEFUN([_LT_WITH_SYSROOT],
 [m4_require([_LT_DECL_SED])dnl
 AC_MSG_CHECKING([for sysroot])
-AC_ARG_WITH([sysroot],
-[AS_HELP_STRING([--with-sysroot@<:@=DIR@:>@],
+AC_ARG_WITH([libtool-sysroot],
+[AS_HELP_STRING([--with-libtool-sysroot@<:@=DIR@:>@],
   [Search for dependent libraries within DIR (or the compiler's sysroot
if not specified).])],
-[], [with_sysroot=no])
+[], [with_libtool_sysroot=no])
 
 dnl lt_sysroot will always be passed unquoted.  We quote it here
 dnl in case the user passed a directory name.
 lt_sysroot=
-case $with_sysroot in #(
+case $with_libtool_sysroot in #(
  yes)
if test yes = "$GCC"; then
  lt_sysroot=`$CC --print-sysroot 2>/dev/null`
fi
;; #(
  /*)
-   lt_sysroot=`echo "$with_sysroot" | $SED -e "$sed_quote_subst"`
+   lt_sysroot=`echo "$with_libtool_sysroot" | $SED -e "$sed_quote_subst"`
;; #(
  no|'')
;; #(
  *)
-   AC_MSG_RESULT([$with_sysroot])
+   AC_MSG_RESULT([$with_libtool_sysroot])
AC_MSG_ERROR([The sysroot must be an absolute path.])
;;
 esac
diff --git a/tests/sysroot.at b/tests/sysroot.at
index 540edde9..47fce0c2 100644
--- a/tests/sysroot.at
+++ b/tests/sysroot.at
@@ -65,7 +65,7 @@ while read file; do
 done])
 
 LDFLAGS="$LDFLAGS --sysroot=$sysroot -no-undefined"
-configure_options="$configure_options --with-sysroot=$sysroot --prefix=$prefix"
+configure_options="$configure_options --with-libtool-sysroot=$sysroot 
--prefix=$prefix"
 
 #???
 if test PATH = "$shlibpath_var"; then
@@ -115,7 +115,7 @@ AM_INIT_AUTOMAKE([foreign])
 AC_PROG_CC
 AC_CONFIG_SRCDIR([lib2.c])
 LT_INIT
-sysroot=$with_sysroot
+sysroot=$with_libtool_sysroot
 AC_SUBST([sysroot])
 AC_OUTPUT(Makefile)
 ]])
@@ -156,7 +156,7 @@ AM_INIT_AUTOMAKE([foreign])
 AC_PROG_CC
 AC_CONFIG_SRCDIR([prog.c])
 LT_INIT
-sysroot=$with_sysroot
+sysroot=$with_libtool_sysroot
 AC_SUBST([sysroot])
 AC_OUTPUT(Makefile)
 ]])
-- 
2.35.1

[PATCH v2 02/12] ltmain.in: Handle trailing slashes on install commands correctly

[Sam James]

From: Richard Purdie 

A command like:

libtool --mode=install /usr/bin/install -c gck-roots-store-standalone.la 
'/image/usr/lib/gnome-keyring/standalone/'

where the path ends with a trailing slash currently fails. This occurs in
software like gnome-keyring or pulseaudio and is because the comparision
code doesn't see the paths as equal. Strip both paths to ensure this works
reliably.

Signed-off-by: Richard Purdie 
---
 build-aux/ltmain.in | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/build-aux/ltmain.in b/build-aux/ltmain.in
index d3a03a53..bc0a3950 100644
--- a/build-aux/ltmain.in
+++ b/build-aux/ltmain.in
@@ -2381,8 +2381,14 @@ func_mode_install ()
func_append dir "$objdir"
 
if test -n "$relink_command"; then
+ # Strip any trailing slash from the destination.
+ func_stripname '' '/' "$libdir"
+ destlibdir=$func_stripname_result
+ func_stripname '' '/' "$destdir"
+ s_destdir=$func_stripname_result
+
  # Determine the prefix the user has applied to our future dir.
- inst_prefix_dir=`$ECHO "$destdir" | $SED -e "s%$libdir\$%%"`
+ inst_prefix_dir=`$ECHO "X$s_destdir" | $Xsed -e "s%$destlibdir\$%%"`
 
  # Don't allow the user to place us outside of our expected
  # location b/c this prevents finding dependent libraries that
-- 
2.35.1

[PATCH v2 00/12] Rebased version of Yocto patches

[Sam James]

Done after discussion w/ Alex (thanks!). Rebased on master after
2.4.7 release.

Khem Raj (3):
  libtool.m4: Rename the --with-sysroot option to avoid conflict with
gcc/binutils
  libtool: Check for static libs for internal compiler libraries
  ltmain.in: Add missing sysroot to library path

Marek Vasut (1):
  libtool: Fix support for NIOS2 processor

Mingli Yu (2):
  Makefile.am: make sure autoheader run before autoconf
  Makefile.am: make sure autoheader run before automake

Richard Purdie (6):
  ltmain.sh: Fix sysroot paths being encoded into RPATHs
  ltmain.in: Handle trailing slashes on install commands correctly
  libtool.m4: For reproducibility stop encoding hostname in libtool
script
  ltmain.in: Don't encode RATHS which match default linker paths
  libtool.m4: Handle "/" as a sysroot correctly
  ltmain.in: Handle prefix-map compiler options correctly

 Makefile.am |  4 +--
 build-aux/ltmain.in | 81 +++--
 m4/libtool.m4   | 25 --
 tests/sysroot.at|  6 ++--
 4 files changed, 89 insertions(+), 27 deletions(-)

-- 
2.35.1

[PATCH] ltmain.in: Keep compiler generated deps

[Frederic Berat]

Hello,

This patch is a follow-up from the proposal posted on the mailing list,
titled opt_duplicate_compiler_generated_deps [1].

Fred.

[1] https://lists.gnu.org/archive/html/libtool/2022-02/msg1.html

-- 8< --

On Linux, postdeps may be defined as "-lstdc++ -lm -lgcc_s -lc -lgcc_s",
which is later stripped to "-lstdc++ -lm -lc -lgcc_s" leading to
undefined symbol references.

Since this behavior has been observed on quite a lot of systems now, it
appears that de-duplicating compiler generated deps generates more harm
than benefits.

Therefore, instead of adding one more exception, unconditionally keep compiler
generated deps by default for all hosts.
---
 build-aux/ltmain.in | 14 +++---
 1 file changed, 3 insertions(+), 11 deletions(-)

diff --git a/build-aux/ltmain.in b/build-aux/ltmain.in
index a5f21a1d..8d1b1687 100644
--- a/build-aux/ltmain.in
+++ b/build-aux/ltmain.in
@@ -518,17 +518,9 @@ libtool_validate_options ()
 # preserve --debug
 test : = "$debug_cmd" || func_append preserve_args " --debug"
 
-case $host 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* | *pw32* | *cegcc* | *solaris2* | *os2*)
-# don't eliminate duplications in $postdeps and $predeps
-opt_duplicate_compiler_generated_deps=:
-;;
-  *)
-opt_duplicate_compiler_generated_deps=$opt_preserve_dup_deps
-;;
-esac
+# Keeping compiler generated deps duplicates doesn't harm, and is necessary
+# in a majority of systems.
+opt_duplicate_compiler_generated_deps=:
 
 $opt_help || {
   # Sanity checks first:
-- 
2.34.1

libtool should not pass option '-pthread' to Solaris link-editor.

[Stacey Marshall]

Hi,

Following up on libtool bug 34076:
Patch to libtool for solaris 11.4 link-editor which rejects -pthread option
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=34076

with this email to libtool-patches@gnu.org as documented on
https://www.gnu.org/software/libtool/contribute.html

FYI that requirement is not documented at time of posting on
https://www.gnu.org/software/libtool/manual/html_node/Reporting-bugs.html

This same issue is posted to savannah as
https://savannah.gnu.org/support/index.php?110542

The patch provided below is copied from savannah.

libtool should not pass option '-pthread' to Solaris link-editor.
diff --git a/build-aux/ltmain.sh b/build-aux/ltmain.sh
index 0f0a2da3f9..7c8bcfd9d2 100644
--- a/build-aux/ltmain.sh
+++ b/build-aux/ltmain.sh
@@ -7070,7 +7070,21 @@ func_mode_link ()
continue
;;

-  -mt|-mthreads|-kthread|-Kthread|-pthread|-pthreads|--thread-safe \
+  # Solaris ld rejects as of 11.4.  Refer to Oracle bug 22985199.
+  -pthread)
+ case $host in
+  *solaris2*) ;;
+  *)
+ case "$new_inherited_linker_flags " in
+  *" $arg "*) ;;
+  * ) func_append new_inherited_linker_flags " $arg" ;;
+ esac
+ ;;
+ esac
+ continue
+ ;;
+
+  -mt|-mthreads|-kthread|-Kthread|-pthreads|--thread-safe \
   |-threads|-fopenmp|-openmp|-mp|-xopenmp|-omp|-qsmp=*)
func_append compiler_flags " $arg"
func_append compile_command " $arg"


Mr. Stacey Marshall - Principal Software Engineer
Oracle Global Services Limited

[patch #9305] Use $SED more

[Alex Ameen]

Update of patch #9305 (project libtool):

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


___

Reply to this item at:

  

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

[patch #10007] Add support for MidnightBSD

[Alex Ameen]

Update of patch #10007 (project libtool):

  Status:  Ready For Test => Done   
 Open/Closed:Open => Closed 


___

Reply to this item at:

  

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

[patch #10007] Add support for MidnightBSD

[Lucas Holt]

Additional Item Attachment, patch #10007 (project libtool):

File name: testsuite.log  Size:104 KB




___

Reply to this item at:

  

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

[patch #10007] Add support for MidnightBSD

[Lucas Holt]

Follow-up Comment #2, patch #10007 (project libtool):

I've checked out the source from git this time. This new patch is based on
sources from about a week ago.

Please ignore the original patch "midnightbsd.patch"

___

Reply to this item at:

  

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

[patch #10007] Add support for MidnightBSD

[Lucas Holt]

Additional Item Attachment, patch #10007 (project libtool):

File name: midnightbsd2.patch Size:4 KB




___

Reply to this item at:

  

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

[patch #9996] Patch libtool for macOS 11.0 (aka darwin20)

[Alex Ameen]

Update of patch #9996 (project libtool):

  Status:None => Done   
 Assigned to:None => growpotkin 
 Open/Closed:Open => Closed 


___

Reply to this item at:

  

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

[patch #10113] remove hard coded paths to /usr/bin/file

[Alex Ameen]

Update of patch #10113 (project libtool):

  Status:None => Done   
 Assigned to:None => growpotkin 
 Open/Closed:Open => Closed 


___

Reply to this item at:

  

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

Re: [patch #9687] bugfix: make -export-dynamic imply --whole-archive

[Bob Friesenhahn]

On Sun, 21 Nov 2021, Alex Ameen wrote:


Overall I think we're on the same page. I understand that `libtool' is 
ultimately intended to provide cross-platform consistency as a portability 
wrapper around each platform's various compilers, linkers, and loaders. It is 
certainly not my intention to promote a specific tool or platform over 
another.


I am glad that our new maintainer is philosophically on the same page 
and also has excellent skills.


I think that (similar to the influence of GNU/FSF philosophies on 
software development) libtool should help guide application developers 
to to use the most portable approaches while achieving their own 
objectives.  From this standpoint, libtool (and Autotools in general) 
are not just 'tools' (like 'ld') but help guide users (developers) so 
that if they follow guidelines, and what the tools intend to promote, 
their applications are most likely to be portable and still work well.


If the development/porting problem is looked at using Venn diagrams, 
then there would be a proportion of features/solutions in common 
amongst modern targets and those should be the features/solutions 
which are promoted by Autotools.  In some cases the description of 
what is wanted can be at a high enough level that the desired 
low-level behavior can be accomplished entirely differently on 
different targets (because of how they work).


In Autotools, the above has worked well, although there have been many 
complaints over the years about libtool behavior regarding explicit 
dependencies (via ".la" files) whereas leveraging implicit 
dependencies are usually prefered by distribution maintainers.


Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt

Re: [patch #9687] bugfix: make -export-dynamic imply --whole-archive

[Alex Ameen]

Howdy Bob,

I totally agree with you. `libtool' definitely should not be creating 
solutions that only work with a particular linker in mind, and at a high 
level I think it should ultimately work to provide a sense of 
consistency across a variety of linkers.


In this case my concern is about ease of use for developers who might be 
confused about `libtool', `ld', and other link-editors having options 
with identical names which behave in very different ways. Here we have 
the flags `--whole-archive', `--no-whole-archive', and 
`--export-dynamic' which exist across almost all popular link-editors, 
GNU `ld' ( `ld.bfd' and `ld.gold' ), LLVM's `lld', Solaris' `ld', etc 
which have a consistent behavior. With that in mind I think having the 
flag `-export-dynamic' in `libtool' behave differently from "the norm" 
in discreet ways would likely cause confusion. To my knowledge HP UX and 
AIX are the only two systems which lack these flags ( I believe this is 
actually the type of thing that `libtool' should aim to port to those 
platforms ).


And yeah I agree that convenience libraries are wonky, and that linking 
static archives into dynamic libraries and executables is a tricky task. 
The good news on this front is that this is actually the area of linking 
and loading that I have the most experience in, and I'm familiar with 
many ( but not all ) of the pitfalls that pop up on Linux especially, 
but also with AIX and Windows. The reason I recommended the use of a 
convenience library in this case is because `libtool' already knows to 
use `--whole-archive' and `--no-whole-archive' for these libraries, so 
it is a convenient way to accomplish those goals in existing releases.


I took a look at the option parsing for `libtool --mode=link' in depth 
yesterday and I know why it has trouble handling `--whole-archive' and 
`--no-whole-archive' flags, fixing the issue isn't trivial just because 
of how the parser is written but I plan to get these flags to behave "as 
expected" for folks who are used to this feature in common link-editors.


Overall I think we're on the same page. I understand that `libtool' is 
ultimately intended to provide cross-platform consistency as a 
portability wrapper around each platform's various compilers, linkers, 
and loaders. It is certainly not my intention to promote a specific tool 
or platform over another.


-Alex


On 11/21/21 8:32 AM, Bob Friesenhahn wrote:

On Sat, 20 Nov 2021, Alex Ameen wrote:

Thanks for the follow up, this gave me a much clearer idea of the 
underlying issue that you're trying to solve. I really do appreciate 
you taking the time to help improve `libtool'.


You're absolutely right that `libtool' completely bungles the use of 
`--whole-archive' and `--no-whole-archive' which I see as a high 
priority issue. In several build systems I've built in the past I 
have needed to apply manual patches to `libtool' to work around this, 
and I plan on merging changes to fix this soon ( I'm taking my time 
to create test cases ).


I don't pretend to understand the associated issues, but please take 
care that libtool does not promote solutions which only work with GNU 
ld (or linkers designed to perfectly emulate GNU ld) on a limited set 
of targets.


Libtool is a portability solution to encourage development of software 
which is able to compile and run on many targets, even if the authors 
of the software have never experienced those targets.


Linking static libraries into shared libraries is a complex topic and 
is a reason why libtool offers the clumsy/inefficient "convenience 
library" mechanism since it assures that the objects were compiled 
properly to be used in the library they are linked into.


Bob

Re: [patch #9687] bugfix: make -export-dynamic imply --whole-archive

[Bob Friesenhahn]

On Sat, 20 Nov 2021, Alex Ameen wrote:

Thanks for the follow up, this gave me a much clearer idea of the underlying 
issue that you're trying to solve. I really do appreciate you taking the time 
to help improve `libtool'.


You're absolutely right that `libtool' completely bungles the use of 
`--whole-archive' and `--no-whole-archive' which I see as a high priority 
issue. In several build systems I've built in the past I have needed to apply 
manual patches to `libtool' to work around this, and I plan on merging 
changes to fix this soon ( I'm taking my time to create test cases ).


I don't pretend to understand the associated issues, but please take 
care that libtool does not promote solutions which only work with GNU 
ld (or linkers designed to perfectly emulate GNU ld) on a limited set 
of targets.


Libtool is a portability solution to encourage development of software 
which is able to compile and run on many targets, even if the authors 
of the software have never experienced those targets.


Linking static libraries into shared libraries is a complex topic and 
is a reason why libtool offers the clumsy/inefficient "convenience 
library" mechanism since it assures that the objects were compiled 
properly to be used in the library they are linked into.


Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt

Re: [patch #9687] bugfix: make -export-dynamic imply --whole-archive

[Alex Ameen]

Thanks for the follow up, this gave me a much clearer idea of the 
underlying issue that you're trying to solve. I really do appreciate you 
taking the time to help improve `libtool'.


You're absolutely right that `libtool' completely bungles the use of 
`--whole-archive' and `--no-whole-archive' which I see as a high 
priority issue. In several build systems I've built in the past I have 
needed to apply manual patches to `libtool' to work around this, and I 
plan on merging changes to fix this soon ( I'm taking my time to create 
test cases ).


To answer your question about why `--whole-archive' and 
`--no-whole-archive' are useful flags in general : some code-bases 
create libraries with multiple builds of objects for differing 
configurations, which rely the "cherry picking" behavior of the linker 
in combination with dummy symbols to automatically select the 
appropriate form on an object for a given link. This is sometimes 
combined with `--as-needed' and `--no-as-needed' for more fine grained 
control. These use cases are niche, but they can be incredibly useful - 
and if I remember correctly I believe that `libpthread.so', GNU 
`libc.so.6', `libgcc', and several other "core" libraries use this 
behavior in combination with linker-scripts to "choose the right 
objects" ( the nitty gritty of how this is accomplished is an 
interesting rabbit hole to explore ). This reliance on "cherry picking" 
hopefully sheds light on why `--whole-archive' is not the default 
behavior, and why those flags exist. Now, having said that I agree that 
99.9% of the time when I link a `libfoo.a' into a binary ( especially a 
shared object ), I usually want the entire archive to link - so 
`--whole-archive' is a flag I use frequently and it's a major pain that 
`libtool' doesn't handle it correctly at the moment.


We could got back and forth on whether `-export-dynamic' should imply 
`--whole-archive' or not, but where I think we absolutely have agreement 
is that `libtool' needs to start handling `--whole-archive' and 
`--no-whole-archive' properly. Do you think if those flags were fixed, 
would invoking `libtool --mode=link -export-dynamic OBJECTS 
--whole-archive libfoo.a --no-whole-archive libbar.a ...;' be a suitable 
solution to your issue? Having thought about it more I think my gut 
concern was basically backwards-compatibility with existing 
`-export-dynamic' usage.


On your last comment about all of the linking junk being super complex : 
I totally agree with you, and despite exploring niche `ld' junk for 
years now I am always learning. I think at bottom this is why I'm 
cautious about having `-export-dynamic' imply `--whole-archive' 
automatically; I don't personally know every possible use case for these 
flags and I would hate to unknowingly break someone's code-base by 
silently changing the behavior of `-export-dynamic'.



On 11/20/21 10:28 AM, David Lamparter wrote:

Follow-up Comment #2, patch #9687 (project libtool):

Well, it's now 3 years later, and my memory of details on this is pretty much
gone, but let's try.  No warranty on anything here, I'm trying to
reconstruct.

[comment #1 comment #1:]

Could you maybe elaborate on your use case? Perhaps there's something that

I'm missing.

Any executable linked with `-export-dynamic` that links static libraries may
end up missing globally visible symbols if they are not used by the executable
itself.  If the program then tries to load a module that needs these symbols,
it fails.


In my opinion : the existing behavior both by `ld' and `libtool' is

appropriate. Implying `--whole-archive' for dependency libraries in with
`-export-dynamic' will prevent users from intentionally localizing symbols.

`--whole-archive` has no impact on symbol visibility; I don't follow at all
what you're trying to say here.  A binary linked with `-export-dynamic` is
essentially a shared library, and the `ld` docs state:

"This is normally used to turn an archive file into a shared library, forcing
every object to be included in the resulting shared library."

I agree `ld` is doing the appropriate thing here, but `libtool` isn't.  A
binary with `-export-dynamic` needs to export ALL of its global symbols from
ALL of its files for dynamically loaded modules to use.  It is essentially a
shared library at the same time and needs to be treated as such.

NB: `--whole-archive` does NOT make all symbols globally visible! This is
about *objects*, i.e. files.  If you have a file getting linked in that has
some global symbols, but none of them are used in the binary itself - `ld`
will drop the entire file.  That's the wrong thing to do for both creating a
shared library as well as for creating an executable with `-export-dynamic`.


I see these flags as having distinct use cases. I'll note that, the need for

using `--whole-archive' with `ld' isn't necessarily intuitive to users, so I
see the appeal of using it in many situations - but adding additional variance
between `libtool' and 

[patch #9687] bugfix: make -export-dynamic imply --whole-archive

[David Lamparter]

Follow-up Comment #2, patch #9687 (project libtool):

Well, it's now 3 years later, and my memory of details on this is pretty much
gone, but let's try.  No warranty on anything here, I'm trying to
reconstruct.

[comment #1 comment #1:]
> Could you maybe elaborate on your use case? Perhaps there's something that
I'm missing.

Any executable linked with `-export-dynamic` that links static libraries may
end up missing globally visible symbols if they are not used by the executable
itself.  If the program then tries to load a module that needs these symbols,
it fails.

> In my opinion : the existing behavior both by `ld' and `libtool' is
appropriate. Implying `--whole-archive' for dependency libraries in with
`-export-dynamic' will prevent users from intentionally localizing symbols.

`--whole-archive` has no impact on symbol visibility; I don't follow at all
what you're trying to say here.  A binary linked with `-export-dynamic` is
essentially a shared library, and the `ld` docs state:

"This is normally used to turn an archive file into a shared library, forcing
every object to be included in the resulting shared library."

I agree `ld` is doing the appropriate thing here, but `libtool` isn't.  A
binary with `-export-dynamic` needs to export ALL of its global symbols from
ALL of its files for dynamically loaded modules to use.  It is essentially a
shared library at the same time and needs to be treated as such.

NB: `--whole-archive` does NOT make all symbols globally visible! This is
about *objects*, i.e. files.  If you have a file getting linked in that has
some global symbols, but none of them are used in the binary itself - `ld`
will drop the entire file.  That's the wrong thing to do for both creating a
shared library as well as for creating an executable with `-export-dynamic`.

> I see these flags as having distinct use cases. I'll note that, the need for
using `--whole-archive' with `ld' isn't necessarily intuitive to users, so I
see the appeal of using it in many situations - but adding additional variance
between `libtool' and `ld' does not seem justified to me.

If I remember correctly, I couldn't find a way to manually add
`--whole-archive` to the linker invocation that libtool does, because the
option is ordering-sensitive to the file names on the ld command line.  I also
do not understand what you mean with "variance" between `libtool` and `ld` -
there is no equivalency here.  `libtool` is a user/wrapper of `ld` that has
the express purpose of figuring out the "right" flags for `ld`, and it's
failing at its job.

Also: what is that distinct use case for `--whole-archive`?  I think it's
exactly this situation right here... the ld docs even hint at it.

> If the intention is to export symbols which are defined in statically linked
`libtool' libraries a "convenience library" ( `noinst_' ) might be what you're
actually looking for?

Barring my memory failing me, I think we tried that and it simply has the same
problem.


The patch posted here has been shipped in FRRouting for 3 years now, it has
not caused any breakage in any OS/distribution (prominently: Debian, Ubuntu,
RHEL, *BSD, …) - as such I would urge you to just merge it and move on.  I
would happily help you in understanding the issue here, but I can't do that
with having more or less lost my own understanding of it.  Sorry about that,
but there's a boatload of other stuff I need to understand, and my brain is
not infinite :(.

___

Reply to this item at:

  

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

[patch #9687] bugfix: make -export-dynamic imply --whole-archive

[Alex Ameen]

Update of patch #9687 (project libtool):

  Status:None => Need Info  
 Assigned to:None => growpotkin 

___

Follow-up Comment #1:

Could you maybe elaborate on your use case? Perhaps there's something that I'm
missing.

In my opinion : the existing behavior both by `ld' and `libtool' is
appropriate. Implying `--whole-archive' for dependency libraries in with
`-export-dynamic' will prevent users from intentionally localizing symbols.

I see these flags as having distinct use cases. I'll note that, the need for
using `--whole-archive' with `ld' isn't necessarily intuitive to users, so I
see the appeal of using it in many situations - but adding additional variance
between `libtool' and `ld' does not seem justified to me.

If the intention is to export symbols which are defined in statically linked
`libtool' libraries a "convenience library" ( `noinst_' ) might be what you're
actually looking for?

___

Reply to this item at:

  

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

[patch #8977] libtool: add -Xassembler compilation flag support

[Alex Ameen]

Update of patch #8977 (project libtool):

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


___

Reply to this item at:

  

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

[patch #10007] Add support for MidnightBSD

[Alex Ameen]

Follow-up Comment #1, patch #10007 (project libtool):

Looks straightforward to me.

I'm going to test it on my box just to catch typos or anything unexpected; but
since I don't have a MidnightBSD box could you run the test suite and upload
the logs?

___

Reply to this item at:

  

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

[patch #10007] Add support for MidnightBSD

[Alex Ameen]

Update of patch #10007 (project libtool):

  Status:None => Ready For Test 
 Assigned to:None => growpotkin 


___

Reply to this item at:

  

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

[PATCH 01/12] ltmain.in: Handle trailing slashes on install commands correctly

[Richard Purdie]

A command like:

libtool --mode=install /usr/bin/install -c gck-roots-store-standalone.la 
'/image/usr/lib/gnome-keyring/standalone/'

where the path ends with a trailing slash currently fails. This occurs in
software like gnome-keyring or pulseaudio and is because the comparision
code doesn't see the paths as equal. Strip both paths to ensure this works
reliably.

Signed-off-by: Richard Purdie 
---
 build-aux/ltmain.in | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/build-aux/ltmain.in b/build-aux/ltmain.in
index 96b37003..3d5dcd0a 100644
--- a/build-aux/ltmain.in
+++ b/build-aux/ltmain.in
@@ -2378,8 +2378,14 @@ func_mode_install ()
func_append dir "$objdir"
 
if test -n "$relink_command"; then
+ # Strip any trailing slash from the destination.
+ func_stripname '' '/' "$libdir"
+ destlibdir=$func_stripname_result
+ func_stripname '' '/' "$destdir"
+ s_destdir=$func_stripname_result
+
  # Determine the prefix the user has applied to our future dir.
- inst_prefix_dir=`$ECHO "$destdir" | $SED -e "s%$libdir\$%%"`
+ inst_prefix_dir=`$ECHO "X$s_destdir" | $Xsed -e "s%$destlibdir\$%%"`
 
  # Don't allow the user to place us outside of our expected
  # location b/c this prevents finding dependent libraries that
-- 
2.25.1

[PATCH 04/12] ltmain.sh: Fix sysroot paths being encoded into RPATHs

[Richard Purdie]

There is a bug where RPATHs could end up containing sysroot values when
cross compiling which is obviously incorrect. Strip out sysroot components
from libdir when building RPATH values to avoid this.

Signed-off-by: Richard Purdie 
---
 build-aux/ltmain.in | 14 --
 1 file changed, 12 insertions(+), 2 deletions(-)

diff --git a/build-aux/ltmain.in b/build-aux/ltmain.in
index 2c994612..96238350 100644
--- a/build-aux/ltmain.in
+++ b/build-aux/ltmain.in
@@ -7654,9 +7654,11 @@ EOF
  test relink = "$opt_mode" || rpath=$compile_rpath$rpath
  for libdir in $rpath; do
if test -n "$hardcode_libdir_flag_spec"; then
+ func_replace_sysroot "$libdir"
+ libdir=$func_replace_sysroot_result
+ func_stripname '=' '' "$libdir"
+ libdir=$func_stripname_result
  if test -n "$hardcode_libdir_separator"; then
-   func_replace_sysroot "$libdir"
-   libdir=$func_replace_sysroot_result
if test -z "$hardcode_libdirs"; then
  hardcode_libdirs=$libdir
else
@@ -8386,6 +8388,10 @@ EOF
   hardcode_libdirs=
   for libdir in $compile_rpath $finalize_rpath; do
if test -n "$hardcode_libdir_flag_spec"; then
+ func_replace_sysroot "$libdir"
+ libdir=$func_replace_sysroot_result
+ func_stripname '=' '' "$libdir"
+ libdir=$func_stripname_result
  if test -n "$hardcode_libdir_separator"; then
if test -z "$hardcode_libdirs"; then
  hardcode_libdirs=$libdir
@@ -8437,6 +8443,10 @@ EOF
   hardcode_libdirs=
   for libdir in $finalize_rpath; do
if test -n "$hardcode_libdir_flag_spec"; then
+ func_replace_sysroot "$libdir"
+ libdir=$func_replace_sysroot_result
+ func_stripname '=' '' "$libdir"
+ libdir=$func_stripname_result
  if test -n "$hardcode_libdir_separator"; then
if test -z "$hardcode_libdirs"; then
  hardcode_libdirs=$libdir
-- 
2.25.1

[PATCH 09/12] Makefile.am: make sure autoheader run before autoconf

[Richard Purdie]

From: Mingli Yu 

autoheader will update ../libtool-2.4.6/libltdl/config-h.in which
autoconf needs, so there comes a race sometimes as below:
 | configure.ac:45: error: required file 'config-h.in' not found
 | touch '../libtool-2.4.6/libltdl/config-h.in'

So make sure autoheader run before autoconf to avoid this race.

Signed-off-by: Mingli Yu 
Signed-off-by: Richard Purdie 
---
 Makefile.am | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Makefile.am b/Makefile.am
index 6b546092..84795d87 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -370,7 +370,7 @@ lt_configure_deps = $(lt_aclocal_m4) $(lt_aclocal_m4_deps)
 $(lt_aclocal_m4): $(lt_aclocal_m4_deps)
$(AM_V_GEN)cd '$(srcdir)/$(ltdl_dir)' && $(ACLOCAL) -I ../m4
 
-$(lt_configure): $(lt_configure_deps)
+$(lt_configure): $(lt_configure_deps) $(lt_config_h_in)
$(AM_V_GEN)cd '$(srcdir)/$(ltdl_dir)' && $(AUTOCONF)
 
 $(lt_config_h_in): $(lt_configure_deps)
-- 
2.25.1

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

[Richard Purdie]

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.

Signed-off-by: Richard Purdie 
---
 m4/libtool.m4 | 10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/m4/libtool.m4 b/m4/libtool.m4
index de2f1ebf..180dd9d1 100644
--- a/m4/libtool.m4
+++ b/m4/libtool.m4
@@ -1256,16 +1256,20 @@ dnl lt_sysroot will always be passed unquoted.  We 
quote it here
 dnl in case the user passed a directory name.
 lt_sysroot=
 case $with_libtool_sysroot in #(
- yes)
+ no)
if test yes = "$GCC"; then
  lt_sysroot=`$CC --print-sysroot 2>/dev/null`
+ # Treat "/" the same a an unset sysroot.
+ if test "$lt_sysroot" = /; then
+   lt_sysroot=
+ fi
fi
;; #(
+ yes|''|/)
+   ;; #(
  /*)
lt_sysroot=`echo "$with_libtool_sysroot" | sed -e "$sed_quote_subst"`
;; #(
- no|'')
-   ;; #(
  *)
AC_MSG_RESULT([$with_libtool_sysroot])
AC_MSG_ERROR([The sysroot must be an absolute path.])
-- 
2.25.1

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

[Richard Purdie]

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.

Signed-off-by: Richard Purdie 
---
 build-aux/ltmain.in | 34 --
 1 file changed, 28 insertions(+), 6 deletions(-)

diff --git a/build-aux/ltmain.in b/build-aux/ltmain.in
index 96238350..6fb58ed2 100644
--- 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
  fi
elif test -n "$runpath_var"; then
  case "$perm_rpath " in
@@ -8406,8 +8414,16 @@ EOF
  esac
fi
  else
-   eval flag=\"$hardcode_libdir_flag_spec\"
-   func_append 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\"
+   rpath+=" $flag"
+   ;;
+   esac
  fi
elif test -n "$runpath_var"; then
  case "$perm_rpath " in
@@ -8461,8 +8477,14 @@ EOF
  esac
fi
  else
-   eval flag=\"$hardcode_libdir_flag_spec\"
-   func_append rpath " $flag"
+# We only want to hardcode in an rpath if it isn't in the
+# default dlsearch path.
+   case " $sys_lib_dlsearch_path " in
+   *" $libdir "*) ;;
+   *) eval flag=\"$hardcode_libdir_flag_spec\"
+   func_append rpath " $flag"
+   ;;
+   esac
  fi
elif test -n "$runpath_var"; then
  case "$finalize_perm_rpath " in
-- 
2.25.1

[PATCH 03/12] ltmain.in: Add missing sysroot to library path

[Richard Purdie]

From: Khem Raj 

When using a sysroot we should append it to libdir, which is helpful in
cross builds as the system is staged in the sysroot. For normal builds,
i.e. when lt_sysroot is not set, it will still behave the same and add
-L/usr/lib to the relink command.

Signed-off-by: Richard Purdie 
---
 build-aux/ltmain.in | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/build-aux/ltmain.in b/build-aux/ltmain.in
index 3d5dcd0a..2c994612 100644
--- a/build-aux/ltmain.in
+++ b/build-aux/ltmain.in
@@ -6475,7 +6475,7 @@ func_mode_link ()
  fi
else
  # We cannot seem to hardcode it, guess we'll fake it.
- add_dir=-L$libdir
+ add_dir="-L$lt_sysroot$libdir"
  # Try looking first in the location we're being installed to.
  if test -n "$inst_prefix_dir"; then
case $libdir in
-- 
2.25.1

[PATCH 10/12] Makefile.am: make sure autoheader run before automake

[Richard Purdie]

From: Mingli Yu 

When use automake to generate Makefile.in from Makefile.am, there
comes below race:
 | configure.ac:45: error: required file 'config-h.in' not found

It is because the file config-h.in in updating process by autoheader,
so make automake run after autoheader to avoid the above race.

Signed-off-by: Mingli Yu 
Signed-off-by: Richard Purdie 
---
 Makefile.am | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Makefile.am b/Makefile.am
index 84795d87..8c9949ed 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -333,7 +333,7 @@ EXTRA_DIST += $(lt_aclocal_m4) \
  $(lt_obsolete_m4) \
  $(stamp_mk)
 
-$(lt_Makefile_in): $(lt_Makefile_am) $(lt_aclocal_m4)
+$(lt_Makefile_in): $(lt_Makefile_am) $(lt_aclocal_m4) $(lt_config_h_in)
$(AM_V_GEN)cd '$(srcdir)/$(ltdl_dir)' && $(AUTOMAKE) Makefile
 
 # Don't let unused scripts leak into the libltdl Makefile
-- 
2.25.1

[PATCH 11/12] 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.
Add these to the list of options libtool passes through.

Signed-off-by: Richard Purdie 
---
 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 606f17be..7dc2e897 100644
--- a/build-aux/ltmain.in
+++ b/build-aux/ltmain.in
@@ -5392,10 +5392,11 @@ func_mode_link ()
   # -stdlib=*select c++ std lib with clang
   # -fsanitize=* Clang/GCC memory and address sanitizer
   # -fuse-ld=*   Linker select flags for GCC
+  # -f*-prefix-map*  needed for lto linking
   -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=*|-fuse-ld=*)
+  -specs=*|-fsanitize=*|-fuse-ld=*|-f*-prefix-map*)
 func_quote_arg pretty "$arg"
arg=$func_quote_arg_result
 func_append compile_command " $arg"
-- 
2.25.1

[PATCH 07/12] libtool: Fix support for NIOS2 processor

[Richard Purdie]

From: Marek Vasut 

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.

This patch adds an explicit check for *nios2* before the *os2*
checks to prevent the OS/2 check incorrectly trapping the nios2
as well.

Signed-off-by: Marek Vasut 
Signed-off-by: Richard Purdie 
---
 build-aux/ltmain.in | 20 
 1 file changed, 20 insertions(+)

diff --git a/build-aux/ltmain.in b/build-aux/ltmain.in
index 6fb58ed2..606f17be 100644
--- a/build-aux/ltmain.in
+++ b/build-aux/ltmain.in
@@ -519,6 +519,12 @@ libtool_validate_options ()
 test : = "$debug_cmd" || func_append preserve_args " --debug"
 
 case $host in
+  # For NIOS2, we want to make sure that it's not caught by the
+  # more general OS/2 check below. Otherwise, NIOS2 is the same
+  # as the default option.
+  *nios2*)
+opt_duplicate_compiler_generated_deps=$opt_preserve_dup_deps
+;;
   # 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* | *pw32* | *cegcc* | *solaris2* | *os2*)
@@ -6246,6 +6252,15 @@ func_mode_link ()
if test -n "$library_names" &&
   { test no = "$use_static_libs" || test -z "$old_library"; }; then
  case $host in
+ *nios2*)
+   # For NIOS2, we want to make sure that it's not caught by the
+   # more general OS/2 check below. Otherwise, NIOS2 is the same
+   # as the default option.
+   if test no = "$installed"; then
+ func_append notinst_deplibs " $lib"
+ need_relink=yes
+   fi
+   ;;
  *cygwin* | *mingw* | *cegcc* | *os2*)
  # No point in relinking DLLs because paths are not encoded
  func_append notinst_deplibs " $lib"
@@ -6316,6 +6331,11 @@ func_mode_link ()
elif test -n "$soname_spec"; then
  # bleh windows
  case $host in
+ *nios2*)
+   # For NIOS2, we want to make sure that it's not caught by the
+   # more general OS/2 check below. Otherwise, NIOS2 is the same
+   # as the default option.
+   ;;
  *cygwin* | mingw* | *cegcc* | *os2*)
func_arith $current - $age
major=$func_arith_result
-- 
2.25.1

[PATCH 08/12] libtool: Check for static libs for internal compiler libraries

[Richard Purdie]

From: Khem Raj 

Libtool checks only for libraries linked as -l* when trying to
find internal compiler libraries. Clang, however uses the absolute
path to link its internal libraries e.g. compiler_rt. This patch
handles clang's statically linked libraries when finding internal
compiler libraries.

Signed-off-by: Khem Raj 
Signed-off-by: Richard Purdie 
---
 m4/libtool.m4 | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/m4/libtool.m4 b/m4/libtool.m4
index 180dd9d1..022c1292 100644
--- a/m4/libtool.m4
+++ b/m4/libtool.m4
@@ -7560,7 +7560,7 @@ if AC_TRY_EVAL(ac_compile); then
   for p in `eval "$output_verbose_link_cmd"`; do
 case $prev$p in
 
--L* | -R* | -l*)
+-L* | -R* | -l* | */libclang_rt.*.a)
# Some compilers place space between "-{L,R}" and the path.
# Remove the space.
if test x-L = "$p" ||
-- 
2.25.1

[PATCH 12/12] libtool.m4: For reproducibility stop encoding hostname in libtool script

[Richard Purdie]

For reproducibilty, stop encoding the hostname into the libtool script, this 
isn't
really adding much to debugging and most distros are carrying such a patch now 
as
reproducibility is important.

Signed-off-by: Richard Purdie 
---
 m4/libtool.m4 | 1 -
 1 file changed, 1 deletion(-)

diff --git a/m4/libtool.m4 b/m4/libtool.m4
index 022c1292..1a8a2998 100644
--- a/m4/libtool.m4
+++ b/m4/libtool.m4
@@ -728,7 +728,6 @@ _LT_CONFIG_SAVE_COMMANDS([
 cat <<_LT_EOF >> "$cfgfile"
 #! $SHELL
 # Generated automatically by $as_me ($PACKAGE) $VERSION
-# Libtool was configured on host `(hostname || uname -n) 2>/dev/null | sed 1q`:
 # NOTE: Changes made to this file will be lost: look at ltmain.sh.
 
 # Provide generalized library-building support services.
-- 
2.25.1

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

[Richard Purdie]

From: Khem Raj 

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.

Signed-off-by: Richard Purdie 
---
 m4/libtool.m4| 12 ++--
 tests/sysroot.at |  6 +++---
 2 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/m4/libtool.m4 b/m4/libtool.m4
index f2d1f398..de2f1ebf 100644
--- a/m4/libtool.m4
+++ b/m4/libtool.m4
@@ -1246,28 +1246,28 @@ _LT_DECL([], [ECHO], [1], [An echo program that 
protects backslashes])
 # 
 AC_DEFUN([_LT_WITH_SYSROOT],
 [AC_MSG_CHECKING([for sysroot])
-AC_ARG_WITH([sysroot],
-[AS_HELP_STRING([--with-sysroot@<:@=DIR@:>@],
+AC_ARG_WITH([libtool-sysroot],
+[AS_HELP_STRING([--with-libtool-sysroot@<:@=DIR@:>@],
   [Search for dependent libraries within DIR (or the compiler's sysroot
if not specified).])],
-[], [with_sysroot=no])
+[], [with_libtool_sysroot=no])
 
 dnl lt_sysroot will always be passed unquoted.  We quote it here
 dnl in case the user passed a directory name.
 lt_sysroot=
-case $with_sysroot in #(
+case $with_libtool_sysroot in #(
  yes)
if test yes = "$GCC"; then
  lt_sysroot=`$CC --print-sysroot 2>/dev/null`
fi
;; #(
  /*)
-   lt_sysroot=`echo "$with_sysroot" | sed -e "$sed_quote_subst"`
+   lt_sysroot=`echo "$with_libtool_sysroot" | sed -e "$sed_quote_subst"`
;; #(
  no|'')
;; #(
  *)
-   AC_MSG_RESULT([$with_sysroot])
+   AC_MSG_RESULT([$with_libtool_sysroot])
AC_MSG_ERROR([The sysroot must be an absolute path.])
;;
 esac
diff --git a/tests/sysroot.at b/tests/sysroot.at
index 05faa13d..7a1f9567 100644
--- a/tests/sysroot.at
+++ b/tests/sysroot.at
@@ -64,7 +64,7 @@ while read file; do
 done])
 
 LDFLAGS="$LDFLAGS --sysroot=$sysroot -no-undefined"
-configure_options="$configure_options --with-sysroot=$sysroot --prefix=$prefix"
+configure_options="$configure_options --with-libtool-sysroot=$sysroot 
--prefix=$prefix"
 
 #???
 if test PATH = "$shlibpath_var"; then
@@ -114,7 +114,7 @@ AM_INIT_AUTOMAKE([foreign])
 AC_PROG_CC
 AC_CONFIG_SRCDIR([lib2.c])
 LT_INIT
-sysroot=$with_sysroot
+sysroot=$with_libtool_sysroot
 AC_SUBST([sysroot])
 AC_OUTPUT(Makefile)
 ]])
@@ -155,7 +155,7 @@ AM_INIT_AUTOMAKE([foreign])
 AC_PROG_CC
 AC_CONFIG_SRCDIR([prog.c])
 LT_INIT
-sysroot=$with_sysroot
+sysroot=$with_libtool_sysroot
 AC_SUBST([sysroot])
 AC_OUTPUT(Makefile)
 ]])
-- 
2.25.1

[PATCH 00/12] Yocto Project libtool patch queue

[Richard Purdie]

Hi,

I saw comments about a possible pending release and decided to take the 
opportunity to send out the bulk of Yocto Project's patch queue
for libtool. We use it in a cross compiling environment and make
extensive use of the sysroot support in the toolchain so most of our
issues are in that area but there are also some reproducubility and
reduction of unnecessary rpaths tweaks here.

We've been using these patches for many years in some cases so it
would be create to reduce our patchset and share the fixes with others.

Some have been on the libtool mailing lists before but I thought it
simpler to send the set out for review together as a set.

Cheers,

Richard

Khem Raj (3):
  libtool.m4: Rename the --with-sysroot option to avoid conflict with
gcc/binutils
  ltmain.in: Add missing sysroot to library path
  libtool: Check for static libs for internal compiler libraries

Marek Vasut (1):
  libtool: Fix support for NIOS2 processor

Mingli Yu (2):
  Makefile.am: make sure autoheader run before autoconf
  Makefile.am: make sure autoheader run before automake

Richard Purdie (6):
  ltmain.in: Handle trailing slashes on install commands correctly
  ltmain.sh: Fix sysroot paths being encoded into RPATHs
  ltmain.in: Don't encode RATHS which match default linker paths
  libtool.m4: Handle "/" as a sysroot correctly
  ltmain.in: Handle prefix-map compiler options correctly
  libtool.m4: For reproducibility stop encoding hostname in libtool
script

 Makefile.am |  4 +--
 build-aux/ltmain.in | 81 +++--
 m4/libtool.m4   | 25 --
 tests/sysroot.at|  6 ++--
 4 files changed, 89 insertions(+), 27 deletions(-)

-- 
2.25.1

[patch #9305] Use $SED more

[Alex Ameen]

Update of patch #9305 (project libtool):

 Assigned to:None => growpotkin 


___

Reply to this item at:

  

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

[patch #8977] libtool: add -Xassembler compilation flag support

[Alex Ameen]

Update of patch #8977 (project libtool):

 Assigned to:None => growpotkin 


___

Reply to this item at:

  

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

[patch #10126] Fix handling xlc(1)-specific options

[WHR]

URL:
  

 Summary: Fix handling xlc(1)-specific options
 Project: GNU Libtool
Submitted by: whr
Submitted on: Sat 23 Oct 2021 04:41:21 AM UTC
Category: None
Priority: 5 - Normal
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any

___

Details:

The IBM XL C/C++ compiler uses the following syntax to control most of its
behavior, which is called a 'keyword option':
-q [=]
Libtool however handles this only when the option argument is immediately
connected with the option ('-q') itself.

For example if I want to compile for POWER7 64-bit and optmize for code size,
I would passing:
-q 64 -q arch=pwr7 -q optimize -q compact
But this will break Libtool, as it would expecting '-q64 -qarch=pwr7
-qoptimize -qcompact'.

The attached patch adds support of handling option '-q' with its option
argument separated from the option itself.



___

File Attachments:


---
Date: Sat 23 Oct 2021 04:41:21 AM UTC  Name: libtool-xlc-q-option.diff  Size:
640B   By: whr



___

Reply to this item at:

  

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

Re: Organization of ltmain.in into sub-files

[Alex Ameen]

Gotcha I can contact GNU and handle any merges that are needed based on
submitted patches. The bulk of the "effort" was developing a good pattern
and forcing the build and support scripts to treat `ltmain.in' as a built
target, so honestly merging isn't a major hassle.

Thank you for pointing me in the right direction.

On Mon, Oct 18, 2021, 10:38 AM Bob Friesenhahn 
wrote:

> On Mon, 18 Oct 2021, Alex Ameen wrote:
>
> > This sounds great to me, I'd love to lend a hand.
> >
> > I had filled out the form a few weeks ago when I sent in patch for
> > `/usr/bin/file' references, so that might still be sitting in the queue
> for
> > review. If not, let me know and I can file a new request.
>
> The problem is that there are no libtool maintainers to service your
> requests. :-(
>
> This means that you would need to contact the GNU organization to
> express your interest in becomming a libtool maintainer.
>
> There are many pending bug reports with patches to be integrated. Your
> own work may collide with these patches so they can not be easily
> applied.
>
> Bob
> --
> Bob Friesenhahn
> bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
> GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
> Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt
>

Re: Organization of ltmain.in into sub-files

[Bob Friesenhahn]

On Mon, 18 Oct 2021, Alex Ameen wrote:


This sounds great to me, I'd love to lend a hand.

I had filled out the form a few weeks ago when I sent in patch for 
`/usr/bin/file' references, so that might still be sitting in the queue for 
review. If not, let me know and I can file a new request.


The problem is that there are no libtool maintainers to service your 
requests. :-(


This means that you would need to contact the GNU organization to 
express your interest in becomming a libtool maintainer.


There are many pending bug reports with patches to be integrated. Your 
own work may collide with these patches so they can not be easily 
applied.


Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt

Re: Organization of ltmain.in into sub-files

[Alex Ameen]

This sounds great to me, I'd love to lend a hand.

I had filled out the form a few weeks ago when I sent in patch for 
`/usr/bin/file' references, so that might still be sitting in the queue 
for review. If not, let me know and I can file a new request.


Thank you,

-Alex


On 10/18/21 8:15 AM, Bob Friesenhahn wrote:

On Sun, 17 Oct 2021, Alex Ameen wrote:


I thought I had seen in some TODO notes that other maintainers had been
working on reorganizing `ltmain.in', so I wanted to poke my head in 
and see

if there was an existing branch doing this sort of works, or if this was
something that anyone thinks would be useful as a project branch? 
Right now


Your work sounds like an excellent idea.  The major problem for the 
libtool project right now is that (as far as I am aware) there have 
not been active maintainers for years.  It seems like you have the 
skills required for this task.  Becoming an official libtool 
maintainer would help move the project forward and make it easier to 
integrate your own ideas.


Bob

Re: Organization of ltmain.in into sub-files

[Bob Friesenhahn]

On Sun, 17 Oct 2021, Alex Ameen wrote:


I thought I had seen in some TODO notes that other maintainers had been
working on reorganizing `ltmain.in', so I wanted to poke my head in and see
if there was an existing branch doing this sort of works, or if this was
something that anyone thinks would be useful as a project branch? Right now


Your work sounds like an excellent idea.  The major problem for the 
libtool project right now is that (as far as I am aware) there have 
not been active maintainers for years.  It seems like you have the 
skills required for this task.  Becoming an official libtool 
maintainer would help move the project forward and make it easier to 
integrate your own ideas.


Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt

Organization of ltmain.in into sub-files

[Alex Ameen]

Howdy,

I spent a few hours today seeing how reasonable it would be to split the
~9,000 `ltmain.in' script into a collection of smaller `m4sugar' files to
make it a bit easier to read/maintain. This began as a way for me to get my
feet wet with modifying `ltmain.in', but I was pleasantly surprised by how
well it's been working out so far.

Notably I am strictly using `m4sugar', not `m4sh' which is more of a
challenge ( trying to port diversions and wrapper scripts is a large effort
); but I've followed the same general patterns that might make alignment
easier in the future.

I've essentially moved one function at a time into various categories of
sub-files, some associated with each mode, IO for printing messages,
file/path handling. Each function is placed in a "PREPARE" block with an
associated `m4_defun_init' which references it. This means these functions
are still available exactly as they were before as regular shell functions,
but the M4 wrappers now exist as alternates that could be aligned quite
easily with the rest of `autom4te' usage.

I've found that not only are things a bit easier to navigate now, but that
the use of `m4_require' blocks has made ordering the script's contents much
easier.

I integrated the generation of `ltmain.in' from `ltmain.in.m4' into the
appropriate bootstrap and build files such that `ltmain.in' is packaged as
it was before - so `ltmain.in.sh' is effectively only relevant for
maintainers or people making extensions.

Test suite matches an unmodified branch as well which is good.


I thought I had seen in some TODO notes that other maintainers had been
working on reorganizing `ltmain.in', so I wanted to poke my head in and see
if there was an existing branch doing this sort of works, or if this was
something that anyone thinks would be useful as a project branch? Right now
I just have it living in a fork

of the GitHub mirror. I imagined uploading patches would be pretty
difficult to read since there's so many files created and snippets moved,
but if anyone prefers to check things out that way let me know.

Thanks for reading!

-- 
Alex Ameen

[patch #10113] remove hard coded paths to /usr/bin/file

[Alex Ameen]

URL:
  

 Summary: remove hard coded paths to /usr/bin/file
 Project: GNU Libtool
Submitted by: growpotkin
Submitted on: Sat 02 Oct 2021 12:19:57 AM UTC
Category: None
Priority: 5 - Normal
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any

___

Details:

Hard coded paths which invoke file(cmd) fail on certain Linux distributions,
in my case NixOS. I saw a commit from 1999 by Thomas Tanner  (
https://git.savannah.gnu.org/cgit/libtool.git/tree/libtool.m4?id=ef128a41ba1a3126f01b18054e7d4c5ca528f61c
) which used to call `AC_CHECK_TOOL(FILE` to handle this, I lost track of
exactly when it was removed, but I assume it was dropped because other macros
use `FILE` when performing compilation/linking checks.

This essentially restores Thomas Tanner  commit, but instead
of using the name `FILE` I instead use `FILECMD`. I tried to follow patterns
in use by other tools, but feel free to recommend any changes.

This passes everything in `make check` on my NixOS machine, except for
`destdir.at`, `old-ltdl-iface.at`, `cmdline_wrap.at` which appear to be
unrelated to my patch ( they fail on an unmodified build in my environment as
well ). See attached testsuite.log.

This patch is against the "public" master branch, I will rewrite it against
the private one for a merge.



___

File Attachments:


---
Date: Sat 02 Oct 2021 12:19:57 AM UTC  Name: filecmd.patch  Size: 3KiB   By:
growpotkin


---
Date: Sat 02 Oct 2021 12:19:57 AM UTC  Name: testsuite.log  Size: 163KiB   By:
growpotkin



___

Reply to this item at:

  

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

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

[Tim Rice]

On Mon, 19 Jul 2021, Nick Alcock wrote:

> This reports common symbols like GNU nm, via a type code of 'C'.
> 
> * m4/libtool.m4 (lt_cv_sys_global_symbol_pipe): Augment symcode for
> Solaris 11.
> 
> Signed-off-by: Nick Alcock 
> ---
>  m4/libtool.m4 | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/m4/libtool.m4 b/m4/libtool.m4
> index a3bc337b..2851b204 100644
> --- a/m4/libtool.m4
> +++ b/m4/libtool.m4
> @@ -3931,7 +3931,7 @@ osf*)
>symcode='[[BCDEGQRST]]'
>;;
>  solaris*)
> -  symcode='[[BDRT]]'
> +  symcode='[[BCDRT]]'

Will this change work on previous releases of Solaris?

>;;
>  sco3.2v5*)
>symcode='[[DT]]'
> 

-- 
Tim Rice
t...@multitalents.net

[PATCH 3/3] libtool.m4: fix nm BSD flag detection

[Nick Alcock]

Libtool needs to get BSD-format (or MS-format) output out of the system
nm, so that it can scan generated object files for symbol names for
-export-symbols-regex support.  Some nms need specific flags to turn on
BSD-formatted output, so libtool checks for this in its AC_PATH_NM.
Unfortunately the code to do this has a pair of interlocking flaws:

 - it runs the test by doing an nm of /dev/null.  Some platforms
   reasonably refuse to do an nm on a device file, but before now this
   has only been worked around by assuming that the error message has a
   specific textual form emitted by Tru64 nm, and that getting this
   error means this is Tru64 nm and that nm -B would work to produce
   BSD-format output, even though the test never actually got anything
   but an error message out of nm -B.  This is fixable by nm'ing *nm
   itself* (since we necessarily have a path to it).

 - the test is entirely skipped if NM is set in the environment, on the
   grounds that the user has overridden the test: but the user cannot
   reasonably be expected to know that libtool wants not only nm but
   also flags forcing BSD-format output.  Worse yet, one such "user" is
   the top-level Cygnus configure script, which neither tests for
   nor specifies any BSD-format flags.  So platforms needing BSD-format
   flags always fail to set them when run in a Cygnus tree, breaking
   -export-symbols-regex on such platforms.  Libtool also needs to
   augment $LD on some platforms, but this is done unconditionally,
   augmenting whatever the user specified: the nm check should do the
   same.

   One wrinkle: if the user has overridden $NM, a path might have been
   provided: so we use the user-specified path if there was one, and
   otherwise do the path search as usual.  (If the nm specified doesn't
   work, this might lead to a few extra pointless path searches -- but
   the test is going to fail anyway, so that's not a problem.)

(Tested on Solaris 11.4 with NM unset, and set to nm, /usr/bin/nm,
my-nm where my-nm is a symlink to /usr/bin/nm on the PATH, and
/not-on-the-path/my-nm where *that* is a symlink to /usr/bin/nm.
With NM=/usr/bin/nm, Libtool 2.4.6 sees 41 failures, 36 unexpected
and not present if NM is unset; all are fixed by this commit.)

* m4/libtool.m4 (LT_PATH_NM): Try BSDization flags with a user-provided
NM, if there is one.  Run nm on itself, not on /dev/null, to avoid
errors from nms that refuse to work on non-regular files.  Remove
other workarounds for this problem.  Strip out blank lines from the
nm output.

Signed-off-by: Nick Alcock 
---
 m4/libtool.m4 | 85 ++-
 1 file changed, 43 insertions(+), 42 deletions(-)

diff --git a/m4/libtool.m4 b/m4/libtool.m4
index fea1a41a..cb1229d0 100644
--- a/m4/libtool.m4
+++ b/m4/libtool.m4
@@ -3660,48 +3660,49 @@ AC_DEFUN([LT_PATH_NM],
 [AC_REQUIRE([AC_PROG_CC])dnl
 AC_CACHE_CHECK([for BSD- or MS-compatible name lister (nm)], lt_cv_path_NM,
 [if test -n "$NM"; then
-  # Let the user override the test.
-  lt_cv_path_NM=$NM
-else
-  lt_nm_to_check=${ac_tool_prefix}nm
-  if test -n "$ac_tool_prefix" && test "$build" = "$host"; then
-lt_nm_to_check="$lt_nm_to_check nm"
-  fi
-  for lt_tmp_nm in $lt_nm_to_check; do
-lt_save_ifs=$IFS; IFS=$PATH_SEPARATOR
-for ac_dir in $PATH /usr/ccs/bin/elf /usr/ccs/bin /usr/ucb /bin; do
-  IFS=$lt_save_ifs
-  test -z "$ac_dir" && ac_dir=.
-  tmp_nm=$ac_dir/$lt_tmp_nm
-  if test -f "$tmp_nm" || test -f "$tmp_nm$ac_exeext"; then
-   # Check to see if the nm accepts a BSD-compat flag.
-   # Adding the 'sed 1q' prevents false positives on HP-UX, which says:
-   #   nm: unknown option "B" ignored
-   # Tru64's nm complains that /dev/null is an invalid object file
-   case `"$tmp_nm" -B /dev/null 2>&1 | sed '1q'` in
-   */dev/null* | *'Invalid file or object type'*)
- lt_cv_path_NM="$tmp_nm -B"
- break 2
- ;;
-   *)
- case `"$tmp_nm" -p /dev/null 2>&1 | sed '1q'` in
- */dev/null*)
-   lt_cv_path_NM="$tmp_nm -p"
-   break 2
-   ;;
- *)
-   lt_cv_path_NM=${lt_cv_path_NM="$tmp_nm"} # keep the first match, but
-   continue # so that we can try to find one that supports BSD flags
-   ;;
- esac
- ;;
-   esac
-  fi
-done
-IFS=$lt_save_ifs
-  done
-  : ${lt_cv_path_NM=no}
-fi])
+   # Let the user override the nm to test.
+   lt_nm_to_check="$NM"
+ else
+   lt_nm_to_check="${ac_tool_prefix}nm"
+   if test -n "$ac_tool_prefix" && test "$build" = "$host"; then
+ lt_nm_to_check="$lt_nm_to_check nm"
+   fi
+ fi
+ for lt_tmp_nm in $lt_nm_to_check; do
+   lt_save_ifs="$IFS"; IFS=$PATH_SEPARATOR
+   for ac_dir in $PATH /usr/ccs/bin/elf /usr/ccs/bin /usr/ucb /bin; do
+ IFS="$lt_save_ifs"
+ test -z "$ac_dir" && ac_dir=.
+ case "$lt_tmp_nm" in
+ */*|*\\*) tmp_nm="$lt_tmp_nm";;
+ *) tmp_nm="$ac_dir/$lt_tmp_nm";;
+   

[PATCH 2/3] Revert "libtool: fix nm test for MSYS/MinGW"

[Nick Alcock]

This reverts commit 13aa364c0c66f9f6b41f98772d0735039ac974a1.

We fix it in a more general way in the next commit.

* m4/libtool.m4 (LT_PATH_NM): Revert special case for MSYS.

Signed-off-by: Nick Alcock 
---
 m4/libtool.m4 | 9 ++---
 1 file changed, 2 insertions(+), 7 deletions(-)

diff --git a/m4/libtool.m4 b/m4/libtool.m4
index 2851b204..fea1a41a 100644
--- a/m4/libtool.m4
+++ b/m4/libtool.m4
@@ -3678,13 +3678,8 @@ else
# Adding the 'sed 1q' prevents false positives on HP-UX, which says:
#   nm: unknown option "B" ignored
# Tru64's nm complains that /dev/null is an invalid object file
-   # MSYS converts /dev/null to NUL, MinGW nm treats NUL as empty
-   case $build_os in
-   mingw*) lt_bad_file=conftest.nm/nofile ;;
-   *) lt_bad_file=/dev/null ;;
-   esac
-   case `"$tmp_nm" -B $lt_bad_file 2>&1 | sed '1q'` in
-   *$lt_bad_file* | *'Invalid file or object type'*)
+   case `"$tmp_nm" -B /dev/null 2>&1 | sed '1q'` in
+   */dev/null* | *'Invalid file or object type'*)
  lt_cv_path_NM="$tmp_nm -B"
  break 2
  ;;
-- 
2.32.0.255.gd9b1d14a2a

[PATCH 0/3] Fixes for Solaris 11

[Nick Alcock]

These were triggered by Sourceware bug 27967, which breaks building of
recent GNU Binutils on Solaris 11 (and, differently, on Solaris 11.4).

Nick Alcock (2):
  libtool.m4: augment symcode for Solaris 11
  Revert "libtool: fix nm test for MSYS/MinGW"
  libtool.m4: fix nm BSD flag detection

 m4/libtool.m4 | 92 ---
 1 file changed, 44 insertions(+), 48 deletions(-)

-- 
2.32.0.255.gd9b1d14a2a

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

[Nick Alcock]

This reports common symbols like GNU nm, via a type code of 'C'.

* m4/libtool.m4 (lt_cv_sys_global_symbol_pipe): Augment symcode for
Solaris 11.

Signed-off-by: Nick Alcock 
---
 m4/libtool.m4 | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/m4/libtool.m4 b/m4/libtool.m4
index a3bc337b..2851b204 100644
--- a/m4/libtool.m4
+++ b/m4/libtool.m4
@@ -3931,7 +3931,7 @@ osf*)
   symcode='[[BCDEGQRST]]'
   ;;
 solaris*)
-  symcode='[[BDRT]]'
+  symcode='[[BCDRT]]'
   ;;
 sco3.2v5*)
   symcode='[[DT]]'
-- 
2.32.0.255.gd9b1d14a2a

[PATCH] libtool with mingw hangs in func_convert_core_msys_to_w32

[Brian Inglis]

Problem reported by a downstream Cygwin user inadvertently
misconfiguring a package cross-build with mingw toolchain:

libtool with mingw hangs building openocd in
func_convert_core_msys_to_w32:

https://cygwin.com/pipermail/cygwin/2021-June/248791.html

The issue exists in libtool build-aux/ltmain.in line 963 in
func_convert_core_msys_to_w32 Windows subshell command:

( cmd //c echo "$1" )

see:

https://git.savannah.gnu.org/cgit/libtool.git/tree/build-aux/ltmain.in#n963

where the switch char "/" is duplicated, so instead of executing one
command in the Windows subshell context, a subshell is spawned and hangs
until manually exited e.g.:

$ cmd //c echo "$1"
Microsoft Windows [Version 10.0.19042.985]
(c) Microsoft Corporation. All rights reserved.

C:\...>exit
$

The patch merely removes the extraneous duplicated switch char "/".

As the patch is trivial, no copyright assignemnt should be required.

---
 build-aux/ltmain.in | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/build-aux/ltmain.in b/build-aux/ltmain.in
index 96b3700347d5..4b8088903740 100644
--- a/build-aux/ltmain.in
+++ b/build-aux/ltmain.in
@@ -960,7 +960,7 @@ func_convert_core_msys_to_w32 ()
   $debug_cmd
 
   # awkward: cmd appends spaces to result
-  func_convert_core_msys_to_w32_result=`( cmd //c echo "$1" ) 2>/dev/null |
+  func_convert_core_msys_to_w32_result=`( cmd /c echo "$1" ) 2>/dev/null |
 $SED -e 's/[ ]*$//' -e "$sed_naive_backslashify"`
 }
 #end: func_convert_core_msys_to_w32

Re: [PATCH 1/2] ltmain.in: ensure old libraries are not archived

[Alexandre Janniaux]

Hi,

For information, I've made a test project at this location:
https://github.com/alexandre-janniaux/libtool-relocatable-tests/blob/main/Makefile

It highlights the issue with the current libtool code and
show the linked result when using LIBTOOL=/path/to/patched/libtool.

I hope it helps review, but I can also improve it to test other
cases if needed.

Regards,
--
Alexandre Janniaux
Videolabs

On Tue, Apr 06, 2021 at 10:22:14AM +0200, Alexandre Janniaux wrote:
> Previously, adding a static archive library, aka. old library, as a
> dependency of a new libtool library compiled as a static archive (be it
> a convenience library or an installed static library) resulted in the
> dependency archive being added into the target archive as-is.
>
> However, linkers are usually not able to use nested archive as-is. It
> results in errors like these on Linux and Darwin at least:
>
> /usr/bin/ld: ./.libs/libfoo.a: member ./.libs/libfoo.a(libbar.a) in
> archive is not an object
>
> or
>
> /usr/bin/nm: libbar.a: file format not recognized
>
> With libfoo.a being the static libtool target and libbar.a being the
> nested/linked static library.
>
> Libtool has a quite close behaviour with convenience libraries, where
> the content (objects) of the convenience library are extracted and added
> back into the new target, but that´s mostly a libtool creation.
>
> The static dependencies should not be "linked" into other static
> libraries as there should not be linking involved, and we don´t want to
> potentially duplicate symbols like done for the convenience libraries.
>
> Instead, keep them in the dependency_libs of the new libtool archive
> created and forward them until we link a shared library or an
> executable.
> ---
>  build-aux/ltmain.in | 11 ---
>  1 file changed, 8 insertions(+), 3 deletions(-)
>
> diff --git a/build-aux/ltmain.in b/build-aux/ltmain.in
> index 96b37003..d172deae 100644
> --- a/build-aux/ltmain.in
> +++ b/build-aux/ltmain.in
> @@ -5508,7 +5508,6 @@ func_mode_link ()
>*.$libext)
>   # An archive.
>   func_append deplibs " $arg"
> - func_append old_deplibs " $arg"
>   continue
>   ;;
>
> @@ -5867,6 +5866,8 @@ func_mode_link ()
> if test conv = "$pass"; then
>   deplibs="$deplib $deplibs"
>   continue
> +   else
> + func_append old_deplibs " $deplib"
> fi
> case $linkmode in
> lib)
> @@ -6817,7 +6818,6 @@ func_mode_link ()
># Now set the variables for building old libraries.
>build_libtool_libs=no
>oldlibs=$output
> -  func_append objs "$old_deplibs"
>;;
>
>  lib)
> @@ -8697,7 +8697,11 @@ EOF
> build_libtool_libs=no
>;;
>   *)
> -   oldobjs="$old_deplibs $non_pic_objects"
> +   oldobjs="$non_pic_objects"
> +   # This is not correct to add old_deplibs creating an archive
> +   # so append them only when creating an executable or a shared
> +   # library.
> +   test yes != "$build_old_libs" && oldobjs="$oldobjs $old_deplibs"
> $preload && test -f "$symfileobj" \
>   && func_append oldobjs " $symfileobj"
> addlibs=$old_convenience
> @@ -8958,6 +8962,7 @@ EOF
>   done
>   dlprefiles=$newdlprefiles
> fi
> +   func_append dependency_libs " $old_deplibs"
> $RM $output
> # place dlname in correct position for cygwin
> # In fact, it would be nice if we could use this code for all target
> --
> 2.31.1
>

[PATCH] Makefile.am: make sure autoheader run before automake

[mingli.yu]

From: Mingli Yu 

When use automake to generate Makefile.in from Makefile.am, there
comes below race:
 | configure.ac:45: error: required file 'config-h.in' not found

It is because the file config-h.in in updating process by autoheader,
so make automake run after autoheader to avoid the above race.

Signed-off-by: Mingli Yu 
---
 Makefile.am | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Makefile.am b/Makefile.am
index 84795d87..8c9949ed 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -333,7 +333,7 @@ EXTRA_DIST += $(lt_aclocal_m4) \
  $(lt_obsolete_m4) \
  $(stamp_mk)
 
-$(lt_Makefile_in): $(lt_Makefile_am) $(lt_aclocal_m4)
+$(lt_Makefile_in): $(lt_Makefile_am) $(lt_aclocal_m4) $(lt_config_h_in)
$(AM_V_GEN)cd '$(srcdir)/$(ltdl_dir)' && $(AUTOMAKE) Makefile
 
 # Don't let unused scripts leak into the libltdl Makefile
-- 
2.17.1

[PATCH 1/2] ltmain.in: ensure old libraries are not archived

[Alexandre Janniaux]

Previously, adding a static archive library, aka. old library, as a
dependency of a new libtool library compiled as a static archive (be it
a convenience library or an installed static library) resulted in the
dependency archive being added into the target archive as-is.

However, linkers are usually not able to use nested archive as-is. It
results in errors like these on Linux and Darwin at least:

/usr/bin/ld: ./.libs/libfoo.a: member ./.libs/libfoo.a(libbar.a) in
archive is not an object

or

/usr/bin/nm: libbar.a: file format not recognized

With libfoo.a being the static libtool target and libbar.a being the
nested/linked static library.

Libtool has a quite close behaviour with convenience libraries, where
the content (objects) of the convenience library are extracted and added
back into the new target, but that´s mostly a libtool creation.

The static dependencies should not be "linked" into other static
libraries as there should not be linking involved, and we don´t want to
potentially duplicate symbols like done for the convenience libraries.

Instead, keep them in the dependency_libs of the new libtool archive
created and forward them until we link a shared library or an
executable.
---
 build-aux/ltmain.in | 11 ---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/build-aux/ltmain.in b/build-aux/ltmain.in
index 96b37003..d172deae 100644
--- a/build-aux/ltmain.in
+++ b/build-aux/ltmain.in
@@ -5508,7 +5508,6 @@ func_mode_link ()
   *.$libext)
# An archive.
func_append deplibs " $arg"
-   func_append old_deplibs " $arg"
continue
;;
 
@@ -5867,6 +5866,8 @@ func_mode_link ()
  if test conv = "$pass"; then
deplibs="$deplib $deplibs"
continue
+ else
+   func_append old_deplibs " $deplib"
  fi
  case $linkmode in
  lib)
@@ -6817,7 +6818,6 @@ func_mode_link ()
   # Now set the variables for building old libraries.
   build_libtool_libs=no
   oldlibs=$output
-  func_append objs "$old_deplibs"
   ;;
 
 lib)
@@ -8697,7 +8697,11 @@ EOF
  build_libtool_libs=no
   ;;
*)
- oldobjs="$old_deplibs $non_pic_objects"
+ oldobjs="$non_pic_objects"
+ # This is not correct to add old_deplibs creating an archive
+ # so append them only when creating an executable or a shared
+ # library.
+ test yes != "$build_old_libs" && oldobjs="$oldobjs $old_deplibs"
  $preload && test -f "$symfileobj" \
&& func_append oldobjs " $symfileobj"
  addlibs=$old_convenience
@@ -8958,6 +8962,7 @@ EOF
done
dlprefiles=$newdlprefiles
  fi
+ func_append dependency_libs " $old_deplibs"
  $RM $output
  # place dlname in correct position for cygwin
  # In fact, it would be nice if we could use this code for all target
-- 
2.31.1

[PATCH 2/2] ltmain.in: defer warn dependency to static library

[Alexandre Janniaux]

When linking old library to any libtool target that is not an
executable, libtool warns that it might not be portable, in particular
because shared libraries need PIC from the static library to be working.

However, when adding an old library as dependency to a static libtool
library, there is no linkage, and thus no portability issue, so there's
no reason to warn. If the static libtool library is then linked to a
shared library, the dependency will be forwarded and the warning will
happen at this time.
---
 build-aux/ltmain.in | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/build-aux/ltmain.in b/build-aux/ltmain.in
index d172deae..ecd9a5a0 100644
--- a/build-aux/ltmain.in
+++ b/build-aux/ltmain.in
@@ -5891,9 +5891,11 @@ func_mode_link ()
;;
  esac
  if $valid_a_lib; then
-   echo
-   $ECHO "*** Warning: Linking the shared library $output against 
the"
-   $ECHO "*** static library $deplib is not portable!"
+   if test yes != "$build_old_libs"; then
+   echo
+   $ECHO "*** Warning: Linking the shared library $output 
against the"
+   $ECHO "*** static library $deplib is not portable!"
+   fi
deplibs="$deplib $deplibs"
  else
echo
-- 
2.31.1

[PATCH] Makefile.am: make sure autoheader run before autoconf

[mingli.yu]

From: Mingli Yu 

autoheader will update ../libtool-2.4.6/libltdl/config-h.in which
autoconf needs, so there comes a race sometimes as below:
 | configure.ac:45: error: required file 'config-h.in' not found
 | touch '../libtool-2.4.6/libltdl/config-h.in'

So make sure autoheader run before autoconf to avoid this race.

Signed-off-by: Mingli Yu 
---
 Makefile.am | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Makefile.am b/Makefile.am
index 6b546092..84795d87 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -370,7 +370,7 @@ lt_configure_deps = $(lt_aclocal_m4) $(lt_aclocal_m4_deps)
 $(lt_aclocal_m4): $(lt_aclocal_m4_deps)
$(AM_V_GEN)cd '$(srcdir)/$(ltdl_dir)' && $(ACLOCAL) -I ../m4
 
-$(lt_configure): $(lt_configure_deps)
+$(lt_configure): $(lt_configure_deps) $(lt_config_h_in)
$(AM_V_GEN)cd '$(srcdir)/$(ltdl_dir)' && $(AUTOCONF)
 
 $(lt_config_h_in): $(lt_configure_deps)
-- 
2.29.2

[PATCH] docs: Fix typo in 'Linking Libraries' section

[Jonathan Wakely]

* doc/libtool.texinfo: Fix typo.
---
 doc/libtool.texi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/doc/libtool.texi b/doc/libtool.texi
index 3411b377..b5e5c3fa 100644
--- a/doc/libtool.texi
+++ b/doc/libtool.texi
@@ -654,7 +654,7 @@ also that we need to add @option{-lm} to the link command 
line because
 libtool}).
 
 Another complication in building shared libraries is that we need to
-specify the path to the directory wher they will (eventually) be
+specify the path to the directory where they will (eventually) be
 installed (in this case, @file{/usr/local/lib})@footnote{If you don't
 specify an @code{rpath}, then libtool builds a libtool convenience
 archive, not a shared library (@pxref{Static libraries}).}:
-- 
2.30.2

[PATCH] docs: Use @file for .libs directory

[Jonathan Wakely]

* doc/libtool.texi: Use @file format for directory name.
---
 doc/libtool.texi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/doc/libtool.texi b/doc/libtool.texi
index b5e5c3fa..12fea4b5 100644
--- a/doc/libtool.texi
+++ b/doc/libtool.texi
@@ -869,7 +869,7 @@ against uninstalled shared libraries. The wrapper 
executable thus
 performs the same function as the wrapper script used on other
 platforms, but allows to satisfy the @command{make} rules for the
 program, whose name ends in @code{$(EXEEXT)}. The actual program
-executable is created below @value{objdir}, and its name will end
+executable is created below @file{@value{objdir}}, and its name will end
 in @code{$(EXEEXT)} and may or may not contain an @code{lt-} prefix.
 This wrapper executable sets various environment values so that the
 program executable may locate its (uninstalled) shared libraries,
-- 
2.30.2

VxWorks RTOS patches for libtool

[Xin, Peixing]

Hi ,

The patch pasted below is VxWorks patches for libtool. Anyone can help to 
review and merge it? Thanks.


>From 8976b51c86491aa283ba8b5691d82e6b1b2cef57 Mon Sep 17 00:00:00 2001
From: Peixing Xin mailto:peixing@windriver.com>>
Date: Tue, 19 Jan 2021 17:56:00 +0800
Subject: [PATCH] libtool: add VxWorks RTOS support

VxWorks uses gcc or llvm to cross-compile libraries.

* m4/libtool.m4: Add VxWorks support in
_LT_SYS_DYNAMIC_LINKER and _LT_CHECK_MAGIC_METHOD.
---
m4/libtool.m4 | 10 ++
1 file changed, 10 insertions(+)

diff --git a/m4/libtool.m4 b/m4/libtool.m4
index f2d1f398..8f0c09ee 100644
--- a/m4/libtool.m4
+++ b/m4/libtool.m4
@@ -3103,6 +3103,13 @@ uts4*)
   shlibpath_var=LD_LIBRARY_PATH
   ;;
+vxworks*)
+  version_type=linux # correct to gnu/linux during the next big refactor
+  library_names_spec='$libname$release$shared_ext$versuffix 
$libname$release$shared_ext$major $libname$shared_ext'
+  soname_spec='$libname$release$shared_ext$major'
+  shlibpath_var=LD_LIBRARY_PATH
+  ;;
+
*)
   dynamic_linker=no
   ;;
@@ -3643,6 +3650,9 @@ tpf*)
os2*)
   lt_cv_deplibs_check_method=pass_all
   ;;
+vxworks*)
+  lt_cv_deplibs_check_method=pass_all
+  ;;
esac
])
--
2.17.1

Thanks,
Peixing