[patch #9999] Fix --preserve-dup-deps flag not to strip some duplicates

[Julien ÉLIE]

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

FWIW, the patch was locally applied to INN in 2020, and there hasn't been any
build problem since then.  Building INN with libtool otherwise failed with
unresolved circular dependencies, even with the use of *--preserve-dup-deps*.

https://github.com/InterNetNews/inn/commit/e715e957fe7db5acc9ec1beaa9abb2ba120c287b#diff-6858ef1035c11e53d6a00ef454d86e2eab93aae2fc7f83f201069946e916c643


I believe it would be useful to fix it upstream too.  There even was a comment
in _ltmain.sh_ noting that the current code is broken and should be fixed,
along with the fix in a commented line:


# FIXME: Pedantically, this is the right thing to do, so
#that some nasty dependency loop isn't accidentally
#broken:
#new_libs="$deplib $new_libs"


The patch basically uses the right expected logic for *--preserve-dup-deps*.


___

Reply to this item at:

  

___
Message posté via Savannah
https://savannah.gnu.org/

Re: [PATCH] Fix Wstrict-prototypes warnings

[Peter Kokot]

On Tue, 16 Apr 2024 at 19:56, Ileana Dumitrescu
 wrote:
>
> Thank you for the patch. Diagnosing the test errors is not so easy
> without more information. Could you tell me which tests failed for you,
> and which ones you fixed with the addition of this patch? Also, which
> libtool and compiler version you are using?

Consider creating a minimalistic configure.ac:

AC_PREREQ([2.71])
AC_INIT([ExampleProject], [1.0.0])
AC_PROG_CC
AC_MSG_NOTICE([Configuring Libtool])
LT_INIT
AC_OUTPUT

Then run "autoreconf -i" to create a configure script.

And then "./configure CFLAGS=-Werror=strict-prototypes"

In the config.log file there will be error similar to this:
conftest.c:10:5: error: function declaration isn't a prototype
[-Werror=strict-prototypes]
10 | int main(){nm_test_var='a';nm_test_func();return(0);}
| ^~~~
cc1: some warnings being treated as errors

Some errors are related to Autoconf, which has fixed most of these in
2.72 already. And this patch (hopefully) fixes most if not all those
related to Libtool.

Libtool version: 2.4.7
Compiler: GCC 13.2

Issue is that some compilers might enable strict-prototypes by default
in future versions.

-- 
Peter Kokot

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

[Roumen Petrov]

На 17.04.24 г. в 18:29 ч., Ileana Dumitrescu написа:

Follow-up Comment #3, patch #10393 (group libtool):

Thank you for the suggestion. Since we are already embedding rpath into
Android, 


And this is now critical defect - https://savannah.gnu.org/support/?111011


we could take the next step and start using GNU/Linux versioning.


No!

Android loader is not compatible.

Roumen

[patch #10393] Fix shared library support on Android

[Ileana Dumitrescu]

Follow-up Comment #3, patch #10393 (group libtool):

Thank you for the suggestion. Since we are already embedding rpath into
Android, we could take the next step and start using GNU/Linux versioning.

This would be contrary to the standard method of Android versioning, in which
shared libraries are not versioned. Although this could be overwritten by
users if needed. There are probably more people on Android using Libtool with
the GNU linker than with the Android linker. I assume most people using the
Android linker are also using the Android SDK. I really have no insight into
this however, so corrections (and solutions) are welcome. :)


___

Reply to this item at:

  

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

[patch #10393] Fix shared library support on Android

[Arun]

Follow-up Comment #2, patch #10393 (group libtool):

I have a suggestion. If we try to build a library that already exist in
_/system/lib/_ or _/system/lib64_ there may be conflicts. So I think setting
version_type to _linux_ and adding _$major_ as suffix to soname_spec will be a
good idea.


___

Reply to this item at:

  

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

Re: [PATCH] Fix Wstrict-prototypes warnings

[Ileana Dumitrescu]

Thank you for the patch. Diagnosing the test errors is not so easy 
without more information. Could you tell me which tests failed for you, 
and which ones you fixed with the addition of this patch? Also, which 
libtool and compiler version you are using?


On 18/03/2024 08:55, Peter Kokot wrote:

Hello,

When building project, for example, with
CFLAGS=-Werror=strict-prototypes or similar, the libtool's
tests can cause false reports and errors in the log files:

error: function declaration isn't a prototype

The appended patch includes some fixes for such cases.

Thank you.



--
Ileana Dumitrescu

GPG Public Key: FA26 CA78 4BE1 8892 7F22 B99F 6570 EA01 146F 7354


OpenPGP_0x6570EA01146F7354.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: [PATCH] ltmain.in: Pass through -fopenmp=*

[Sam James]

Ileana Dumitrescu  writes:

> Thank you! This patch has been merged in.

Thank you!

>
> On 24/03/2024 10:26, Sam James wrote:
>> Clang uses -fopenmp=* to allow choosing between libgomp and libomp.
>> * build-aux/ltmain.in: Pass through -fopenmp=*.
>> Signed-off-by: Sam James 
>> ---
>>   build-aux/ltmain.in | 4 ++--
>>   1 file changed, 2 insertions(+), 2 deletions(-)
>> diff --git a/build-aux/ltmain.in b/build-aux/ltmain.in
>> index af4970be..6c8e90df 100644
>> --- a/build-aux/ltmain.in
>> +++ b/build-aux/ltmain.in
>> @@ -5198,7 +5198,7 @@ func_mode_link ()
>>  continue
>>  ;;
>> -mt|-mthreads|-kthread|-Kthread|-pthreads|--thread-safe \
>> -  |-threads|-fopenmp|-openmp|-mp|-xopenmp|-omp|-qsmp=*)
>> +  |-threads|-fopenmp|-fopenmp=*|-openmp|-mp|-xopenmp|-omp|-qsmp=*)
>>  func_append compiler_flags " $arg"
>>  func_append compile_command " $arg"
>>  func_append finalize_command " $arg"
>> @@ -5755,7 +5755,7 @@ func_mode_link ()
>>  found=false
>>  case $deplib in
>>  -mt|-mthreads|-kthread|-Kthread|-pthread|-pthreads|--thread-safe \
>> -|-threads|-fopenmp|-openmp|-mp|-xopenmp|-omp|-qsmp=*)
>> +|-threads|-fopenmp|-fopenmp=*|-openmp|-mp|-xopenmp|-omp|-qsmp=*)
>>if test prog,link = "$linkmode,$pass"; then
>>  compile_deplibs="$deplib $compile_deplibs"
>>  finalize_deplibs="$deplib $finalize_deplibs"

Re: [PATCH] ltmain.in: Pass through -fopenmp=*

[Ileana Dumitrescu]

Thank you! This patch has been merged in.

On 24/03/2024 10:26, Sam James wrote:

Clang uses -fopenmp=* to allow choosing between libgomp and libomp.

* build-aux/ltmain.in: Pass through -fopenmp=*.

Signed-off-by: Sam James 
---
  build-aux/ltmain.in | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/build-aux/ltmain.in b/build-aux/ltmain.in
index af4970be..6c8e90df 100644
--- a/build-aux/ltmain.in
+++ b/build-aux/ltmain.in
@@ -5198,7 +5198,7 @@ func_mode_link ()
continue
;;
-mt|-mthreads|-kthread|-Kthread|-pthreads|--thread-safe \
-  |-threads|-fopenmp|-openmp|-mp|-xopenmp|-omp|-qsmp=*)
+  |-threads|-fopenmp|-fopenmp=*|-openmp|-mp|-xopenmp|-omp|-qsmp=*)
func_append compiler_flags " $arg"
func_append compile_command " $arg"
func_append finalize_command " $arg"
@@ -5755,7 +5755,7 @@ func_mode_link ()
found=false
case $deplib in
-mt|-mthreads|-kthread|-Kthread|-pthread|-pthreads|--thread-safe \
-|-threads|-fopenmp|-openmp|-mp|-xopenmp|-omp|-qsmp=*)
+|-threads|-fopenmp|-fopenmp=*|-openmp|-mp|-xopenmp|-omp|-qsmp=*)
  if test prog,link = "$linkmode,$pass"; then
compile_deplibs="$deplib $compile_deplibs"
finalize_deplibs="$deplib $finalize_deplibs"


--
Ileana Dumitrescu

GPG Public Key: FA26 CA78 4BE1 8892 7F22 B99F 6570 EA01 146F 7354


OpenPGP_0x6570EA01146F7354.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

[PATCH] ltmain.in: Pass through -fopenmp=*

[Sam James]

Clang uses -fopenmp=* to allow choosing between libgomp and libomp.

* build-aux/ltmain.in: Pass through -fopenmp=*.

Signed-off-by: Sam James 
---
 build-aux/ltmain.in | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/build-aux/ltmain.in b/build-aux/ltmain.in
index af4970be..6c8e90df 100644
--- a/build-aux/ltmain.in
+++ b/build-aux/ltmain.in
@@ -5198,7 +5198,7 @@ func_mode_link ()
continue
;;
   -mt|-mthreads|-kthread|-Kthread|-pthreads|--thread-safe \
-  |-threads|-fopenmp|-openmp|-mp|-xopenmp|-omp|-qsmp=*)
+  |-threads|-fopenmp|-fopenmp=*|-openmp|-mp|-xopenmp|-omp|-qsmp=*)
func_append compiler_flags " $arg"
func_append compile_command " $arg"
func_append finalize_command " $arg"
@@ -5755,7 +5755,7 @@ func_mode_link ()
found=false
case $deplib in
-mt|-mthreads|-kthread|-Kthread|-pthread|-pthreads|--thread-safe \
-|-threads|-fopenmp|-openmp|-mp|-xopenmp|-omp|-qsmp=*)
+|-threads|-fopenmp|-fopenmp=*|-openmp|-mp|-xopenmp|-omp|-qsmp=*)
  if test prog,link = "$linkmode,$pass"; then
compile_deplibs="$deplib $compile_deplibs"
finalize_deplibs="$deplib $finalize_deplibs"
-- 
2.44.0

[PATCH] Fix Wstrict-prototypes warnings

[Peter Kokot]

Hello,

When building project, for example, with
CFLAGS=-Werror=strict-prototypes or similar, the libtool's
tests can cause false reports and errors in the log files:

   error: function declaration isn't a prototype

The appended patch includes some fixes for such cases.

Thank you.

-- 
Peter Kokot
From 8477915fdf027a813dfecb9e635f628a9df2ccf6 Mon Sep 17 00:00:00 2001
From: Peter Kokot 
Date: Mon, 18 Mar 2024 01:28:15 +0100
Subject: [PATCH] Fix Wstrict-prototypes warnings

This changes the C function prototypes to use void where needed. When
building with CFLAGS=-Werror=strict-prototypes or similar, the libtool's
tests can cause false reports and errors in the log files:

error: function declaration isn't a prototype
---
 build-aux/ltmain.in |  2 +-
 m4/libtool.m4   | 12 ++--
 m4/ltdl.m4  |  4 ++--
 3 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/build-aux/ltmain.in b/build-aux/ltmain.in
index af4970be..2be99842 100644
--- a/build-aux/ltmain.in
+++ b/build-aux/ltmain.in
@@ -7320,7 +7320,7 @@ func_mode_link ()
 	  # whether they linked in statically or dynamically with ldd.
 	  $opt_dry_run || $RM conftest.c
 	  cat > conftest.c <_MESSAGE_LOG_FD
   $RANLIB libconftest.a 2>_MESSAGE_LOG_FD
   cat > conftest.c << _LT_EOF
-int main() { return 0;}
+int main(void) { return 0;}
 _LT_EOF
   echo "$LTCC $LTCFLAGS $LDFLAGS -o conftest conftest.c -Wl,-force_load,./libconftest.a" >_MESSAGE_LOG_FD
   $LTCC $LTCFLAGS $LDFLAGS -o conftest conftest.c -Wl,-force_load,./libconftest.a 2>conftest.err
@@ -1879,11 +1879,11 @@ else
 /* When -fvisibility=hidden is used, assume the code has been annotated
correspondingly for the symbols needed.  */
 #if defined __GNUC__ && (((__GNUC__ == 3) && (__GNUC_MINOR__ >= 3)) || (__GNUC__ > 3))
-int fnord () __attribute__((visibility("default")));
+int fnord (void) __attribute__((visibility("default")));
 #endif
 
-int fnord () { return 42; }
-int main ()
+int fnord (void) { return 42; }
+int main (void)
 {
   void *self = dlopen (0, LT_DLGLOBAL|LT_DLLAZY_OR_NOW);
   int status = $lt_dlunknown;
@@ -4061,7 +4061,7 @@ void nm_test_func(void){}
 #ifdef __cplusplus
 }
 #endif
-int main(){nm_test_var='a';nm_test_func();return(0);}
+int main(void){nm_test_var='a';nm_test_func();return(0);}
 _LT_EOF
 
   if AC_TRY_EVAL(ac_compile); then
@@ -6233,7 +6233,7 @@ _LT_TAGVAR(objext, $1)=$objext
 lt_simple_compile_test_code="int some_variable = 0;"
 
 # Code to be used in simple link tests
-lt_simple_link_test_code='int main(){return(0);}'
+lt_simple_link_test_code='int main(void){return(0);}'
 
 _LT_TAG_COMPILER
 # Save the default compiler, since it gets overwritten when the other
diff --git a/m4/ltdl.m4 b/m4/ltdl.m4
index 548e3643..8c6222b9 100644
--- a/m4/ltdl.m4
+++ b/m4/ltdl.m4
@@ -758,7 +758,7 @@ AC_CACHE_CHECK([for _ prefix in compiled symbols],
   [lt_cv_sys_symbol_underscore=no
   cat > conftest.$ac_ext <<_LT_EOF
 void nm_test_func(){}
-int main(){nm_test_func;return 0;}
+int main(void){nm_test_func;return 0;}
 _LT_EOF
   if AC_TRY_EVAL(ac_compile); then
 # Now try to grab the symbols.
@@ -862,7 +862,7 @@ _LT_EOF
 #define RTLD_NOW 0
 #  endif
 #endif
-int main () {
+int main (void) {
   void *handle = dlopen ("`pwd`/$libname$libltdl_cv_shlibext", RTLD_GLOBAL|RTLD_NOW);
   int status = $libltdl_dlunknown;
   if (handle) {
-- 
2.40.1

Re: [PATCH] ltmain.in: correct windows compiler preprocessor checks

[Ileana Dumitrescu]

Thank you for catching this! I have merged in the fix.

On 01/03/2024 11:39, Ozkan Sezer wrote:

Commit f54924fa5d8d5959038e58adab7c552c3ca495ae seems to have been
wrongly applied.

Regards.
--
O.S.


--
Ileana Dumitrescu

GPG Public Key: FA26 CA78 4BE1 8892 7F22 B99F 6570 EA01 146F 7354


OpenPGP_0x6570EA01146F7354.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

[PATCH] ltmain.in: correct windows compiler preprocessor checks

[Ozkan Sezer]

Commit f54924fa5d8d5959038e58adab7c552c3ca495ae seems to have been
wrongly applied.

Regards.
--
O.S.
From e84eddb8b98fee7a31d95bb1b8e701f5ef3dca50 Mon Sep 17 00:00:00 2001
From: Ozkan Sezer 
Date: Fri, 1 Mar 2024 11:37:28 +0300
Subject: [PATCH] ltmain.in: correct windows compiler preprocessor checks

Commit f54924fa5d8d5959038e58adab7c552c3ca495ae seems to have been
wrongly applied.
---
 build-aux/ltmain.in |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/build-aux/ltmain.in b/build-aux/ltmain.in
index 1b8d503..af4970b 100644
--- a/build-aux/ltmain.in
+++ b/build-aux/ltmain.in
@@ -3638,7 +3638,7 @@ EOF
 #endif
 #include 
 #include 
-#if defined (WIN32) && !defined (__GNUC_)
+#if defined (_WIN32) && !defined (__GNUC__)
 # include 
 # include 
 # include 
-- 
1.7.1

[patch #9678] ltmain.sh: [_MSC_VER] should be [_WIN32] in one place

[Ileana Dumitrescu]

Update of patch#9678 (group libtool):

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

___

Follow-up Comment #1:

Thanks for the patch! I merged it in.


___

Reply to this item at:

  

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

[PATCH] libtool: Add support for SerenityOS

[Tim Schumacher]

This hobbyist OS has already been added to `config.sub` (and
`config.guess` respectively) some time ago, but was still lacking
upstream support for building libraries using libtool.

Since it is a relatively up-to-date system with ports of modern
software, "adding support" mostly just means adding empty cases to avoid
falling though to the most basic behavior (that guarantees compatibility
at the expense of disabling everything that might be critical).

* m4/libtool.m4: Add support for SerenityOS.
---
 m4/libtool.m4 | 26 ++
 1 file changed, 26 insertions(+)

diff --git a/m4/libtool.m4 b/m4/libtool.m4
index 66b12b5a..f2ef36bb 100644
--- a/m4/libtool.m4
+++ b/m4/libtool.m4
@@ -2999,6 +2999,17 @@ rdos*)
   dynamic_linker=no
   ;;

+serenity*)
+  version_type=linux # correct to gnu/linux during the next big refactor
+  need_lib_prefix=no
+  need_version=no
+  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
+  shlibpath_overrides_runpath=no
+  dynamic_linker='SerenityOS LibELF'
+  ;;
+
 solaris*)
   version_type=linux # correct to gnu/linux during the next big refactor
   need_lib_prefix=no
@@ -3595,6 +3606,10 @@ rdos*)
   lt_cv_deplibs_check_method=pass_all
   ;;

+serenity*)
+  lt_cv_deplibs_check_method=pass_all
+  ;;
+
 solaris*)
   lt_cv_deplibs_check_method=pass_all
   ;;
@@ -4469,6 +4484,8 @@ m4_if([$1], [CXX], [
;;
   psos*)
;;
+  serenity*)
+;;
   solaris*)
case $cc_basename in
  CC* | sunCC*)
@@ -4811,6 +4828,9 @@ m4_if([$1], [CXX], [
   _LT_TAGVAR(lt_prog_compiler_static, $1)='-non_shared'
   ;;

+serenity*)
+  ;;
+
 solaris*)
   _LT_TAGVAR(lt_prog_compiler_pic, $1)='-KPIC'
   _LT_TAGVAR(lt_prog_compiler_static, $1)='-Bstatic'
@@ -5917,6 +5937,9 @@ _LT_EOF
   _LT_TAGVAR(hardcode_libdir_separator, $1)=:
   ;;

+serenity*)
+  ;;
+
 solaris*)
   _LT_TAGVAR(no_undefined_flag, $1)=' -z defs'
   if test yes = "$GCC"; then
@@ -7237,6 +7260,9 @@ if test yes != "$_lt_caught_CXX_error"; then
 _LT_TAGVAR(ld_shlibs, $1)=no
 ;;

+  serenity*)
+;;
+
   sunos4*)
 case $cc_basename in
   CC*)
--
2.44.0

[patch #10433] libtool: Add support for SerenityOS

[Tim Schumacher]

URL:
  

 Summary: libtool: Add support for SerenityOS
   Group: GNU Libtool
   Submitter: timschumi
   Submitted: Sun 25 Feb 2024 01:26:01 AM 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 25 Feb 2024 01:26:01 AM UTC By: Tim Schumacher 
This hobbyist OS has already been added to `config.sub` (and
`config.guess` respectively) some time ago, but was still lacking
upstream support for building libraries using libtool.

Since it is a relatively up-to-date system with ports of modern
software, "adding support" mostly just means adding empty cases to avoid
falling though to the most basic behavior (that guarantees compatibility
at the expense of disabling everything that might be critical).






___
File Attachments:


---
Name: 0001-libtool-Add-support-for-SerenityOS.patch  Size: 2KiB


AGPL NOTICE

These attachments are served by Savane. You can download the corresponding
source code of Savane at
https://git.savannah.nongnu.org/cgit/administration/savane.git/snapshot/savane-fd9b348a8fcb146b565f753e2f7db1ab857a7bf6.tar.gz

___

Reply to this item at:

  

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

[PATCH] RISC-V doesn't allow linking non-PIC into shared objects

[Palmer Dabbelt]

I'm not sure exactly why, but it looks like this has started failing on
the latest Fedora rebuilds (with a bump to GCC-14 prereleases) with
errors along the lines of

/usr/bin/ld: .libs/libhello_la-hello.o: relocation R_RISCV_HI20 against `a 
local symbol' can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: .libs/libhello_la-foo.o: relocation R_RISCV_HI20 against `a 
local symbol' can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: unresolvable R_RISCV_CALL_PLT relocation against symbol 
`puts@@GLIBC_2.27'
/usr/bin/ld: unresolvable R_RISCV_CALL_PLT relocation against symbol 
`__printf_chk@@GLIBC_2.27'

As far as I can tell this always should have failed on RISC-V, as
non-PIC objects have never worked correctly in shared libraries.  We
have added some stricter linker error checking over the last few months
so it's possible this is a newly reported error, but I'd guess that the
resulting binaries have always been invalid.

Regardless of exactly why it's getting noticed now, R_RISCV_HI20 is very
much an absolute relocation (it maps to LUI, which just loads up a
constant address) and thus won't work for shared libraries.  Given that
other ports skip this test that seems like the way to go for RISC-V
as well.

Signed-off-by: Palmer Dabbelt 
---
 tests/demo.at | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tests/demo.at b/tests/demo.at
index feb71dcd..b62a9215 100644
--- a/tests/demo.at
+++ b/tests/demo.at
@@ -511,7 +511,7 @@ AT_CLEANUP
 AT_SETUP([force non-PIC objects])
 
 AT_CHECK([case $host in
-hppa*|amd64*|x86_64*|s390*)
+hppa*|amd64*|x86_64*|s390*|riscv*)
   # These hosts cannot use non-PIC shared libs
   exit 77 ;;
 *-solaris*|*-sunos*)
-- 
2.43.0

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

[INVALID.NOREPLY]

Follow-up Comment #3, patch#9442 (group libtool):

Seems this patch does not fully address the problem.

+ libtool --version
 libtool (GNU libtool) 2.4.7.65-e11f

For example, building hdf5 with the ARM compiler, with an MPI compiler
wrapper
I still get this error:

flang: error: unknown argument: '-soname'

Looking at the libtool script produced by configure,
I still see empty wl= 

11810 # ### BEGIN LIBTOOL TAG CONFIG: FC
11811   
11812 # The linker used to build libraries.
11813
LD="/bm/ashterenli/install/arm-compiler-for-linux_23.10_AmazonLinux-2/gcc-12.2.0_AmazonLinux-2/aarch64-linux-gnu/bin/ld"
11814 
11815 # How to create reloadable object files.
11816 reload_flag=" -r"
11817 reload_cmds="\$LD\$reload_flag -o \$output\$reload_objs"
11818 
11819 # Commands used to build an old-style archive.
11820 old_archive_cmds="\$AR \$AR_FLAGS \$oldlib\$oldobjs~\$RANLIB
\$tool_oldlib"
11821 
11822 # A language specific compiler.
11823 CC="ftn"
11824 
11825 # Is the compiler the GNU compiler?
11826 with_gcc=no
11827   
11828 # Compiler flag to turn off builtin functions.
11829 no_builtin_flag=""
11830   
11831 # Additional compiler flags for building library objects.
11832 pic_flag=""
11833   
11834 # How to pass a linker flag through the compiler.
11835 wl=""   


And I still have to fix the libtool script with:

sed -i -e 's/wl=""/wl="-Wl,"/g' libtool

which I got from: https://github.com/Unidata/netcdf-fortran/issues/309






___

Reply to this item at:

  

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

[PATCH] m4: update serial numbers in modified files

[Mike Frysinger]

These should have been included in the commits that updated these
files, but too late now to rewrite git history.

* m4/libtool.m4: Update serial number.
* m4/ltdl.m4, m4/ltoptions.m4: Likewise.
---
 m4/libtool.m4   | 2 +-
 m4/ltdl.m4  | 2 +-
 m4/ltoptions.m4 | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/m4/libtool.m4 b/m4/libtool.m4
index 20527f830aa1..d9725fdfd1cd 100644
--- a/m4/libtool.m4
+++ b/m4/libtool.m4
@@ -32,7 +32,7 @@ m4_define([_LT_COPYING], [dnl
 # along with this program.  If not, see .
 ])
 
-# serial 59 LT_INIT
+# serial 60 LT_INIT
 
 
 # LT_PREREQ(VERSION)
diff --git a/m4/ltdl.m4 b/m4/ltdl.m4
index 0c43799cdecc..548e3643196e 100644
--- a/m4/ltdl.m4
+++ b/m4/ltdl.m4
@@ -8,7 +8,7 @@
 # unlimited permission to copy and/or distribute it, with or without
 # modifications, as long as this notice is preserved.
 
-# serial 21 LTDL_INIT
+# serial 22 LTDL_INIT
 
 # LT_CONFIG_LTDL_DIR(DIRECTORY, [LTDL-MODE])
 # --
diff --git a/m4/ltoptions.m4 b/m4/ltoptions.m4
index e24ae1538b6b..6dfe99f1f200 100644
--- a/m4/ltoptions.m4
+++ b/m4/ltoptions.m4
@@ -8,7 +8,7 @@
 # unlimited permission to copy and/or distribute it, with or without
 # modifications, as long as this notice is preserved.
 
-# serial 8 ltoptions.m4
+# serial 9 ltoptions.m4
 
 # This is to help aclocal find these macros, as it can't see m4_define.
 AC_DEFUN([LTOPTIONS_VERSION], [m4_if([1])])
-- 
2.43.0

[patch #41] Do all rm's in one command with --mode=clean

[Ileana Dumitrescu]

Update of patch#41 (group libtool):

  Status:None => Wont Do
 Open/Closed:Open => Closed 

___

Follow-up Comment #2:

The patch no longer seems attached, and the first comment provides a
reasonable reason for rejecting the patch. So I'm closing this.


___

Reply to this item at:

  

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

Re: [PATCH] libtool.m4: Fix -export-symbols for GNU ld on non-Linux

[Ileana Dumitrescu]

On 23/01/2024 03:38, Mike Frysinger wrote:

On 22 Jan 2024 15:34, Tijl Coosemans wrote:

Apply the fix for Linux from fb5e6cda96bd9dcae9e4f62ec8b6b3e572a32743
to the non-Linux cases.

-export-symbols was implemented using --retain-symbols-file. For
non-exported symbols this flag tries to remove symbol information
altogether which it can only do if a symbol isn't referenced
anywhere. So, often this flag doesn't do anything. With a version
script non-exported symbols can be marked local instead of removed.


this looks fine, but i kind of think we should wait to kick out the current
release and then merge it
-mike


I agree. I'm currently waiting on upload permissions to Savannah, so
that I can upload an alpha. If it takes too long to get permissions,
I'll consider going ahead and merging this in.

--
Ileana Dumitrescu

GPG Public Key: FA26 CA78 4BE1 8892 7F22 B99F 6570 EA01 146F 7354


OpenPGP_0x6570EA01146F7354.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: [PATCH] libtool.m4: Fix -export-symbols for GNU ld on non-Linux

[Mike Frysinger]

On 22 Jan 2024 15:34, Tijl Coosemans wrote:
> Apply the fix for Linux from fb5e6cda96bd9dcae9e4f62ec8b6b3e572a32743
> to the non-Linux cases.
> 
> -export-symbols was implemented using --retain-symbols-file. For
> non-exported symbols this flag tries to remove symbol information
> altogether which it can only do if a symbol isn't referenced
> anywhere. So, often this flag doesn't do anything. With a version
> script non-exported symbols can be marked local instead of removed.

this looks fine, but i kind of think we should wait to kick out the current
release and then merge it
-mike


signature.asc
Description: PGP signature

Re: [PATCH] tests/demo.at: Also test for amd64 where we test for x86_64

[Mike Frysinger]

On 22 Jan 2024 14:12, Tijl Coosemans wrote:
> It is used on FreeBSD.
> 
> * tests/demo.at: Also test for amd64 where we test for x86_64.

thx, merged now
-mike


signature.asc
Description: PGP signature

Re: [PATCH] libtool.m4: Fix -export-symbols for GNU ld on non-Linux

[Tijl Coosemans]

On Mon, 22 Jan 2024 15:34:38 +0100 Tijl Coosemans  wrote:
> Apply the fix for Linux from fb5e6cda96bd9dcae9e4f62ec8b6b3e572a32743
> to the non-Linux cases.
> 
> -export-symbols was implemented using --retain-symbols-file. For
> non-exported symbols this flag tries to remove symbol information
> altogether which it can only do if a symbol isn't referenced
> anywhere. So, often this flag doesn't do anything. With a version
> script non-exported symbols can be marked local instead of removed.
> 
> * m4/libtool.m4: Fix -export-symbols for GNU ld on non-Linux.
> ---
>  m4/libtool.m4 | 35 ++-
>  1 file changed, 30 insertions(+), 5 deletions(-)

Note that --retain-symbols-file is also used in the non-GNU ld case and
in the C++ case.  This patch doesn't change those.

If accepted, you may want to mention this in the NEWS file because this
change may have a significant impact in some cases.

[PATCH] libtool.m4: Fix -export-symbols for GNU ld on non-Linux

[Tijl Coosemans]

Apply the fix for Linux from fb5e6cda96bd9dcae9e4f62ec8b6b3e572a32743
to the non-Linux cases.

-export-symbols was implemented using --retain-symbols-file. For
non-exported symbols this flag tries to remove symbol information
altogether which it can only do if a symbol isn't referenced
anywhere. So, often this flag doesn't do anything. With a version
script non-exported symbols can be marked local instead of removed.

* m4/libtool.m4: Fix -export-symbols for GNU ld on non-Linux.
---
 m4/libtool.m4 | 35 ++-
 1 file changed, 30 insertions(+), 5 deletions(-)

diff --git a/m4/libtool.m4 b/m4/libtool.m4
index 20527f83..5e6a283b 100644
--- a/m4/libtool.m4
+++ b/m4/libtool.m4
@@ -5192,7 +5192,12 @@ _LT_EOF
   # 256 KiB-aligned image base between 0x5000 and 0x6FFC at link
   # time.  Moving up from 0x1000 also allows more sbrk(2) space.
   _LT_TAGVAR(archive_cmds, $1)='$CC -shared $pic_flag $libobjs $deplibs 
$compiler_flags $wl-h,$soname $wl--image-base,`expr ${RANDOM-$$} % 4096 / 2 \* 
262144 + 1342177280` -o $lib'
-  _LT_TAGVAR(archive_expsym_cmds, $1)='$SED "s|^|_|" $export_symbols 
>$output_objdir/$soname.expsym~$CC -shared $pic_flag $libobjs $deplibs 
$compiler_flags $wl-h,$soname 
$wl--retain-symbols-file,$output_objdir/$soname.expsym $wl--image-base,`expr 
${RANDOM-$$} % 4096 / 2 \* 262144 + 1342177280` -o $lib'
+  if test yes = "$supports_anon_versioning"; then
+   _LT_TAGVAR(archive_expsym_cmds, $1)='echo "{ global:" > 
$output_objdir/$libname.ver~
+ $SED "s/.*/_&;/" $export_symbols >> $output_objdir/$libname.ver~
+ echo "local: *; };" >> $output_objdir/$libname.ver~
+ $CC -shared $pic_flag $libobjs $deplibs $compiler_flags $wl-h,$soname 
$wl--version-script,$output_objdir/$libname.ver $wl--image-base,`expr 
${RANDOM-$$} % 4096 / 2 \* 262144 + 1342177280` -o $lib'
+  fi
   ;;
 
 gnu* | linux* | tpf* | k*bsd*-gnu | kopensolaris*-gnu)
@@ -5280,7 +5285,12 @@ _LT_EOF
wlarc=
   else
_LT_TAGVAR(archive_cmds, $1)='$CC -shared $pic_flag $libobjs $deplibs 
$compiler_flags $wl-soname $wl$soname -o $lib'
-   _LT_TAGVAR(archive_expsym_cmds, $1)='$CC -shared $pic_flag $libobjs 
$deplibs $compiler_flags $wl-soname $wl$soname $wl-retain-symbols-file 
$wl$export_symbols -o $lib'
+   if test yes = "$supports_anon_versioning"; then
+ _LT_TAGVAR(archive_expsym_cmds, $1)='echo "{ global:" > 
$output_objdir/$libname.ver~
+   $SED "s/$/;/" $export_symbols >> $output_objdir/$libname.ver~
+   echo "local: *; };" >> $output_objdir/$libname.ver~
+   $CC -shared $pic_flag $libobjs $deplibs $compiler_flags $wl-soname 
$wl$soname $wl--version-script $wl$output_objdir/$libname.ver -o $lib'
+   fi
   fi
   ;;
 
@@ -5299,7 +5309,12 @@ _LT_EOF
 _LT_EOF
   elif $LD --help 2>&1 | $GREP ': supported targets:.* elf' > /dev/null; 
then
_LT_TAGVAR(archive_cmds, $1)='$CC -shared $pic_flag $libobjs $deplibs 
$compiler_flags $wl-soname $wl$soname -o $lib'
-   _LT_TAGVAR(archive_expsym_cmds, $1)='$CC -shared $pic_flag $libobjs 
$deplibs $compiler_flags $wl-soname $wl$soname $wl-retain-symbols-file 
$wl$export_symbols -o $lib'
+   if test yes = "$supports_anon_versioning"; then
+ _LT_TAGVAR(archive_expsym_cmds, $1)='echo "{ global:" > 
$output_objdir/$libname.ver~
+   $SED "s/$/;/" $export_symbols >> $output_objdir/$libname.ver~
+   echo "local: *; };" >> $output_objdir/$libname.ver~
+   $CC -shared $pic_flag $libobjs $deplibs $compiler_flags $wl-soname 
$wl$soname $wl--version-script $wl$output_objdir/$libname.ver -o $lib'
+   fi
   else
_LT_TAGVAR(ld_shlibs, $1)=no
   fi
@@ -5328,7 +5343,12 @@ _LT_EOF
  if $LD --help 2>&1 | $GREP ': supported targets:.* elf' > /dev/null; 
then
_LT_TAGVAR(hardcode_libdir_flag_spec, $1)='$wl-rpath $wl$libdir'
_LT_TAGVAR(archive_cmds, $1)='$CC -shared $libobjs $deplibs 
$compiler_flags $wl-soname $wl$soname -o $lib'
-   _LT_TAGVAR(archive_expsym_cmds, $1)='$CC -shared $libobjs $deplibs 
$compiler_flags $wl-soname $wl$soname $wl-retain-symbols-file 
$wl$export_symbols -o $lib'
+   if test yes = "$supports_anon_versioning"; then
+ _LT_TAGVAR(archive_expsym_cmds, $1)='echo "{ global:" > 
$output_objdir/$libname.ver~
+   $SED "s/$/;/" $export_symbols >> $output_objdir/$libname.ver~
+   echo "local: *; };" >> $output_objdir/$libname.ver~
+   $CC -shared $libobjs $deplibs $compiler_flags $wl-soname 
$wl$soname $wl--version-script $wl$output_objdir/$libname.ver -o $lib'
+   fi
  else
_LT_TAGVAR(ld_shlibs, $1)=no
  fi
@@ -5346,7 +5366,12 @@ _LT_EOF
 *)
   if $LD --help 2>&1 | $GREP ': supported targets:.* elf' > /dev/null; then
_LT_TAGVAR(archive_cmds, $1)='$CC -shared $pic_flag $libobjs $deplibs 
$compiler_flags $wl-soname 

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

[KO Myung-Hun]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi/2.

Mike Frysinger wrote:
> On 17 Jan 2024 22:44, KO Myung-Hun wrote:
>> Mike Frysinger wrote:
>>> On 16 Jan 2024 23:44, KO Myung-Hun wrote:
 Some OSes such as OS/2, uses ';' as a path separator. So
 using $PATH_SEPARATOR instead of hard-coded ':' is more
 proper.
>>> 
>>> so we're on the same page, we're talking about the separator
>>> that is used in the $PATH environment variable.  it doesn't
>>> show up in other places -- it is not used to separate e.g.
>>> rpath entries right ?  what about LD_LIBRARY_PATH and similar
>>> vars ?  i guess we assume the separator used by PATH is also
>>> used with that var ?
>> 
>> This is applied to all the variables containing a list of paths
>> and/or dirs separated by ':' including PATH and LD_LIBRARY_PATH.
>> 
>> If rpath entries is separated by ':', it's also true.
> 
> i'm not familiar with the diff (non-glibc) runtime loaders, so will
> take your word for this.  afaict, libtool has behaved this way for
> a long time, so i'm a bit inclined to wait for 2.4.8 release and
> then merge it.

This is true for `libtool: Limit a length of DLL name to 8.3
correctly' patch ?

- -- 
KO Myung-Hun

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

iD8DBQFlrlAqE9YstvghgroRAu9lAJ9PNW+i6302JaHF1EJdwflkAaqXCwCfQkBX
TD0X3lZjcbypyNfW27XR800=
=j071
-END PGP SIGNATURE-

Re: [PATCH 2/2] libtoolize: always copy config-h.in like aclocal.m4

[Roumen Petrov]

Hi,

Mike Frysinger wrote:

When running `libtoolize --ltdl`, a symlink to the source config-h.in
is used rather than a copy of the file.  ...

This is fine . Command supports --copy and this is documented in manual page.


  This breaks `make distcheck` because when a few tests run
that invoke `libtoolize --ltdl --install` w/out --copy, and then try

This is not only autotool that install links . More or less this is expected.



to build the project, automake's rules trigger autoheader regen, and
then update the timestamp, which updates the underlying file, and then
causes libtool's own files to get out of sync.  So the next time make
is run in the tree, it tries to regenerate the source files, and fails
as the source tree is read-only.

Change libtoolize to always copying the header over during install.
...

Sure Just to remind what is output from $ autoreconf -ifv

...
autoreconf: running: libtoolize --copy --force
...
autoreconf: running: automake --add-missing --copy --force-missing
...

Remark: project does not use ltld.


Roumen

Re: [PATCH] doc: minor fixes

[Ileana Dumitrescu]

On 20/01/2024 15:43, Mike Frysinger wrote:

* doc/libtool.texi: Fix some style & minor grammar.
---
  doc/libtool.texi | 12 ++--
  1 file changed, 6 insertions(+), 6 deletions(-) 


Thanks, I merged it in.

--
Ileana Dumitrescu

GPG Public Key: FA26 CA78 4BE1 8892 7F22 B99F 6570 EA01 146F 7354


OpenPGP_0x6570EA01146F7354.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

[PATCH] doc: minor fixes

[Mike Frysinger]

* doc/libtool.texi: Fix some style & minor grammar.
---
 doc/libtool.texi | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/doc/libtool.texi b/doc/libtool.texi
index ba2e99809de2..44f7eae26468 100644
--- a/doc/libtool.texi
+++ b/doc/libtool.texi
@@ -885,7 +885,7 @@ on to the program executable.  Therefore, the program 
executable may not
 employ command line options that begin with @code{--lt-}. (In fact, the
 wrapper executable will detect any command line options that begin with
 @code{--lt-} and abort with an error message if the option is not
-recognized). If this presents a problem, please contact the Libtool
+recognized.) If this presents a problem, please contact the Libtool
 team at @value{BUGADDR}.
 
 These command line options include:
@@ -1792,8 +1792,8 @@ These individual steps are often automated with 
@command{autoreconf}.
 
 Here is a diagram showing how such a typical Libtool configuration works
 when preparing a package for distribution, assuming that @file{m4} has
-been chosen as location for additional Autoconf macros, and
-@file{build-aux} as location for auxiliary build tools (@pxref{Input,,
+been chosen as the location for additional Autoconf macros, and
+@file{build-aux} as the location for auxiliary build tools (@pxref{Input,,
 The Autoconf Manual, autoconf, The Autoconf Manual}):
 
 @example
@@ -2046,8 +2046,8 @@ generated header file), you may find it necessary to 
manually record
 these dependencies.
 Because libtool archives generate object file names manually recording these
 dependencies is not as straightforward as the examples in Automake's manual
-describe in their examples.
-This effects header files in particular, because simply listing them as
+describe.
+This affects header files in particular, because simply listing them as
 @samp{nodist_libfoo_la_SOURCES} will not cause Automake to establish a
 dependent relationship for the object files of @file{libfoo.la}.
 A useful trick (although somewhat imprecise) is to manually record built
@@ -6160,7 +6160,7 @@ cross-compiling, and affects only the ability to launch 
host platform
 executables on the build platform using an emulation or API-enhancement
 environment such as Wine.  Failure to convert paths
 (@pxref{File Name Conversion Failure}) will cause a warning to be issued, but
-rarely causes the build to fail---and should have no affect on the compiled
+rarely causes the build to fail---and should have no effect on the compiled
 products, once installed properly on the host platform.  For more information,
 @pxref{Cross compiling}.
 
-- 
2.43.0

[PATCH 2/2] libtoolize: always copy config-h.in like aclocal.m4

[Ileana Dumitrescu]

I looked over and applied both the patches and they work
for me. I was running into the same permissions issue.
--
Ileana Dumitrescu

GPG Public Key: FA26 CA78 4BE1 8892 7F22 B99F 6570 EA01 146F 7354


OpenPGP_0x6570EA01146F7354.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

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

[Mike Frysinger]

On 17 Jan 2024 22:44, KO Myung-Hun wrote:
> Mike Frysinger wrote:
> > On 16 Jan 2024 23:44, KO Myung-Hun wrote:
> >> Some OSes such as OS/2, uses ';' as a path separator. So using 
> >> $PATH_SEPARATOR instead of hard-coded ':' is more proper.
> > 
> > so we're on the same page, we're talking about the separator that
> > is used in the $PATH environment variable.  it doesn't show up in
> > other places -- it is not used to separate e.g. rpath entries right
> > ?  what about LD_LIBRARY_PATH and similar vars ?  i guess we assume
> > the separator used by PATH is also used with that var ?
> 
> This is applied to all the variables containing a list of paths and/or
> dirs separated by ':' including PATH and LD_LIBRARY_PATH.
> 
> If rpath entries is separated by ':', it's also true.

i'm not familiar with the diff (non-glibc) runtime loaders, so will take your
word for this.  afaict, libtool has behaved this way for a long time, so i'm
a bit inclined to wait for 2.4.8 release and then merge it.
-mike


signature.asc
Description: PGP signature

[PATCH 1/2] bootstrap: don't reset config-h.in timestamp newer than configure

[Mike Frysinger]

Various autotools rules will compare the timestamps of config-h.in
and configure, and if config-h.in is newer than configure, attempt
to regenerate it.  This breaks `make distcheck` which we need to
produce new releases.  So update config-h.in timestamp, but only
up to the configure file.

The breakage is caught because distcheck makes source dirs read-only
before running.

$ make distcheck
...
make[3]: Entering directory '.../libtool-2.4.7.62-7132f/_build/sub'
  GEN  ../../libltdl/configure
autom4te-2.72: error: cannot create autom4te.cache in 
.../libtool-2.4.7.62-7132f/libltdl: Permission denied
make[3]: *** [Makefile:2411: ../../libltdl/configure] Error 1

* bootstrap.conf (libtool_fudge_timestamps): Set config-h.in timestamp
to configure.
---
 bootstrap.conf | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/bootstrap.conf b/bootstrap.conf
index 808321a0897b..85ac3ee19748 100644
--- a/bootstrap.conf
+++ b/bootstrap.conf
@@ -269,12 +269,17 @@ func_add_hook func_fini 
libtool_readme_release_package_substitutions
 # are updated.  Unfortunately config-h.in depends on aclocal.m4, which
 # *is* updated, so running 'libtoolize --ltdl=. && configure && make'
 # causes autoheader to be called... undesirable for users that do not
-# have it!  Fudge the timestamp to prevent that:
+# have it!  Fudge the timestamp to prevent that.  But only fudge it as
+# much as configure since configure depends on config-h.in and we don't
+# want to require autoconf either.
 libtool_fudge_timestamps ()
 {
 $debug_cmd
 
-sleep 2 && touch libltdl/config-h.in
+(
+cd libltdl
+touch -r configure config-h.in
+)
 }
 func_add_hook func_fini libtool_fudge_timestamps
 
-- 
2.43.0

[PATCH 2/2] libtoolize: always copy config-h.in like aclocal.m4

[Mike Frysinger]

When running `libtoolize --ltdl`, a symlink to the source config-h.in
is used rather than a copy of the file.  This causes the build system
to look at its old timestamp relative to the other generated files
that are copied in, and then try to regenerate things, and update the
config-h.in timestamp by touching the symlink (which will dereference
things).  This breaks `make distcheck` because when a few tests run
that invoke `libtoolize --ltdl --install` w/out --copy, and then try
to build the project, automake's rules trigger autoheader regen, and
then update the timestamp, which updates the underlying file, and then
causes libtool's own files to get out of sync.  So the next time make
is run in the tree, it tries to regenerate the source files, and fails
as the source tree is read-only.

Change libtoolize to always copying the header over during install.
It's not clear to me whether this is 100% the right answer, but it
shouldn't make things worse beyond missing a case to use a symlink.
We probably can't avoid this as long as aclocal.m4 itself is copied
in instead of symlinked.  This changed between v2.4.2 and v2.4.3 in
commit 4e671d6ba69c889b1f9aee12de6c504d26dc6514 ("libtoolize:
simplify file-copying and -linking call-graph.").

Example failure log:

$ make distcheck
...
make[3]: Entering directory '.../libtool-2.4.7.62-3e11/_build/sub'
  GEN  ../../libltdl/Makefile.in
  GEN  ../../libltdl/configure
autom4te-2.72: error: cannot create autom4te.cache in 
.../libtool-2.4.7.62-3e11/libltdl: Permission denied
make[3]: *** [Makefile:2411: ../../libltdl/configure] Error 1
make[3]: *** Waiting for unfinished jobs
autom4te-2.72: error: cannot create autom4te.cache in 
.../libtool-2.4.7.62-3e11/libltdl: Permission denied
automake-1.16: error: autoconf failed with exit status: 1
make[3]: *** [Makefile:2387: ../../libltdl/Makefile.in] Error 1

We can see this in old-m4-iface.at:AC_WITH_LTDL which doesn't use
--copy with libtoolize:

$ stat libltdl/config-h.in | grep Modify
Modify: 2024-01-18 01:18:52.998059970 -0500
$ make check-local TESTSUITEFLAGS=100
...
100: AC_WITH_LTDLok
...
$ stat libltdl/config-h.in | grep Modify
Modify: 2024-01-18 01:19:19.254727020 -0500

And in the test log we can see:

100. old-m4-iface.at:113: testing AC_WITH_LTDL ...
...
libtoolize: linking file 'libltdl/config-h.in'
...
./old-m4-iface.at:161: : ${CONFIG_SHELL=/bin/sh}; export CONFIG_SHELL;
$CONFIG_SHELL ./configure $configure_options   --prefix="$prefix" 
--exec-prefix="$prefix" --bindir="$prefix/bin" --libdir="$prefix/lib" 
--with-included-ltdl
...
./old-m4-iface.at:161: $as_unset LIBTOOL; $as_unset LIBTOOLIZE; $MAKE $target
stderr:
stdout:
cd libltdl && make
make[1]: Entering directory 
'/usr/local/src/gnu/libtool/tests/testsuite.dir/100/libltdl'
CDPATH="${ZSH_VERSION+.}:" && cd . && aclocal -I m4
 cd . && automake --foreign
CDPATH="${ZSH_VERSION+.}:" && cd . && autoconf
/bin/sh ./config.status --recheck
...
(CDPATH="${ZSH_VERSION+.}:" && cd . && autoheader)
rm -f stamp-h1
touch config-h.in
...

* libtoolize.in: Copy config-h.in.
* tests/libtoolize.at: Change "linking" to "copying".
---
 libtoolize.in   | 10 +-
 tests/libtoolize.at |  4 ++--
 2 files changed, 11 insertions(+), 3 deletions(-)

diff --git a/libtoolize.in b/libtoolize.in
index 631069418eb0..336fc81bd5ea 100644
--- a/libtoolize.in
+++ b/libtoolize.in
@@ -947,7 +947,15 @@ func_install_pkgltdl_files ()
  ;;
 
 config-h.in)
-  test subproject = "$ltdl_mode" || continue
+  test subproject = "$ltdl_mode" && {
+# Always copy config-h.in, otherwise automake's autoheader rules
+# will change the destination's timestamp if it is symlinked.
+( opt_copy=:
+  func_copy "$file" "$pkgltdldir" "$ltdl_dir" \
+pkgltdl_header "$my_copy_filter"
+)
+  }
+  continue
   ;;
 
 configure)
diff --git a/tests/libtoolize.at b/tests/libtoolize.at
index fec51c61c5e6..cbc21d68b61d 100644
--- a/tests/libtoolize.at
+++ b/tests/libtoolize.at
@@ -471,7 +471,7 @@ libtoolize: linking file 'ltdl/README'
 libtoolize: linking file 'ltdl/configure.ac'
 libtoolize: copying file 'ltdl/aclocal.m4'
 libtoolize: linking file 'ltdl/Makefile.in'
-libtoolize: linking file 'ltdl/config-h.in'
+libtoolize: copying file 'ltdl/config-h.in'
 libtoolize: copying file 'ltdl/configure'
 libtoolize: linking file 'ltdl/libltdl/lt__alloc.h'
 libtoolize: linking file 'ltdl/libltdl/lt__argz_.h'
@@ -1047,7 +1047,7 @@ libtoolize: linking file 'ltdl/README'
 libtoolize: creating file 'ltdl/configure.ac'
 libtoolize: creating file 'ltdl/aclocal.m4'
 libtoolize: creating file 'ltdl/Makefile.in'
-libtoolize: linking file 'ltdl/config-h.in'
+libtoolize: copying file 'ltdl/config-h.in'
 libtoolize: creating file 'ltdl/configure'
 libtoolize: linking file 'ltdl/libltdl/lt__alloc.h'
 libtoolize: linking file 

[PATCH] HACKING: add more test related tips

[Mike Frysinger]

* HACKING: Document syntax-check & distcheck & parallel testing.
---
 HACKING | 16 ++--
 1 file changed, 14 insertions(+), 2 deletions(-)

diff --git a/HACKING b/HACKING
index 664251e680a9..38401c9cd732 100644
--- a/HACKING
+++ b/HACKING
@@ -24,6 +24,14 @@ and is not part of a release distribution.
   that demonstrates the bug.  Then fix the bug, re-run the test suite,
   and check everything in.
 
+* Always run the testsuite after applying a patch:
+make check syntax-check TESTSUITEFLAGS="--jobs=$(nproc)" -j$(nproc)
+
+  Ideally also verify the release process doesn't break:
+make distcheck TESTSUITEFLAGS="--jobs=$(nproc)" -j$(nproc)
+  This will run check & syntax-check from above, but will take longer as
+  builds & tests in different configurations.
+
 * Some files in the libtool package are not owned by libtool.  These
   files should never be edited here.  These files are:
COPYING
@@ -55,13 +63,17 @@ and is not part of a release distribution.
   AT_CHECK) is on a single line so that 'testsuite -x' displays the
   whole thing.  You can use m4_do or '[... ]dnl' to wrap long lines.
 
-* Use
-make -k check
+* Run tests in parallel with
+make -k check TESTSUITEFLAGS="--jobs=$(nproc)"
   liberally, on as many platforms as you can.  Use as many compilers and
   linkers you can.  To run old and new testsuites separately, use:
 make check TESTSUITEFLAGS=-V
 make check-local
 
+* The gnulib module also provides some maintainer-focused tests that only
+  work when run from a git checkout.
+make syntax-check
+
 * The new Autotest testsuite uses keywords to denote test features:
 autoconf   needs Autoconf
 automake   needs Automake
-- 
2.43.0

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

[Mike Frysinger]

On 17 Jan 2024 12:39, Richard Purdie wrote:
> clang uses -rtlib and --unwindlib to select proper compiler runtime in
> some cases. Therefore pass these options to linker when found in
> ldflags

merged, thanks
-mike


signature.asc
Description: PGP signature

Re: [PATCH 3/3] libtool.m4: Cleanup sysroot trailing "/"

[Mike Frysinger]

On 17 Jan 2024 12:39, Richard Purdie wrote:
> If $CC has --sysroot=/, it is a valid configuration however libtool will
> then set lt_sysroot to "/".
> 
> This means references like $lt_sysroot$libdir become //usr/lib instead
> of the more normally expected /usr/lib. This may or may not break something
> but certainly is confusing to the user and gives confusing output. Making
> "/" simply unset lt_sysroot is much cleaner.
> 
> Whilst here, trim any trailing '/' from sysroot paths to drop the duplication
> and result in cleaner/consistent output.

merged, thanks
-mike


signature.asc
Description: PGP signature

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

[Mike Frysinger]

On 17 Jan 2024 12:39, Richard Purdie wrote:
> If lto is enabled, we need the prefix-map variables to be passed to the linker
> to correctly link the objects using correctly mapped paths.
> 
> Add these to the list of options libtool passes through.

merged, thanks
-mike


signature.asc
Description: PGP signature

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

[Nick Alcock]

On 17 Jan 2024, Mike Frysinger told this:

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

Truly, the dead walk!

(Thank you.)

(There are a few related problems on other architectures I've fixed in
the binutils copy of libtool.m4 too -- I think I posted them to the list
lo these many years ago as well.)

-- 
NULL && (void)

Re: patch to correct fallout from freebsd-elf changes

[Mike Frysinger]

On 18 Jun 2017 19:43, Tim Rice wrote:
> Here is a small patch to correct builds on svr5.
> When the freebsd-elf target was changed, this got missed.
> 
> Symptoms were, build newer lib ened up with libfo.nn a loser number
> than the previous version. And building libpng-1.6.29 produced
> libtool:   error: CURRENT '' must be a nonnegative integer
> libtool:   error: '16:29:0' is not valid version information
> 
> Patch attached and inline here.

merged, thanks.

in the future, please make & send standard git commits instead.
when you attach patches, it makes things difficult for us to merge.
-mike


signature.asc
Description: PGP signature

Re: patch to correct fallout from freebsd-elf changes

[Tim Rice]

[original post:
https://lists.gnu.org/archive/html/libtool-patches/2017-06/msg0.html]

With all the flurry of commits I'm hoping this gets included.
[And gives me a chance to correct all the embarrassing typos
in the body of the original message]

Thanks.

On Sun, 18 Jun 2017, Tim Rice wrote:

> 
> Here is a small patch to correct builds on svr5.
> When the freebsd-elf target was changed, this got missed.
> 
> Symptoms were, building newer lib ended up with libfoo.nn a lower number
> than the previous version. And building libpng-1.6.29 produced
> libtool:   error: CURRENT '' must be a nonnegative integer
> libtool:   error: '16:29:0' is not valid version information
> 
> Patch attached and inline here.
> 
> diff --git a/build-aux/ltmain.in b/build-aux/ltmain.in
> index bbc7643..d3ee94f 100644
> --- a/build-aux/ltmain.in
> +++ b/build-aux/ltmain.in
> @@ -6919,7 +6919,7 @@ func_mode_link ()
>   age=$number_minor
>   revision=$number_revision
>   ;;
> -   freebsd-aout|qnx|sunos)
> +   freebsd-aout|qnx|sco|sunos)
>   current=$number_major
>   revision=$number_minor
>   age=0
> 
> 

-- 
Tim RiceMultitalents
t...@multitalents.net
diff --git a/build-aux/ltmain.in b/build-aux/ltmain.in
index bbc7643..d3ee94f 100644
--- a/build-aux/ltmain.in
+++ b/build-aux/ltmain.in
@@ -6919,7 +6919,7 @@ func_mode_link ()
age=$number_minor
revision=$number_revision
;;
- freebsd-aout|qnx|sunos)
+ freebsd-aout|qnx|sco|sunos)
current=$number_major
revision=$number_minor
age=0

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

[Bob Friesenhahn]

On Wed, 17 Jan 2024, Roumen Petrov wrote:


Hi All

Mike Frysinger wrote:

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

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

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

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


This seems like a strong argument, but there are other factors.

A strong reason to stop supporting a target/version is if it's 
existence interferes with maintenance/development and there is no 
reasonable means available to verify that the support still works.


Support which is not periodically tested likely does not work any 
more.


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 1/2] libtool: replace : with $PATH_SEPARATOR

[KO Myung-Hun]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1



Mike Frysinger wrote:
> On 16 Jan 2024 23:44, KO Myung-Hun wrote:
>> Some OSes such as OS/2, uses ';' as a path separator. So using 
>> $PATH_SEPARATOR instead of hard-coded ':' is more proper.
> 
> so we're on the same page, we're talking about the separator that
> is used in the $PATH environment variable.  it doesn't show up in
> other places -- it is not used to separate e.g. rpath entries right
> ?  what about LD_LIBRARY_PATH and similar vars ?  i guess we assume
> the separator used by PATH is also used with that var ?

This is applied to all the variables containing a list of paths and/or
dirs separated by ':' including PATH and LD_LIBRARY_PATH.

If rpath entries is separated by ':', it's also true.

- -- 
KO Myung-Hun

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

iD8DBQFlp9m6E9YstvghgroRAqRsAKCpMU2R0Ci96WrlxC4v3MeDSnJBlACgtwJo
sb+xmV5nLYLHccbW8uJl4W8=
=FtDX
-END PGP SIGNATURE-

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

[Richard Purdie]

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

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

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

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

[Richard Purdie]

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

Add these to the list of options libtool passes through.

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

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

[PATCH 3/3] libtool.m4: Cleanup sysroot trailing "/"

[Richard Purdie]

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

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

Whilst here, trim any trailing '/' from sysroot paths to drop the duplication
and result in cleaner/consistent output.

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

diff --git a/m4/libtool.m4 b/m4/libtool.m4
index ed572bb3..f2532f0e 100644
--- a/m4/libtool.m4
+++ b/m4/libtool.m4
@@ -1255,7 +1255,9 @@ lt_sysroot=
 case $with_sysroot in #(
  yes)
if test yes = "$GCC"; then
- lt_sysroot=`$CC --print-sysroot 2>/dev/null`
+ # Trim trailing / since we'll always append absolute paths and we want
+ # to avoid //, if only for less confusing output for the user.
+ lt_sysroot=`$CC --print-sysroot 2>/dev/null | $SED 's:/\+$::'`
fi
;; #(
  /*)
-- 
2.39.2

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

[Richard Purdie]

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

Sorry.

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

Yes. There was talk of a 'read from file' version but that doesn't look
like it was merged anywhere.

> so we'd want to put a = before the glob at the end ?

Sure. I'll also add profile-prefix-map for completeness since it looks
like the naming debate was settled on that one and it was merged (I
personally don't need it).

Cheers,

Richard

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

[Roumen Petrov]

Hi Bruno,

Bruno Haible wrote:

Roumen Petrov wrote:

Android and Microsoft windows must not encode any paths.


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

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


RUNPATH or another section.
So far so good but not all loaders support all features elf format.
You cannot use one particular sample to dictate for all others.

On top of this run-paths are again rules on some above mentioned OS-es.
On those operation system shared libraries could be installed anywhere.





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


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


There is nothing related to the way how binaries are created by high level 
build environment.
You cannot dictated how to build binaries. I use standard build provided by 
project.

This is reason do not understand you point here. You environment is with 
"hard-coded" paths. I mean at least prefix.

I cannot understand why you build does not use -Xlinker (please check libtool 
documentation for exact name) to specify run-time paths.
You environment is specific and does not fulfill Android requirements.

Libtool is general purpose build system and so must follow OS-requirement.
General build system cannot follow wish list of a developer in environment with 
hard-coded locations.
This is reason Termux application to fail to run in other Android profile.

Termux is a good sample for broken Android application.
Libtool must not follow builds in environment broken by design.





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


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


Related to functionality supported by Android loader.
If you would like to distribute binaries clean of some section is strongly 
recommended.

But if build is for fun please pass to the linker specific paths.
As pointed above you environment is with hard-coded location i.e., it is easy 
to set linker options.



Bruno



Roumen

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

[Roumen Petrov]

Hi All,

Mike Frysinger wrote:

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

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

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

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


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

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


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


May be issues is from cygwin build environment.


-mike


Regards,
Roumen

[PATCH] libtool.m4: drop AC_PROG_SED fallback

[Mike Frysinger]

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

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

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

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

[Roumen Petrov]

Hi All

Mike Frysinger wrote:

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

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

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

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


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

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


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


Regards,
Roumen Petrov

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

[Mike Frysinger]

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


signature.asc
Description: PGP signature

[patch #9086] Fix support for Solaris 11 build

[Mike Frysinger]

Update of patch#9086 (group libtool):

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

___

Follow-up Comment #1:

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

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


___

Reply to this item at:

  

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

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

[Mike Frysinger]

On 16 Jan 2024 12:21, Richard Purdie wrote:
> On Mon, 2024-01-15 at 20:08 -0500, Mike Frysinger wrote:
> > On 25 Oct 2021 15:33, Richard Purdie wrote:
> > > This patch renames the --with-sysroot option to --with-libtool-sysroot
> > > to avoid namespace conflict with binutils, gcc and other toolchain
> > > components since these componets also add that option to configure
> > > and this becomes confusing and conflicting otherwise.
> > 
> > we're talking like 3 projects ?  libtool is used & included in way more
> > projects than that.  it seems like --with-sysroot as a standard name to
> > propagate out into the wider ecosystem makes more sense.
> 
> You're saying binutils and gcc should change? I'm fairly sure they'll
> decline to do that. Their options are encoded into quite a few cross
> compiling documents and build systems.

and there are even more packages out there using libtool.

these are all GNU projects working in the toolchain space to make the GNU
system coherent & better under the FSF.  it is not one GNU project working
in isolation and not caring about anyone else.  decisions should be made
with the long term outlook in mind, especially when we aren't talking about
runtime ABI that would break/blow up everywhere.  these are development and
build scripts ... they aren't immutable.

> > i agree there's confusion between "use this path as a sysroot to compile
> > and link against" and "have the compile tools target this sysroot".  the
> > same problem exists with host selection which is why we have the build,
> > host, and target options.  sounds like we want names that can align with
> > these somehow.
> 
> FWIW gcc and binutils have gone with --with-sysroot and --with-build-
> sysroot to differentiate. Unfortunately that doesn't really help
> libtool (see below).

i would argue --with-build-sysroot is not aligned with the other conventions
used in configure scripts.
https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.72/html_node/Hosts-and-Cross_002dCompilation.html

--build is the system doing the compilation and controls settings for the
build tools themselves, not for the toolchain specified via --host.  instead
the "host" part is omitted since it's the default.  c.f. BUILD_CC & CC,
BUILD_CFLAGS & CFLAGS, etc...

which makes --with-sysroot the original sin as it fills that gap already.
which is how libtool is using it now.

really it seems like --with-sysroot should be renamed to --with-target-sysroot
since it's controlling the target output behavior ... which is what gcc et al
already use --target for.  you can see that with the various libs it builds
and the use of xxx_FOR_TARGET variables.

ignoring the mismatch in conventions, i can't say that i would see much use
of a sysroot setting for the build tools themselves, so it isn't like gcc
has squatted in a space that would cause issues.  although that kind of
thinking is why we're in this situation in the first place.

> > --with-libtool-sysroot doesn't make sense as it isn't an internal libtool
> > setting, it's changing how executables are linked, and users (who run the
> > configure scripts) don't know or care about this "libtool" thing.
> 
> I think it partly depends upon how you view it. Most of the time
> libtool uses `$CC --print-sysroot` to set this and therefore most users
> wouldn't use the commandline option. In general you do want the
> compiler/linker and libtool to be working the same way.
> 
> The challenge is that binutils/gcc and libtool have adopted different
> meanings for the same option and if/as/where the commandline options
> get passed around, things can become quite broken when cross compiling.

i understand the conflict, and how it only applies to building the toolchain
source projects (gcc and its downstream like binutils & gdb).

> My ask is to try and find a way to avoid the confusion (and the need
> for Yocto Project to have to patch one set of components to make things
> work).
> 
> The options as I see it are:
> 
> a) Use a libtool specific option (as per the patch under review)

no.  libtool is an internal implementation detail.  there should be no
exposure/leakage of the name to people configuring+building.  it's like
saying we should call --with-pic --with-libtool-pic because it's libtool
creating the position independent code.

> b) Stop providing a commandline option for libtool and rely on the
> compiler query.

no, it is in active use as intended already.  this is like saying most
people don't set LDFLAGS, so just delete it.  while it's uncommon, it can
serve a pretty critical and irreplaceable function.

> c) Switch to --with-build-sysroot

not the worst option, but certainly not preferable as outlined above.

> d) Switch to --sysroot

does not align with GNU standards on naming.
https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.72/html_node/External-Software.html

> e) Ask gcc/binutils to change

in the immortal words of Michael Bolton,
"Why should I change?  

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

[Mike Frysinger]

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

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

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


signature.asc
Description: PGP signature

[PATCH] HACKING: minor formatting tweaks

[Mike Frysinger]

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

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

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

[Sam James]

Richard Purdie  writes:

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

Thanks, I was planning on sending this one too.

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

Re: pass_all for z/OS

[Mike Frysinger]

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

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

the first version did:
openedition)

the new one does:
*openedition*)

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


signature.asc
Description: PGP signature

RE: pass_all for z/OS

[Igor Todorovski]

Hi Mike,

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

Thanks,
Igor

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

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



zos.patch
Description: zos.patch

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

[Mike Frysinger]

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

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

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


signature.asc
Description: PGP signature

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

[Brad Smith]

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

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

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

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

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

[Mike Frysinger]

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

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

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

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

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

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

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


signature.asc
Description: PGP signature

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

[Mike Frysinger]

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

merged, thx
-mike


signature.asc
Description: PGP signature

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

[Mike Frysinger]

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

merged, thx
-mike


signature.asc
Description: PGP signature

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

[Mike Frysinger]

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

let's leave unrelated changes out please

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

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


signature.asc
Description: PGP signature

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

[Mike Frysinger]

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

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


signature.asc
Description: PGP signature

[PATCH] bootstrap: sync to latest version

[Mike Frysinger]

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

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

Re: [PATCH 1/3] Fix typos

[Mike Frysinger]

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

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


signature.asc
Description: PGP signature

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

[Bruno Haible]

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

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

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

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

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

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

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

Bruno

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

Re: [PATCH 1/3] Fix typos

[Mike Frysinger]

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


signature.asc
Description: PGP signature

[PATCH] cfg.mk: update old NEWS hash

[Mike Frysinger]

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

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

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

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

[Mike Frysinger]

From: Antonin D??cimo 

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

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

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

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

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

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

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

[Richard Purdie]

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

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

Cheers,

Richard

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

[Richard Purdie]

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

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

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

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

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

[Brad Smith]

libtool: remove OpenBSD specific performance hack for ranlib

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

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

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

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

[Roumen Petrov]

Bruno Haible wrote:

Roumen Petrov wrote:

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


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


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


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

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


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

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


Roumen

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

[Bruno Haible]

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

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

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

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

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

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

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

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

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

Bruno

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

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

[Mike Frysinger]

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

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

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

[Roumen Petrov]

Hi,


Mike Frysinger wrote:

Update of patch#9442 (group libtool):

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

 ___

Follow-up Comment #1:

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


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

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

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

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





Regards,
Roumen Petrov

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

[Roumen Petrov]

Hi,


Richard Purdie wrote:

[SNIP]
FWIW gcc and binutils have gone with --with-sysroot and --with-build-
sysroot to differentiate. Unfortunately that doesn't really help
libtool (see below).


Sure but we when use libtool argument --with-sysroot we expect to work as is 
designed and documented .


--with-libtool-sysroot doesn't make sense as it isn't an internal libtool
setting, it's changing how executables are linked, and users (who run the
configure scripts) don't know or care about this "libtool" thing.

I think it partly depends upon how you view it. Most of the time
libtool uses `$CC --print-sysroot` to set this and therefore most users
wouldn't use the commandline option. In general you do want the
compiler/linker and libtool to be working the same way.

Hmm If I remember well this is GCC specific option.
Android does not use GCC i.e., it cannot find default paths.
More over include and library directories are different i.e. option does not 
make sense for Android cross-builds.
Remark: --with-sysroot should point to "library" in my cross-builds and another 
way is used to specify paths to headers.


[SNIP]

Regards,
Roumen

Re: [PATCH] libtool: remove bitrig support.

[Mike Frysinger]

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

pushed, thanks
-mike


signature.asc
Description: PGP signature

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

[Roumen Petrov]

Hi All

Information below is not enough to understand details.

Richard Purdie wrote:

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

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

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


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

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

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


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



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

I meant the runtime linker/loader ld.so.


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

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

Cheers,

Richard


Regards,
Roumen Petrov

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

[Roumen Petrov]

Hello,

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

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


Ileana Dumitrescu wrote:

Update of patch#10393 (group libtool):

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



[SNIP]

Regards,
Roumen Petrov

[patch #10417] Avoid deprecation warning with MSVC

[Ileana Dumitrescu]

Update of patch#10417 (group libtool):

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

___

Follow-up Comment #1:

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


___

Reply to this item at:

  

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

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

[Ileana Dumitrescu]

Update of patch#10411 (group libtool):

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

___

Follow-up Comment #1:

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


___

Reply to this item at:

  

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

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

[Richard Purdie]

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

I meant the runtime linker/loader ld.so.

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

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

Cheers,

Richard

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

[Richard Purdie]

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

Add these to the list of options libtool passes through.

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

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

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

[Richard Purdie]

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

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

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

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

[Richard Purdie]

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

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

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

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

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

[KO Myung-Hun]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi/2.

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

Another try.

- -- 
KO Myung-Hun

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

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

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

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

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

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

[Antonin Décimo]

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

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

[patch #10393] Fix shared library support on Android

[Ileana Dumitrescu]

Update of patch#10393 (group libtool):

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

___

Follow-up Comment #1:

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


___

Reply to this item at:

  

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

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

[Richard Purdie]

Somehow my original reply ended up blank, sorry. I've retyped it from
memory as best I can.

On Mon, 2024-01-15 at 20:08 -0500, Mike Frysinger wrote:
> On 25 Oct 2021 15:33, Richard Purdie wrote:
> > This patch renames the --with-sysroot option to --with-libtool-sysroot
> > to avoid namespace conflict with binutils, gcc and other toolchain
> > components since these componets also add that option to configure
> > and this becomes confusing and conflicting otherwise.
> 
> we're talking like 3 projects ?  libtool is used & included in way more
> projects than that.  it seems like --with-sysroot as a standard name to
> propagate out into the wider ecosystem makes more sense.

You're saying binutils and gcc should change? I'm fairly sure they'll
decline to do that. Their options are encoded into quite a few cross
compiling documents and build systems.

> i agree there's confusion between "use this path as a sysroot to compile
> and link against" and "have the compile tools target this sysroot".  the
> same problem exists with host selection which is why we have the build,
> host, and target options.  sounds like we want names that can align with
> these somehow.

FWIW gcc and binutils have gone with --with-sysroot and --with-build-
sysroot to differentiate. Unfortunately that doesn't really help
libtool (see below).

> --with-libtool-sysroot doesn't make sense as it isn't an internal libtool
> setting, it's changing how executables are linked, and users (who run the
> configure scripts) don't know or care about this "libtool" thing.

I think it partly depends upon how you view it. Most of the time
libtool uses `$CC --print-sysroot` to set this and therefore most users
wouldn't use the commandline option. In general you do want the
compiler/linker and libtool to be working the same way.

The challenge is that binutils/gcc and libtool have adopted different
meanings for the same option and if/as/where the commandline options
get passed around, things can become quite broken when cross compiling.

My ask is to try and find a way to avoid the confusion (and the need
for Yocto Project to have to patch one set of components to make things
work).

The options as I see it are:

a) Use a libtool specific option (as per the patch under review)

b) Stop providing a commandline option for libtool and rely on the
compiler query.

c) Switch to --with-build-sysroot

d) Switch to --sysroot

e) Ask gcc/binutils to change


I can't see gcc/binutils changing. Using c/d would likely have a
different set of issues. For example in some cases you do want the
build sysroot and sometimes the target with libtool so c swaps one set
of problems for another. 

Since most of the time users never need to care about setting this
option and we couldn't find an alternative, changing it as per the
patch seemed like the least worst solution and  was why we end up with
a).

Would:

--with-sysroot-libtool

be any better?

I'm open to other ideas.

Cheers,

Richard

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

[Richard Purdie]

[PATCH] libtool: remove bitrig support.

[Brad Smith]

libtool: remove bitrig support.

Bitrig has been defunct for 7 years.

* build-aux/ltmain.in (func_mode_link): Remove bitrig support.
* m4/libtool.m4 (_LT_CMD_OLD_ARCHIVE, LT_CMD_MAX_LEN)
(_LT_SYS_DYNAMIC_LINKER, _LT_CHECK_MAGIC_METHOD)
(_LT_LINKER_SHLIBS, _LT_LANG_CXX_CONFIG): Ditto.
* m4/ltdl.m4 (LT_SYS_DLOPEN_DEPLIBS): Ditto.
* NEWS: Updated.
---
 NEWS|  3 +++
 build-aux/ltmain.in |  4 ++--
 m4/libtool.m4   | 14 +++---
 m4/ltdl.m4  |  3 ---
 4 files changed, 12 insertions(+), 12 deletions(-)

diff --git a/NEWS b/NEWS
index 93ade4df..79f135a2 100644
--- a/NEWS
+++ b/NEWS
@@ -2,6 +2,9 @@ NEWS - list of user-visible changes between releases of GNU 
Libtool
 
 * Noteworthy changes in release ?.? (-??-??) [?]
 
+** Changes in supported systems or compilers:
+
+  - Removed support for bitrig.
 
 * Noteworthy changes in release 2.4.7 (2022-03-16) [stable]
 
diff --git a/build-aux/ltmain.in b/build-aux/ltmain.in
index d5157a8d..d996f798 100644
--- a/build-aux/ltmain.in
+++ b/build-aux/ltmain.in
@@ -5134,7 +5134,7 @@ func_mode_link ()
# These systems don't actually have a C library (as such)
test X-lc = "X$arg" && continue
;;
- *-*-openbsd* | *-*-freebsd* | *-*-dragonfly* | *-*-bitrig* | 
*-*-midnightbsd*)
+ *-*-openbsd* | *-*-freebsd* | *-*-dragonfly* | *-*-midnightbsd*)
# Do not include libc due to us having libc/libc_r.
test X-lc = "X$arg" && continue
;;
@@ -5154,7 +5154,7 @@ func_mode_link ()
  esac
elif test X-lc_r = "X$arg"; then
 case $host in
-*-*-openbsd* | *-*-freebsd* | *-*-dragonfly* | *-*-bitrig* | 
*-*-midnightbsd*)
+*-*-openbsd* | *-*-freebsd* | *-*-dragonfly* | *-*-midnightbsd*)
   # Do not include libc_r directly, use -pthread flag.
   continue
   ;;
diff --git a/m4/libtool.m4 b/m4/libtool.m4
index 695ccac4..9b1a4d81 100644
--- a/m4/libtool.m4
+++ b/m4/libtool.m4
@@ -1556,7 +1556,7 @@ old_postuninstall_cmds=
 
 if test -n "$RANLIB"; then
   case $host_os in
-  bitrig* | openbsd*)
+  openbsd*)
 old_postinstall_cmds="$old_postinstall_cmds~\$RANLIB -t \$tool_oldlib"
 ;;
   *)
@@ -1724,7 +1724,7 @@ AC_CACHE_VAL([lt_cv_sys_max_cmd_len], [dnl
 lt_cv_sys_max_cmd_len=8192;
 ;;
 
-  bitrig* | darwin* | dragonfly* | freebsd* | midnightbsd* | netbsd* | 
openbsd*)
+  darwin* | dragonfly* | freebsd* | midnightbsd* | netbsd* | openbsd*)
 # This has been around since 386BSD, at least.  Likely further.
 if test -x /sbin/sysctl; then
   lt_cv_sys_max_cmd_len=`/sbin/sysctl -n kern.argmax`
@@ -2943,7 +2943,7 @@ newsos6)
   dynamic_linker='ldqnx.so'
   ;;
 
-openbsd* | bitrig*)
+openbsd*)
   version_type=sunos
   sys_lib_dlsearch_path_spec=/usr/lib
   need_lib_prefix=no
@@ -3583,7 +3583,7 @@ newos6*)
   lt_cv_deplibs_check_method=pass_all
   ;;
 
-openbsd* | bitrig*)
+openbsd*)
   if test -z "`echo __ELF__ | $CC -E - | $GREP __ELF__`"; then
 lt_cv_deplibs_check_method='match_pattern 
/lib[[^/]]+(\.so\.[[0-9]]+\.[[0-9]]+|\.so|_pic\.a)$'
   else
@@ -5020,7 +5020,7 @@ dnl Note also adjust exclude_expsyms for C++ above.
 # we just hope/assume this is gcc and not c89 (= MSVC++ or ICC)
 with_gnu_ld=yes
 ;;
-  openbsd* | bitrig*)
+  openbsd*)
 with_gnu_ld=no
 ;;
   esac
@@ -5842,7 +5842,7 @@ _LT_EOF
 *nto* | *qnx*)
   ;;
 
-openbsd* | bitrig*)
+openbsd*)
   if test -f /usr/libexec/ld.so; then
_LT_TAGVAR(hardcode_direct, $1)=yes
_LT_TAGVAR(hardcode_shlibpath_var, $1)=no
@@ -7136,7 +7136,7 @@ if test yes != "$_lt_caught_CXX_error"; then
 _LT_TAGVAR(ld_shlibs, $1)=yes
;;
 
-  openbsd* | bitrig*)
+  openbsd*)
if test -f /usr/libexec/ld.so; then
  _LT_TAGVAR(hardcode_direct, $1)=yes
  _LT_TAGVAR(hardcode_shlibpath_var, $1)=no
diff --git a/m4/ltdl.m4 b/m4/ltdl.m4
index f631a00c..0c43799c 100644
--- a/m4/ltdl.m4
+++ b/m4/ltdl.m4
@@ -466,9 +466,6 @@ AC_CACHE_CHECK([whether deplibs are loaded by dlopen],
   ;;
 esac
 ;;
-  bitrig*)
-lt_cv_sys_dlopen_deplibs=yes
-;;
   darwin*)
 # Assuming the user has installed a libdl from somewhere, this is true
 # If you are looking for one http://www.opendarwin.org/projects/dlcompat
-- 
2.43.0

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

[Mike Frysinger]

On 25 Oct 2021 15:33, Richard Purdie wrote:
> We don't want to add RPATHS which match default linker search paths, they're
> a waste of space. This patch filters libtools list of paths to encoode and
> removes the ones we don't need.

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

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


signature.asc
Description: PGP signature

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

[Mike Frysinger]

On 25 Oct 2021 15:33, Richard Purdie wrote:
> This patch renames the --with-sysroot option to --with-libtool-sysroot
> to avoid namespace conflict with binutils, gcc and other toolchain
> components since these componets also add that option to configure
> and this becomes confusing and conflicting otherwise.

we're talking like 3 projects ?  libtool is used & included in way more
projects than that.  it seems like --with-sysroot as a standard name to
propagate out into the wider ecosystem makes more sense.

i agree there's confusion between "use this path as a sysroot to compile
and link against" and "have the compile tools target this sysroot".  the
same problem exists with host selection which is why we have the build,
host, and target options.  sounds like we want names that can align with
these somehow.

--with-libtool-sysroot doesn't make sense as it isn't an internal libtool
setting, it's changing how executables are linked, and users (who run the
configure scripts) don't know or care about this "libtool" thing.
-mike


signature.asc
Description: PGP signature

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

[Mike Frysinger]

On 25 Oct 2021 15:33, Richard Purdie wrote:
> Update libtool.m4 to resolve a problem with lt_sysroot not being properly
> updated if the option '--with[-libtool]-sysroot' is not provided when
> running the 'configure' script for a package so that "/" as a sysroot
> is handled correctly by libtool.

this is a long sentence, and there's no concrete examples, so i'm having a
bit of trouble extrapolating the bug.  can you tweak this a bit to make it
more clear ?
-mike


signature.asc
Description: PGP signature

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

[Mike Frysinger]

On 25 Oct 2021 15:33, Richard Purdie wrote:
> +  # -f*-prefix-map*  needed for lto linking

what flags are you trying to actually match here ?  excessive globs
make it more likely to match flags we don't want.
-mike


signature.asc
Description: PGP signature

Re: [PATCH 00/12] Yocto Project libtool patch queue

[Mike Frysinger]

there's a bunch of changes in here, but no additional test coverage

also the project still requires ChangeLog entries in the commit message,
so can you please add those so we don't have to write them for you ?  if
you look at commit history, the format should hopefully be obvious.
-mike


signature.asc
Description: PGP signature

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

[Mike Frysinger]

On 25 Oct 2021 15:33, Richard Purdie wrote:
> The name of the system contains the string "nios2". This string
> is caught by the some of the greedy checks for OS/2 in libtool,
> in particular the *os2* branches of switch statements match for
> the nios2 string, which results in incorrect behavior of libtool.
> 
> This patch adds an explicit check for *nios2* before the *os2*
> checks to prevent the OS/2 check incorrectly trapping the nios2
> as well.

i don't think this is the right approach.  this is adding another substring
search across the entire space (cpu/vendor/os).  we should fix the search so
it uses the right value only to match against.

> --- a/build-aux/ltmain.in
> +++ b/build-aux/ltmain.in
>
>  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*)

these should only match $host_os, and remove the leading glob at the same time.
same for the other changes in this patch.
-mike


signature.asc
Description: PGP signature

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

[Mike Frysinger]

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

it passes configure, but fails `make check` & `make syntax-check`.
-mike


signature.asc
Description: PGP signature