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

[Olly Betts]

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

It looks like that patch was merged in 2021
(9e8c882517082fe5755f2524d23efb02f1522490) and was included in libtool 2.4.7.


___

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

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

[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] 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

[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] libtool: passthru '-shared-libsan' and '-static-libsan' flags

[Mike Frysinger]

On 21 May 2023 20:28, Dmitry Antipov wrote:
> * build-aux/ltmain.in: Pass '-shared-libsan' and '-static-libsan'
>   flags when linking.
> 
> This is intented to link against shared and static sanitizer
> runtimes with Clang.

thx, merged now
-mike


signature.asc
Description: PGP signature

Re: [PATCH] libtool: remove stray \ before -

[Mike Frysinger]

On 14 Sep 2022 00:10, jspri...@debian.org wrote:
> From: Jochen Sprickerhof 
> 
> grep 3.8 emits a warning for this.

thanks for the patch ... we merged fixed from Paul via
https://savannah.gnu.org/patch/index.php?10282
-mike


signature.asc
Description: PGP signature

[PATCH] libtool: passthru '-shared-libsan' and '-static-libsan' flags

[Dmitry Antipov]

* build-aux/ltmain.in: Pass '-shared-libsan' and '-static-libsan'
  flags when linking.

This is intented to link against shared and static sanitizer
runtimes with Clang.

Signed-off-by: Dmitry Antipov 
---
 build-aux/ltmain.in | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/build-aux/ltmain.in b/build-aux/ltmain.in
index 3b76bd08..1e5f0559 100644
--- a/build-aux/ltmain.in
+++ b/build-aux/ltmain.in
@@ -5406,13 +5406,16 @@ func_mode_link ()
   # -specs=* GCC specs files
   # -stdlib=*select c++ std lib with clang
   # -fsanitize=* Clang/GCC memory and address sanitizer
+  # -shared-libsan   Link with shared sanitizer runtimes (Clang)
+  # -static-libsan   Link with static sanitizer runtimes (Clang)
   # -fuse-ld=*   Linker select flags for GCC
   # -Wa,*Pass flags directly to the assembler
   # -Werror, -Werror=*   Report (specified) warnings as errors
   -64|-mips[0-9]|-r[0-9][0-9]*|-xarch=*|-xtarget=*|+DA*|+DD*|-q*|-m*| \
   
-t[45]*|-txscale*|-p|-pg|--coverage|-fprofile-*|-F*|@*|-tp=*|--sysroot=*| \
   
-O*|-g*|-flto*|-fwhopr*|-fuse-linker-plugin|-fstack-protector*|-stdlib=*| \
-  -specs=*|-fsanitize=*|-fuse-ld=*|-Wa,*|-Werror|-Werror=*)
+  -specs=*|-fsanitize=*|-shared-libsan|-static-libsan|-fuse-ld=*|-Wa,*| \
+  -Werror|-Werror=*)
 func_quote_arg pretty "$arg"
arg=$func_quote_arg_result
 func_append compile_command " $arg"
-- 
2.40.1

[PATCH] libtool: passthru '-shared-libsan' flag

[Dmitry Antipov]

* build-aux/ltmain.in: Pass '-shared-libsan' flags when linking.

This is intented to link shared libraries against
sanitizer runtimes with Clang.

Signed-off-by: Dmitry Antipov 
---
 build-aux/ltmain.in | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/build-aux/ltmain.in b/build-aux/ltmain.in
index 3b76bd08..2df29a18 100644
--- a/build-aux/ltmain.in
+++ b/build-aux/ltmain.in
@@ -5406,13 +5406,14 @@ func_mode_link ()
   # -specs=* GCC specs files
   # -stdlib=*select c++ std lib with clang
   # -fsanitize=* Clang/GCC memory and address sanitizer
+  # -shared-libsan   Link shared libraries with sanitizer runtimes 
(Clang)
   # -fuse-ld=*   Linker select flags for GCC
   # -Wa,*Pass flags directly to the assembler
   # -Werror, -Werror=*   Report (specified) warnings as errors
   -64|-mips[0-9]|-r[0-9][0-9]*|-xarch=*|-xtarget=*|+DA*|+DD*|-q*|-m*| \
   
-t[45]*|-txscale*|-p|-pg|--coverage|-fprofile-*|-F*|@*|-tp=*|--sysroot=*| \
   
-O*|-g*|-flto*|-fwhopr*|-fuse-linker-plugin|-fstack-protector*|-stdlib=*| \
-  -specs=*|-fsanitize=*|-fuse-ld=*|-Wa,*|-Werror|-Werror=*)
+  -specs=*|-fsanitize=*|-shared-libsan|-fuse-ld=*|-Wa,*|-Werror|-Werror=*)
 func_quote_arg pretty "$arg"
arg=$func_quote_arg_result
 func_append compile_command " $arg"
-- 
2.40.1

[PATCH] libtool

[Yash Shinde]

From: Khem Raj 

libstdc++ from gcc-runtime gets created with -rpath=/usr/lib/../lib for 
qemux86-64
when running on am x86_64 build host.

This patch stops this speading to libdir in the libstdc++.la file within 
libtool.
Arguably, it shouldn't be passing this into libtool in the first place but
for now this resolves the nastiest problems this causes.

func_normal_abspath would resolve an empty path to `pwd` so we need
to filter the zero case.

Signed-off-by: Khem Raj 
Signed-off-by: Yash Shinde 
---
 ltmain.sh | 4 
 1 file changed, 4 insertions(+)

diff --git a/ltmain.sh b/ltmain.sh
index 70990740b6c..a5bb36a364e 100644
--- a/ltmain.sh
+++ b/ltmain.sh
@@ -6359,6 +6359,10 @@ func_mode_link ()
func_warning "ignoring multiple \`-rpath's for a libtool library"
 
   install_libdir="$1"
+  if test -n "$install_libdir"; then
+   func_normal_abspath "$install_libdir"
+   install_libdir=$func_normal_abspath_result
+  fi
 
   oldlibs=
   if test -z "$rpath"; then
-- 
2.34.1

[PATCH] libtool: remove stray \ before -

[jspricke]

From: Jochen Sprickerhof 

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

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

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

[Alex Ameen]

Update of patch #9996 (project libtool):

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


___

Reply to this item at:

  

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

[PATCH] libtool with mingw hangs in func_convert_core_msys_to_w32

[Brian Inglis]

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

libtool with mingw hangs building openocd in
func_convert_core_msys_to_w32:

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

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

( cmd //c echo "$1" )

see:

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

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

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

C:\...>exit
$

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

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

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

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

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

[FX]

URL:
  <https://savannah.gnu.org/patch/?9996>

 Summary: Patch libtool for macOS 11.0 (aka darwin20)
 Project: GNU Libtool
Submitted by: fxcoudert
Submitted on: Mon 16 Nov 2020 03:22:20 PM UTC
Category: None
Priority: 5 - Normal
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any

___

Details:

There is code in m4/libtool.m4 that assumes that macOS version numbers are of
the form 10.*, and darwin version numbers are of the form darwin1*

The latest macOS release is macOS 11.0.1 and it corresponds to the darwin20
kernel. So, this code breaks.

The patch at
https://lists.gnu.org/archive/html/libtool-patches/2020-06/msg1.html
is confirmed to work very well, allowing to build complex software that was
failing before, such as open-mpi.

Please apply this patch to git




___

Reply to this item at:

  <https://savannah.gnu.org/patch/?9996>

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

[PATCH] libtool: use $PATH_SEPARATOR instead ':'

[KO Myung-Hun]

On OS/2, a path separator is ';' not ':'. So use $PATH_SEPARATOR.

* build-aux/ltmain.in (func_exec_program) [shlibpath_var]:
Replace ':' with $PATH_SEPARATOR.
(func_mode_link) [shlib_search_path]: Likewise.
* m4/libtool.m4 (func_munge_path_list): Likewise.
---
 build-aux/ltmain.in |  4 ++--
 m4/libtool.m4   | 16 
 2 files changed, 10 insertions(+), 10 deletions(-)

diff --git a/build-aux/ltmain.in b/build-aux/ltmain.in
index 96b37003..46ddb6d1 100644
--- a/build-aux/ltmain.in
+++ b/build-aux/ltmain.in
@@ -3587,7 +3587,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
 "
@@ -5563,7 +5563,7 @@ func_mode_link ()
 
 if test -n "$shlibpath_var"; then
   # get the directories listed in $shlibpath_var
-  eval shlib_search_path=\`\$ECHO \"\$$shlibpath_var\" \| \$SED \'s/:/ 
/g\'\`
+  eval shlib_search_path=\`\$ECHO \"\$$shlibpath_var\" \| \$SED 
\'s/$PATH_SEPARATOR/ /g\'\`
 else
   shlib_search_path=
 fi
diff --git a/m4/libtool.m4 b/m4/libtool.m4
index f2d1f398..684c2256 100644
--- a/m4/libtool.m4
+++ b/m4/libtool.m4
@@ -2278,18 +2278,18 @@ func_munge_path_list ()
 case x@S|@2 in
 x)
 ;;
-*:)
-eval @S|@1=\"`$ECHO @S|@2 | $SED 's/:/ /g'` \@S|@@S|@1\"
+*$PATH_SEPARATOR)
+eval @S|@1=\"`$ECHO @S|@2 | $SED 's/'$PATH_SEPARATOR'/ /g'` 
\@S|@@S|@1\"
 ;;
-x:*)
-eval @S|@1=\"\@S|@@S|@1 `$ECHO @S|@2 | $SED 's/:/ /g'`\"
+x$PATH_SEPARATOR*)
+eval @S|@1=\"\@S|@@S|@1 `$ECHO @S|@2 | $SED 's/'$PATH_SEPARATOR'/ 
/g'`\"
 ;;
-*::*)
-eval @S|@1=\"\@S|@@S|@1\ `$ECHO @S|@2 | $SED -e 's/.*:://' -e 's/:/ 
/g'`\"
-eval @S|@1=\"`$ECHO @S|@2 | $SED -e 's/::.*//' -e 's/:/ /g'`\ 
\@S|@@S|@1\"
+*$PATH_SEPARATOR$PATH_SEPARATOR*)
+eval @S|@1=\"\@S|@@S|@1\ `$ECHO @S|@2 | $SED -e 
's/.*'$PATH_SEPARATOR$PATH_SEPARATOR'//' -e 's/'$PATH_SEPARATOR'/ /g'`\"
+eval @S|@1=\"`$ECHO @S|@2 | $SED -e 
's/'$PATH_SEPARATOR$PATH_SEPARATOR'.*//' -e 's/'$PATH_SEPARATOR'/ /g'`\ 
\@S|@@S|@1\"
 ;;
 *)
-eval @S|@1=\"`$ECHO @S|@2 | $SED 's/:/ /g'`\"
+eval @S|@1=\"`$ECHO @S|@2 | $SED 's/'$PATH_SEPARATOR'/ /g'`\"
 ;;
 esac
 }
-- 
2.22.0

[PATCH] libtool: consistently pass compiler_flags for darwin

[Carl Dong]

This fixes clang cross-compilations targeting darwin where if we don't
pass compiler_flags to clang, it assumes it's compiling for the host and
will fail to link with a "file format not recognized" error.

* m4/libtool.m4 (_LT_DARWIN_LINKER_FEATURES): Pass compiler_flags to
partial linking commands.
---
 m4/libtool.m4 | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/m4/libtool.m4 b/m4/libtool.m4
index f2d1f398..1e6a6c87 100644
--- a/m4/libtool.m4
+++ b/m4/libtool.m4
@@ -1130,8 +1130,8 @@ m4_defun([_LT_DARWIN_LINKER_FEATURES],
 _LT_TAGVAR(module_expsym_cmds, $1)="sed -e 's|^|_|' < \$export_symbols > 
\$output_objdir/\$libname-symbols.expsym~\$CC \$allow_undefined_flag -o \$lib 
-bundle \$libobjs \$deplibs \$compiler_flags$_lt_dar_export_syms$_lt_dsymutil"
 m4_if([$1], [CXX],
 [   if test yes != "$lt_cv_apple_cc_single_mod"; then
-  _LT_TAGVAR(archive_cmds, $1)="\$CC -r -keep_private_externs -nostdlib -o 
\$lib-master.o \$libobjs~\$CC -dynamiclib \$allow_undefined_flag -o \$lib 
\$lib-master.o \$deplibs \$compiler_flags -install_name \$rpath/\$soname 
\$verstring$_lt_dsymutil"
-  _LT_TAGVAR(archive_expsym_cmds, $1)="sed 's|^|_|' < \$export_symbols > 
\$output_objdir/\$libname-symbols.expsym~\$CC -r -keep_private_externs 
-nostdlib -o \$lib-master.o \$libobjs~\$CC -dynamiclib \$allow_undefined_flag 
-o \$lib \$lib-master.o \$deplibs \$compiler_flags -install_name 
\$rpath/\$soname \$verstring$_lt_dar_export_syms$_lt_dsymutil"
+  _LT_TAGVAR(archive_cmds, $1)="\$CC -r -keep_private_externs -nostdlib -o 
\$lib-master.o \$libobjs \$compiler_flags~\$CC -dynamiclib 
\$allow_undefined_flag -o \$lib \$lib-master.o \$deplibs \$compiler_flags 
-install_name \$rpath/\$soname \$verstring$_lt_dsymutil"
+  _LT_TAGVAR(archive_expsym_cmds, $1)="sed 's|^|_|' < \$export_symbols > 
\$output_objdir/\$libname-symbols.expsym~\$CC -r -keep_private_externs 
-nostdlib -o \$lib-master.o \$libobjs \$compiler_flags~\$CC -dynamiclib 
\$allow_undefined_flag -o \$lib \$lib-master.o \$deplibs \$compiler_flags 
-install_name \$rpath/\$soname \$verstring$_lt_dar_export_syms$_lt_dsymutil"
 fi
 ],[])
   else
-- 
2.25.1

[PATCH] libtool: Cygwin does not use DOS based filesystem

[JonY]

Even though it runs on Windows, Cygwin uses UNIX paths.
The _WIN32 macro may still be defined when using Win32 APIs
however.

Signed-off-by: Jonathan Yong <10wa...@gmail.com>
---
 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 96b37003..3bb3043e 100644
--- a/build-aux/ltmain.in
+++ b/build-aux/ltmain.in
@@ -3711,8 +3711,8 @@ int setenv (const char *, const char *, int);
 # define PATH_SEPARATOR ':'
 #endif

-#if defined _WIN32 || defined __MSDOS__ || defined __DJGPP__ || \
-  defined __OS2__
+#if (defined _WIN32 && ! defined __CYGWIN__) || defined __MSDOS__ || \
+  defined __DJGPP__ || defined __OS2__
 # define HAVE_DOS_BASED_FILE_SYSTEM
 # define FOPEN_WB "wb"
 # ifndef DIR_SEPARATOR_2
-- 
2.26.1



signature.asc
Description: OpenPGP digital signature

[PATCH] libtool: ignore invalid C symbol names from MS dumpbin

[Michael Haubenwallner]

With 64bit MSVC cl.exe, and since VS 2012 even with 32bit, binary files
may contain (C)ommon symbols.  Their name likely is not valid to be used
as symbol name in the C programming language, and should be ignored in
the global symbol pipe.  This does fix test cases 27-29, 31-37 and 109.

* libtool.m4 (_LT_CMD_GLOBAL_SYMBOLS): For the global symbol pipe,
accept symbol names that are valid for the C language only.  And when
parsing MS dumpbin output, decorate symbols from section UNDEF but
nonzero value as (C)ommon instead of (D)ata, even if they likely are
ignored later on because of having an invalid C language symbol name.
---
 m4/libtool.m4 | 21 +++--
 1 file changed, 11 insertions(+), 10 deletions(-)

diff --git a/m4/libtool.m4 b/m4/libtool.m4
index 05bf608c..0d0280d2 100644
--- a/m4/libtool.m4
+++ b/m4/libtool.m4
@@ -3977,13 +3977,13 @@ esac
 
 if test "$lt_cv_nm_interface" = "MS dumpbin"; then
   # Gets list of data symbols to import.
-  lt_cv_sys_global_symbol_to_import="sed -n -e 's/^I .* \(.*\)$/\1/p'"
+  lt_cv_sys_global_symbol_to_import="sed -n -e 's/^I .* 
\([[a-zA-Z_]][[0-9a-zA-Z_]]*\)$/\1/p'"
   # Adjust the below global symbol transforms to fixup imported variables.
-  lt_cdecl_hook=" -e 's/^I .* \(.*\)$/extern __declspec(dllimport) char \1;/p'"
-  lt_c_name_hook=" -e 's/^I .* \(.*\)$/  {\"\1\", (void *) 0},/p'"
+  lt_cdecl_hook=" -e 's/^I .* \([[a-zA-Z_]][[0-9a-zA-Z_]]*\)$/extern 
__declspec(dllimport) char \1;/p'"
+  lt_c_name_hook=" -e 's/^I .* \([[a-zA-Z_]][[0-9a-zA-Z_]]*\)$/  {\"\1\", 
(void *) 0},/p'"
   lt_c_name_lib_hook="\
-  -e 's/^I .* \(lib.*\)$/  {\"\1\", (void *) 0},/p'\
-  -e 's/^I .* \(.*\)$/  {\"lib\1\", (void *) 0},/p'"
+  -e 's/^I .* \(lib[[a-zA-Z_]][[0-9a-zA-Z_]]*\)$/  {\"\1\", (void *) 0},/p'\
+  -e 's/^I .* \([[a-zA-Z_]][[0-9a-zA-Z_]]*\)$/  {\"lib\1\", (void *) 0},/p'"
 else
   # Disable hooks by default.
   lt_cv_sys_global_symbol_to_import=
@@ -3997,22 +3997,22 @@ fi
 # so use this general approach.
 lt_cv_sys_global_symbol_to_cdecl="sed -n"\
 $lt_cdecl_hook\
-" -e 's/^T .* \(.*\)$/extern int \1();/p'"\
-" -e 's/^$symcode$symcode* .* \(.*\)$/extern char \1;/p'"
+" -e 's/^T .* \([[a-zA-Z_]][[0-9a-zA-Z_]]*\)$/extern int \1();/p'"\
+" -e 's/^$symcode$symcode* .* \([[a-zA-Z_]][[0-9a-zA-Z_]]*\)$/extern char 
\1;/p'"
 
 # Transform an extracted symbol line into symbol name and symbol address
 lt_cv_sys_global_symbol_to_c_name_address="sed -n"\
 $lt_c_name_hook\
 " -e 's/^: \(.*\) .*$/  {\"\1\", (void *) 0},/p'"\
-" -e 's/^$symcode$symcode* .* \(.*\)$/  {\"\1\", (void *) \&\1},/p'"
+" -e 's/^$symcode$symcode* .* \([[a-zA-Z_]][[0-9a-zA-Z_]]*\)$/  {\"\1\", (void 
*) \&\1},/p'"
 
 # Transform an extracted symbol line into symbol name with lib prefix and
 # symbol address.
 lt_cv_sys_global_symbol_to_c_name_address_lib_prefix="sed -n"\
 $lt_c_name_lib_hook\
 " -e 's/^: \(.*\) .*$/  {\"\1\", (void *) 0},/p'"\
-" -e 's/^$symcode$symcode* .* \(lib.*\)$/  {\"\1\", (void *) \&\1},/p'"\
-" -e 's/^$symcode$symcode* .* \(.*\)$/  {\"lib\1\", (void *) \&\1},/p'"
+" -e 's/^$symcode$symcode* .* \(lib[[a-zA-Z_]][[0-9a-zA-Z_]]*\)$/  {\"\1\", 
(void *) \&\1},/p'"\
+" -e 's/^$symcode$symcode* .* \([[a-zA-Z_]][[0-9a-zA-Z_]]*\)$/  {\"lib\1\", 
(void *) \&\1},/p'"
 
 # Handle CRLF in mingw tool chain
 opt_cr=
@@ -4052,6 +4052,7 @@ for ac_symprfx in "" "_"; do
 " / 0+ UNDEF /{next}; / UNDEF \([^|]\)*()/{next};"\
 " {if(hide[section]) next};"\
 " {f=\"D\"}; \$ 0~/\(\).*\|/{f=\"T\"};"\
+" \$ 0~/ [0-9a-fA-F]*[1-9a-fA-F][0-9a-fA-F]* UNDEF /{f=\"C\"};"\
 " {split(\$ 0,a,/\||\r/); split(a[2],s)};"\
 " s[1]~/^[@?]/{print f,s[1],s[1]; next};"\
 " s[1]~prfx {split(s[1],t,\"@\"); print f,t[1],substr(t[1],length(prfx))}"\
-- 
2.21.0

[PATCH] libtool: fix data imports with GNU ld on 64bit windows

[Michael Haubenwallner]

Using '_nm__' to match symbols from GNU ld to enable special data import
treatment on windows targets does rely on the leading underscore being
stripped from the __nm_ prefix rather than the subsequent symbol name.
This does fail on 64bit Windows targets, because there is no leading
underscore with symbol names any more.

* m4/libtool.m4 (lt_cv_sys_global_symbol_pipe): Strip the leading
underscore, if any, from the symbol name that follows the optional
__imp_ or __nm_ prefix, rather than from that prefix.
* build-aux/ltmain.in (func_generate_dlsyms): Account for the global
symbol pipe leaving the __nm_ prefix intact now, but stripping the
leading underscore, if any, from the subsequent symbol name instead.
---
 build-aux/ltmain.in | 2 +-
 m4/libtool.m4   | 9 +++--
 2 files changed, 8 insertions(+), 3 deletions(-)

diff --git a/build-aux/ltmain.in b/build-aux/ltmain.in
index 96b37003..ad154fb8 100644
--- a/build-aux/ltmain.in
+++ b/build-aux/ltmain.in
@@ -2810,7 +2810,7 @@ extern \"C\" {
  fi
  func_to_tool_file "$dlprefile" func_convert_file_msys_to_w32
  eval "$NM \"$func_to_tool_file_result\" 2>/dev/null | 
$global_symbol_pipe |
-   $SED -e '/I __imp/d' -e 's/I __nm_/D /;s/_nm__//' >> 
'$nlist'"
+   $SED -e '/I __imp/d' -e 's/I __nm_/D /;s/ __nm_/ /' >> 
'$nlist'"
}
  else # not an import lib
$opt_dry_run || {
diff --git a/m4/libtool.m4 b/m4/libtool.m4
index 416ff1cc..05bf608c 100644
--- a/m4/libtool.m4
+++ b/m4/libtool.m4
@@ -4026,7 +4026,12 @@ esac
 for ac_symprfx in "" "_"; do
 
   # Transform symcode, sympat, and symprfx into a raw symbol and a C symbol.
-  symxfrm="\\1 $ac_symprfx\\2 \\2"
+  # In Windows import libraries, symbols may be prefixed with __imp_, as well
+  # as __nm_ when using GNU ld.  The leading underscore (in 32bit) comes after
+  # the __imp_ and __nm_ prefix, so make sure to strip the underscore from the
+  # symbol name instead of the __imp_ or __nm_ prefix, leaving these prefixes
+  # intact in the symbol pipe output.
+  symxfrm="\\1 \\2$ac_symprfx\\3 \\2\\3"
 
   # Write the raw and C identifiers.
   if test "$lt_cv_nm_interface" = "MS dumpbin"; then
@@ -4052,7 +4057,7 @@ for ac_symprfx in "" "_"; do
 " s[1]~prfx {split(s[1],t,\"@\"); print f,t[1],substr(t[1],length(prfx))}"\
 " ' prfx=^$ac_symprfx]"
   else
-lt_cv_sys_global_symbol_pipe="sed -n -e 's/^.*[[
]]\($symcode$symcode*\)[[   ]][[
]]*$ac_symprfx$sympat$opt_cr$/$symxfrm/p'"
+lt_cv_sys_global_symbol_pipe="sed -n -e 's/^.*[[
]]\($symcode$symcode*\)[[   ]][[
]]*\(__imp_\|__nm_\)\{0,1\}$ac_symprfx$sympat$opt_cr$/$symxfrm/p'"
   fi
   lt_cv_sys_global_symbol_pipe="$lt_cv_sys_global_symbol_pipe | sed '/ 
__gnu_lto/d'"
 
-- 
2.22.0

[PATCH] libtool: pass more flags to the linker

[Vincent Lefevre]

Resolves bug 17750.

* build-aux/ltmain.in (func_mode_link): In the flags to be passed through
unchanged, also pass -static-* and -fcilkplus.

Signed-off-by: Vincent Lefevre 
---
 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 96b37003..c0e925bb 100644
--- a/build-aux/ltmain.in
+++ b/build-aux/ltmain.in
@@ -5380,10 +5380,12 @@ func_mode_link ()
   # -stdlib=*select c++ std lib with clang
   # -fsanitize=* Clang/GCC memory and address sanitizer
   # -fuse-ld=*   Linker select flags for GCC
+  # -static-*direct GCC to link specific libraries statically
+  # -fcilkplus   Cilk Plus language extension features for C/C++
   -64|-mips[0-9]|-r[0-9][0-9]*|-xarch=*|-xtarget=*|+DA*|+DD*|-q*|-m*| \
   
-t[45]*|-txscale*|-p|-pg|--coverage|-fprofile-*|-F*|@*|-tp=*|--sysroot=*| \
   
-O*|-g*|-flto*|-fwhopr*|-fuse-linker-plugin|-fstack-protector*|-stdlib=*| \
-  -specs=*|-fsanitize=*|-fuse-ld=*)
+  -specs=*|-fsanitize=*|-fuse-ld=*|-static-*|-fcilkplus)
 func_quote_arg pretty "$arg"
arg=$func_quote_arg_result
 func_append compile_command " $arg"
-- 
2.20.1

Re: [PATCH] libtool: fix ABI detection for freebsd-amd64.

[Tijl Coosemans]

On Wed, 2 Nov 2016 16:54:35 +0500 Mihail Konev  wrote:
> Fixes _LT_ENABLE_LOCK.
> Untested.
> 
> BugLink: https://github.com/libffi/libffi/pull/79
> ---
>  m4/libtool.m4 | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/m4/libtool.m4 b/m4/libtool.m4
> index ee292aff5bca..d97f20f1ba0b 100644
> --- a/m4/libtool.m4
> +++ b/m4/libtool.m4
> @@ -1369,7 +1369,7 @@ mips64*-*linux*)
>rm -rf conftest*
>;;
>  
> -x86_64-*kfreebsd*-gnu|x86_64-*linux*|powerpc*-*linux*| \
> +amd64-*-freebsd*|x86_64-*kfreebsd*-gnu|x86_64-*linux*|powerpc*-*linux*| \
>  s390*-*linux*|s390*-*tpf*|sparc*-*linux*)
># Find out what ABI is being produced by ac_compile, and set linker
># options accordingly.  Note that the listed cases only cover the

The code under this case is a no-op for FreeBSD so this patch doesn't make
any sense.  I looked at the history of this patch and the original does
make sense (for libffi) but is no longer needed.  Instead of removing it it
was changed into the above by someone who obviously didn't know what they
were doing:
https://svnweb.freebsd.org/ports/head/lang/python26/files/patch-Modules-_ctypes-libffi-configure?r1=158131=221521=158131

So please just ignore this and feel free to close the libffi bug you
linked to above.

[PATCH] libtool: fix ABI detection for freebsd-amd64.

[Mihail Konev]

Fixes _LT_ENABLE_LOCK.
Untested.

BugLink: https://github.com/libffi/libffi/pull/79
---
 m4/libtool.m4 | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/m4/libtool.m4 b/m4/libtool.m4
index ee292aff5bca..d97f20f1ba0b 100644
--- a/m4/libtool.m4
+++ b/m4/libtool.m4
@@ -1369,7 +1369,7 @@ mips64*-*linux*)
   rm -rf conftest*
   ;;
 
-x86_64-*kfreebsd*-gnu|x86_64-*linux*|powerpc*-*linux*| \
+amd64-*-freebsd*|x86_64-*kfreebsd*-gnu|x86_64-*linux*|powerpc*-*linux*| \
 s390*-*linux*|s390*-*tpf*|sparc*-*linux*)
   # Find out what ABI is being produced by ac_compile, and set linker
   # options accordingly.  Note that the listed cases only cover the
-- 
2.9.2

Re: [PATCH] libtool: preliminary support for the Cray compiler.

[Sean Byland]

I didn’t notice that the archive reference was missing:
http://lists.gnu.org/archive/html/libtool/2015-04/msg3.html

and here’s the patch:
http://lists.gnu.org/archive/html/libtool/2015-04/txtaYIR4rrTPk.txt

Thanks,
Sean B.

From: Sean Byland <se...@cray.com<mailto:se...@cray.com>>
Date: Wednesday, May 4, 2016 at 2:41 PM
To: "libt...@gnu.org<mailto:libt...@gnu.org>" 
<libt...@gnu.org<mailto:libt...@gnu.org>>, 
"libtool-patches@gnu.org<mailto:libtool-patches@gnu.org>" 
<libtool-patches@gnu.org<mailto:libtool-patches@gnu.org>>
Cc: Eric Bavier <bav...@cray.com<mailto:bav...@cray.com>>
Subject: Re: [PATCH] libtool: preliminary support for the Cray compiler.

Did anyone get a chance to look at this patch that Eric created last year? Is 
there any chance it could be merged in with the libtool source? In order for 
people to build shared libraries with CCE, I have to tell them to download the 
libtool source and then apply this patch. It would be greatly appreciated if we 
could eliminate the patching step and at some point have the ltmain.sh that 
ships with most packages generate appropriate flags.

Thanks,
Sean B.

Re: [PATCH] libtool: preliminary support for the Cray compiler.

[Sean Byland]

Did anyone get a chance to look at this patch that Eric created last year? Is 
there any chance it could be merged in with the libtool source? In order for 
people to build shared libraries with CCE, I have to tell them to download the 
libtool source and then apply this patch. It would be greatly appreciated if we 
could eliminate the patching step and at some point have the ltmain.sh that 
ships with most packages generate appropriate flags.

Thanks,
Sean B.

[PATCH] libtool: pass through -fuse-ld flags

[Mike Frysinger]

Starting with gcc-4.8, there's a -fuse-ld flag that can be used to select
between bfd & gold.  Make sure we pass it through to the linking stage.

* build-aux/ltmain.in (func_mode_link): Pass -fuse-ld=* flags through.
---
 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 2a5aaad..4c24d5d 100644
--- a/build-aux/ltmain.in
+++ b/build-aux/ltmain.in
@@ -5383,10 +5383,11 @@ func_mode_link ()
   # -specs=* GCC specs files
   # -stdlib=*select c++ std lib with clang
   # -fsanitize=* Clang/GCC memory and address sanitizer
+  # -fuse-ld=*   Linker select flags for GCC
   -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=*)
+  -specs=*|-fsanitize=*|-fuse-ld=*)
 func_quote_arg pretty "$arg"
arg=$func_quote_arg_result
 func_append compile_command " $arg"
-- 
2.6.2

[PATCH] libtool: update cached $GCC value when updating $GXX

[Peter Rosin]

Hi!

I noticed this while looking at the -nostdlib stuff. Will push
in a couple of days unless there are valid objections.

Cheers,
Peter
From 7efe9b28d977fccded55843c8bee3458835d0435 Mon Sep 17 00:00:00 2001
From: Peter Rosin p...@lysator.liu.se
Date: Mon, 11 Nov 2013 10:00:28 +0100
Subject: [PATCH] libtool: update cached $GCC value when updating $GXX

In the meat of the _LT_LANG_CXX_CONFIG macro, and in invoked
macros, $GCC is used to indicate if g++ is used. $GCC is used
instead of $GXX if an invoced macro is written in a tag
agnositic way, like _LT_SYS_DYNAMIC_LINKER is. Note that GCC
is restored to its original value at the end of the macro.

* m4/libtool.m4 (_LT_LANG_CXX_CONFIG): If updating the GXX
variable, for consistency also update the GCC variable.

Signed-off-by: Peter Rosin p...@lysator.liu.se
---
 m4/libtool.m4 |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/m4/libtool.m4 b/m4/libtool.m4
index e34e021..523503f 100644
--- a/m4/libtool.m4
+++ b/m4/libtool.m4
@@ -6083,6 +6083,7 @@ if test yes != $_lt_caught_CXX_error; then
 
 else
   GXX=no
+  GCC=$GXX
   with_gnu_ld=no
   wlarc=
 fi
-- 
1.7.9

Re: [PATCH] libtool: update cached $GCC value when updating $GXX

[Peter Rosin]

On 2013-11-11 10:37, Peter Rosin wrote:
 Will push in a couple of days unless there are valid objections.

Forget it. I am a moron. It would be more valid to simply remove
the GXX=no assignment, but I can't classify that as a bug. Sorry
for wasting your bandwidth.

Cheers,
Peter

Re: [PATCH] libtool: LT_PATH_NM: default to ${ac_tool_prefix}nm

[Peter Rosin]

On 2013-04-28 09:21, Peter Rosin wrote:
 On 2013-04-27 22:38, Mike Frysinger wrote:
 On Saturday 27 April 2013 13:53:28 Peter Rosin wrote:
 On 2013-04-27 07:58, Mike Frysinger wrote:
 The current code tries to locate a compatible nm tool.  It starts with
 a prefixed nm tool (great!) and includes a plain nm too (that's fine).
 The problem is that the code searches for the prefixed nm before the
 plain nm (normally fine), but doesn't break once it has found a valid
 match.  It does this so that it if it finds an OK, but not great,
 tool, it'll keep on searching.

 I agree this sounds like the wrong this to do, but isn't it better to
 just break all the way out when a great nm is found?

 for some reason i thought the [n] arg to break wasn't portable.  this should 
 work though.
 -mike
 
 And on re-reading, my IFS changes are not very constructive. I removed
 those. I will push the attached in a couple of days, if there are no
 objections.

Pushed now, and thanks!

Cheers,
Peter

Re: [PATCH] libtool: LT_PATH_NM: default to ${ac_tool_prefix}nm

[Peter Rosin]

On 2013-04-29 04:45, Mike Frysinger wrote:
 On Sunday 28 April 2013 03:21:15 Peter Rosin wrote:
 And on re-reading, my IFS changes are not very constructive. I removed
 those. I will push the attached in a couple of days, if there are no
 objections.
 
 i actually thought your IFS changes made sense.  the current code 
 saves/restores IFS around the inside loop, so if your code breaks out of both 
 the inside and outside loop, then IFS won't get restored.

The first statement of the inner loop restores IFS, so IFS is as it should
be when break 2 hits, no?

Cheers,
Peter

Re: [PATCH] libtool: LT_PATH_NM: default to ${ac_tool_prefix}nm

[Mike Frysinger]

On Monday 29 April 2013 02:55:12 Peter Rosin wrote:
 On 2013-04-29 04:45, Mike Frysinger wrote:
  On Sunday 28 April 2013 03:21:15 Peter Rosin wrote:
  And on re-reading, my IFS changes are not very constructive. I removed
  those. I will push the attached in a couple of days, if there are no
  objections.
  
  i actually thought your IFS changes made sense.  the current code
  saves/restores IFS around the inside loop, so if your code breaks out of
  both the inside and outside loop, then IFS won't get restored.
 
 The first statement of the inner loop restores IFS, so IFS is as it should
 be when break 2 hits, no?

so it does ... i was focusing on the code outside of the inner loop.  why do 
we need the restore at the bottom then ?
-mike


signature.asc
Description: This is a digitally signed message part.

Re: [PATCH] libtool: LT_PATH_NM: default to ${ac_tool_prefix}nm

[Peter Rosin]

On 2013-04-29 17:55, Mike Frysinger wrote:
 On Monday 29 April 2013 02:55:12 Peter Rosin wrote:
 On 2013-04-29 04:45, Mike Frysinger wrote:
 On Sunday 28 April 2013 03:21:15 Peter Rosin wrote:
 And on re-reading, my IFS changes are not very constructive. I removed
 those. I will push the attached in a couple of days, if there are no
 objections.

 i actually thought your IFS changes made sense.  the current code
 saves/restores IFS around the inside loop, so if your code breaks out of
 both the inside and outside loop, then IFS won't get restored.

 The first statement of the inner loop restores IFS, so IFS is as it should
 be when break 2 hits, no?
 
 so it does ... i was focusing on the code outside of the inner loop.  why do 
 we need the restore at the bottom then ?

It's a pattern, if the for argument list is empty (which it isn't in this
particular case) the inner loop is never entered. I also have this vague
memory of someone saying that some shell restored IFS to the value it had
before the for statement after each round in the for loop, but that might
easily be some silly misunderstanding on my part (or the someone, whoever
that was) and sorry for spreading misinformation in that case...

Cheers,
Peter

Re: [PATCH] libtool: LT_PATH_NM: default to ${ac_tool_prefix}nm

[Peter Rosin]

On 2013-04-27 22:38, Mike Frysinger wrote:
 On Saturday 27 April 2013 13:53:28 Peter Rosin wrote:
 On 2013-04-27 07:58, Mike Frysinger wrote:
 The current code tries to locate a compatible nm tool.  It starts with
 a prefixed nm tool (great!) and includes a plain nm too (that's fine).
 The problem is that the code searches for the prefixed nm before the
 plain nm (normally fine), but doesn't break once it has found a valid
 match.  It does this so that it if it finds an OK, but not great,
 tool, it'll keep on searching.

 I agree this sounds like the wrong this to do, but isn't it better to
 just break all the way out when a great nm is found?
 
 for some reason i thought the [n] arg to break wasn't portable.  this should 
 work though.
 -mike

And on re-reading, my IFS changes are not very constructive. I removed
those. I will push the attached in a couple of days, if there are no
objections.

Cheers,
Peter

From a4629ebff263dcb2e05feb9e41df649ea5ce3f78 Mon Sep 17 00:00:00 2001
From: Peter Rosin p...@lysator.liu.se
Date: Sun, 28 Apr 2013 09:16:56 +0200
Subject: [PATCH] libtool: break all the way out when a good nm is found

The current code tries to locate a compatible nm tool.  It starts with
a prefixed nm tool (great!) and includes a plain nm too (that's fine).
The problem is that the code searches for the prefixed nm before the
plain nm (normally fine), but doesn't break once it has found a valid
match, and the plain nm ends up the winner.

Report and analysis by Mike Frysinger.

* m4/libtool.m4 (LT_PATH_NM): Break all the way out on a good match.

Signed-off-by: Peter Rosin p...@lysator.liu.se
---
 m4/libtool.m4 |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/m4/libtool.m4 b/m4/libtool.m4
index 3f50b0c..d7013c5 100644
--- a/m4/libtool.m4
+++ b/m4/libtool.m4
@@ -3397,13 +3397,13 @@ else
 	case `$tmp_nm -B /dev/null 21 | sed '1q'` in
 	*/dev/null* | *'Invalid file or object type'*)
 	  lt_cv_path_NM=$tmp_nm -B
-	  break
+	  break 2
 	  ;;
 	*)
 	  case `$tmp_nm -p /dev/null 21 | sed '1q'` in
 	  */dev/null*)
 	lt_cv_path_NM=$tmp_nm -p
-	break
+	break 2
 	;;
 	  *)
 	lt_cv_path_NM=${lt_cv_path_NM=$tmp_nm} # keep the first match, but
-- 
1.7.9

Re: [PATCH] libtool: LT_PATH_NM: default to ${ac_tool_prefix}nm

[Mike Frysinger]

On Sunday 28 April 2013 03:21:15 Peter Rosin wrote:
 On 2013-04-27 22:38, Mike Frysinger wrote:
  On Saturday 27 April 2013 13:53:28 Peter Rosin wrote:
  On 2013-04-27 07:58, Mike Frysinger wrote:
  The current code tries to locate a compatible nm tool.  It starts with
  a prefixed nm tool (great!) and includes a plain nm too (that's fine).
  The problem is that the code searches for the prefixed nm before the
  plain nm (normally fine), but doesn't break once it has found a valid
  match.  It does this so that it if it finds an OK, but not great,
  tool, it'll keep on searching.
  
  I agree this sounds like the wrong this to do, but isn't it better to
  just break all the way out when a great nm is found?
  
  for some reason i thought the [n] arg to break wasn't portable.  this
  should work though.
  -mike
 
 And on re-reading, my IFS changes are not very constructive. I removed
 those. I will push the attached in a couple of days, if there are no
 objections.

i actually thought your IFS changes made sense.  the current code 
saves/restores IFS around the inside loop, so if your code breaks out of both 
the inside and outside loop, then IFS won't get restored.
-mike


signature.asc
Description: This is a digitally signed message part.

[PATCH] libtool: LT_PATH_NM: default to ${ac_tool_prefix}nm

[Mike Frysinger]

The current code tries to locate a compatible nm tool.  It starts with
a prefixed nm tool (great!) and includes a plain nm too (that's fine).
The problem is that the code searches for the prefixed nm before the
plain nm (normally fine), but doesn't break once it has found a valid
match.  It does this so that it if it finds an OK, but not great,
tool, it'll keep on searching.

Let's re-order the search so that the plain nm comes first and the
prefixed nm comes last.  This doesn't violate any of the existing
logic and keeps us with defaulting to the prefixed tool.

The code currently tries to avoid using a plain nm tool when it knows
it most likely will be wrong (i.e. when cross-compiling).  However,
this assumption is not valid and can indeed cause problems.  Consider
projects that utilize qemu to provide native builds all the time:
$ ./config.guess
x86_64-unknown-linux-gnu
$ ./configure --build=bfin-uclinux --host=bfin-uclinux
The code produced by the toolchain will execute fine here (because
we've configured the system to use qemu to transparently run the
programs), but libtool will end up defaulting to `nm` which does not
work with ELFs it does not know about.

* m4/libtool.m4 (LT_PATH_NM): Prepend nm to lt_nm_to_check rather than
append.

Signed-off-by: Mike Frysinger vap...@gentoo.org
---
 m4/libtool.m4 | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/m4/libtool.m4 b/m4/libtool.m4
index 3f50b0c..624b3a0 100644
--- a/m4/libtool.m4
+++ b/m4/libtool.m4
@@ -3381,7 +3381,7 @@ AC_CACHE_CHECK([for BSD- or MS-compatible name lister 
(nm)], lt_cv_path_NM,
 else
   lt_nm_to_check=${ac_tool_prefix}nm
   if test -n $ac_tool_prefix  test $build = $host; then
-lt_nm_to_check=$lt_nm_to_check nm
+lt_nm_to_check=nm $lt_nm_to_check
   fi
   for lt_tmp_nm in $lt_nm_to_check; do
 lt_save_ifs=$IFS; IFS=$PATH_SEPARATOR
-- 
1.8.2.1

Re: FYI [PATCH] libtool: minimise forks per invocation under bash.

[Eric Blake]

On 12/18/2011 06:33 AM, Gary V. Vaughan wrote:
 Can anyone think of something better than just removing the whole 
 lt_HAVE_PLUSEQ_OP
 clause from the patch quoted above, and letting the shell figure it by 
 itself later
 on?
 Adding an extra eval seems to do the trick:

Yes - hiding behind eval is the only way to use shell extensions that
not all shells will parse.


  eval 'test 3000 -lt $((${BASH_VERSINFO[0]}*1000 + ${BASH_VERSINFO[1]}))'

 Of course, a comment about why this eval is needed would be definitely
 warranted.
 
 Not that I've looked at the implementation, but isn't eval as bad as a fork on
 Windows? (which is the only reason to avoid forks, since they are extremely 
 cheap on
 Unix.)

No.  eval doesn't fork.

 
 Or, to be even safer, you could directly poke at $BASH_VERSION instead:

  case $BASH_VERSION in
[12].*|3.0.*) ;;
*) lt_HAVE_PLUSEQ_OP=yes;;
  esac
 
 Ah, true... I guess I was too focussed on a straight forward one liner, and 
 missed
 the obvious one.  D'oh!  I'll switch to that and push presently.

-- 
Eric Blake   ebl...@redhat.com+1-919-301-3266
Libvirt virtualization library http://libvirt.org



signature.asc
Description: OpenPGP digital signature

Re: FYI: [PATCH] libtool: make fork minimisation compatible with dash and zsh.

[Eric Blake]

On 12/18/2011 06:49 AM, Gary V. Vaughan wrote:
 * build-aub/general.m4sh (lt_HAVE_PLUSEQ_OP): Instead of using
 $((..)) arithmetic, which causes an error on dash, use a case
 based bash version check.

Dash understands $(( )).  What it doesn't understand is ${BASH_VERSINFO[0]}.

Solaris /bin/sh understands neither, though, so fixing this is
definitely necessary.

 +if test set = ${BASH_VERSION+set}${ZSH_VERSION}; then
  : ${lt_HAVE_ARITH_OP=yes}
  : ${lt_HAVE_XSI_OPS=yes}

If you wanted, you could combine those two into a single statement:

: ${lt_HAVE_ARITH_OP=yes} ${lt_HAVE_XSI_OPS=yes}

-- 
Eric Blake   ebl...@redhat.com+1-919-301-3266
Libvirt virtualization library http://libvirt.org



signature.asc
Description: OpenPGP digital signature

Re: FYI [PATCH] libtool: minimise forks per invocation under bash.

[Stefano Lattarini]

On 12/18/2011 06:15 AM, Gary V. Vaughan wrote:

+# We should try to minimise forks, especially on Windows where they are
+# unreasonably slow, so skip the feature probes when bash is being used:
+if test set = ${BASH_VERSION+set}; then
+: ${lt_HAVE_ARITH_OP=yes}
+: ${lt_HAVE_XSI_OPS=yes}
+# The += operator was introduced in bash 3.1
+test -z $lt_HAVE_PLUSEQ_OP \
+  test 3000 -lt $((${BASH_VERSINFO[0]}*1000 + ${BASH_VERSINFO[1]})) \
+  lt_HAVE_PLUSEQ_OP=yes
+fi

This will likely break with dash 0.5.2:

  $ cat foo.sh
  #!/bin/sh
  if test set = ${BASH_VERSION+set}; then
: ${lt_HAVE_ARITH_OP=yes}
: ${lt_HAVE_XSI_OPS=yes}
# The += operator was introduced in bash 3.1
test -z $lt_HAVE_PLUSEQ_OP \
 test 3000 -lt $((${BASH_VERSINFO[0]}*1000 + ${BASH_VERSINFO[1]})) \
 lt_HAVE_PLUSEQ_OP=yes
  fi
  $ dash foo.sh
  foo.sh: 7: Syntax error: Bad substitution

Regards,
Stefano

Re: FYI [PATCH] libtool: minimise forks per invocation under bash.

[Stefano Lattarini]

On 12/18/2011 10:52 AM, Stefano Lattarini wrote:

On 12/18/2011 06:15 AM, Gary V. Vaughan wrote:

+# We should try to minimise forks, especially on Windows where they are
+# unreasonably slow, so skip the feature probes when bash is being 
used:

+if test set = ${BASH_VERSION+set}; then
+: ${lt_HAVE_ARITH_OP=yes}
+: ${lt_HAVE_XSI_OPS=yes}
+# The += operator was introduced in bash 3.1
+test -z $lt_HAVE_PLUSEQ_OP \
+  test 3000 -lt $((${BASH_VERSINFO[0]}*1000 + 
${BASH_VERSINFO[1]})) \

+  lt_HAVE_PLUSEQ_OP=yes
+fi

This will likely break with dash 0.5.2:

  $ cat foo.sh
  #!/bin/sh
  if test set = ${BASH_VERSION+set}; then
: ${lt_HAVE_ARITH_OP=yes}
: ${lt_HAVE_XSI_OPS=yes}
# The += operator was introduced in bash 3.1
test -z $lt_HAVE_PLUSEQ_OP \
 test 3000 -lt $((${BASH_VERSINFO[0]}*1000 + ${BASH_VERSINFO[1]})) \
 lt_HAVE_PLUSEQ_OP=yes
  fi
  $ dash foo.sh
  foo.sh: 7: Syntax error: Bad substitution


Update: the same happens with NetBSD 5.1 /bin/sh (which is probably
an ash-derivative).

Regards,
  Stefano

Re: FYI [PATCH] libtool: minimise forks per invocation under bash.

[Gary V. Vaughan]

Hi Stefano,

On 18 Dec 2011, at 17:02, Stefano Lattarini wrote:

 On 12/18/2011 10:52 AM, Stefano Lattarini wrote:
 On 12/18/2011 06:15 AM, Gary V. Vaughan wrote:
 +# We should try to minimise forks, especially on Windows where they are
 +# unreasonably slow, so skip the feature probes when bash is being used:
 +if test set = ${BASH_VERSION+set}; then
 +: ${lt_HAVE_ARITH_OP=yes}
 +: ${lt_HAVE_XSI_OPS=yes}
 +# The += operator was introduced in bash 3.1
 +test -z $lt_HAVE_PLUSEQ_OP \
 +  test 3000 -lt $((${BASH_VERSINFO[0]}*1000 + ${BASH_VERSINFO[1]})) \
 +  lt_HAVE_PLUSEQ_OP=yes
 +fi
 This will likely break with dash 0.5.2:
 
  $ cat foo.sh
  #!/bin/sh
  if test set = ${BASH_VERSION+set}; then
: ${lt_HAVE_ARITH_OP=yes}
: ${lt_HAVE_XSI_OPS=yes}
# The += operator was introduced in bash 3.1
test -z $lt_HAVE_PLUSEQ_OP \
  test 3000 -lt $((${BASH_VERSINFO[0]}*1000 + ${BASH_VERSINFO[1]})) \
  lt_HAVE_PLUSEQ_OP=yes
  fi
  $ dash foo.sh
  foo.sh: 7: Syntax error: Bad substitution
 
 Update: the same happens with NetBSD 5.1 /bin/sh (which is probably
 an ash-derivative).

Thanks for the report.

Unfortunately, I'm out of ideas on how to portably detect the bash version 
without
spending a fork, in which case it seems easiest to spend that fork actually 
testing
for += support rather than poking at the bash version.

Can anyone think of something better than just removing the whole 
lt_HAVE_PLUSEQ_OP
clause from the patch quoted above, and letting the shell figure it by itself 
later
on?

Cheers,
-- 
Gary V. Vaughan (gary AT gnu DOT org)

Re: FYI [PATCH] libtool: minimise forks per invocation under bash.

[Stefano Lattarini]

On 12/18/2011 11:07 AM, Gary V. Vaughan wrote:

Hi Stefano,

On 18 Dec 2011, at 17:02, Stefano Lattarini wrote:


On 12/18/2011 10:52 AM, Stefano Lattarini wrote:

On 12/18/2011 06:15 AM, Gary V. Vaughan wrote:

+# We should try to minimise forks, especially on Windows where they are
+# unreasonably slow, so skip the feature probes when bash is being used:
+if test set = ${BASH_VERSION+set}; then
+: ${lt_HAVE_ARITH_OP=yes}
+: ${lt_HAVE_XSI_OPS=yes}
+# The += operator was introduced in bash 3.1
+test -z $lt_HAVE_PLUSEQ_OP \
+   test 3000 -lt $((${BASH_VERSINFO[0]}*1000 + ${BASH_VERSINFO[1]})) \
+   lt_HAVE_PLUSEQ_OP=yes
+fi

This will likely break with dash 0.5.2:

  $ cat foo.sh
  #!/bin/sh
  if test set = ${BASH_VERSION+set}; then
: ${lt_HAVE_ARITH_OP=yes}
: ${lt_HAVE_XSI_OPS=yes}
# The += operator was introduced in bash 3.1
test -z $lt_HAVE_PLUSEQ_OP \
  test 3000 -lt $((${BASH_VERSINFO[0]}*1000 + ${BASH_VERSINFO[1]})) \
  lt_HAVE_PLUSEQ_OP=yes
  fi
  $ dash foo.sh
  foo.sh: 7: Syntax error: Bad substitution

Update: the same happens with NetBSD 5.1 /bin/sh (which is probably
an ash-derivative).

Thanks for the report.

Unfortunately, I'm out of ideas on how to portably detect the bash version 
without
spending a fork, in which case it seems easiest to spend that fork actually 
testing
for += support rather than poking at the bash version.

Can anyone think of something better than just removing the whole 
lt_HAVE_PLUSEQ_OP
clause from the patch quoted above, and letting the shell figure it by itself 
later
on?

Adding an extra eval seems to do the trick:

  eval 'test 3000 -lt $((${BASH_VERSINFO[0]}*1000 + 
${BASH_VERSINFO[1]}))'


Of course, a comment about why this eval is needed would be definitely
warranted.

Or, to be even safer, you could directly poke at $BASH_VERSION instead:

  case $BASH_VERSION in
[12].*|3.0.*) ;;
*) lt_HAVE_PLUSEQ_OP=yes;;
  esac

Regards,
  Stefano

Re: FYI [PATCH] libtool: minimise forks per invocation under bash.

[Gary V. Vaughan]

Hi Stefano,

On 18 Dec 2011, at 17:19, Stefano Lattarini wrote:
 On 12/18/2011 11:07 AM, Gary V. Vaughan wrote:
 On 18 Dec 2011, at 17:02, Stefano Lattarini wrote:
 On 12/18/2011 10:52 AM, Stefano Lattarini wrote:
 On 12/18/2011 06:15 AM, Gary V. Vaughan wrote:
 +# We should try to minimise forks, especially on Windows where they are
 +# unreasonably slow, so skip the feature probes when bash is being used:
 +if test set = ${BASH_VERSION+set}; then
 +: ${lt_HAVE_ARITH_OP=yes}
 +: ${lt_HAVE_XSI_OPS=yes}
 +# The += operator was introduced in bash 3.1
 +test -z $lt_HAVE_PLUSEQ_OP \
 +   test 3000 -lt $((${BASH_VERSINFO[0]}*1000 + ${BASH_VERSINFO[1]})) 
 \
 +   lt_HAVE_PLUSEQ_OP=yes
 +fi
 This will likely break with dash 0.5.2:
 
  $ cat foo.sh
  #!/bin/sh
  if test set = ${BASH_VERSION+set}; then
: ${lt_HAVE_ARITH_OP=yes}
: ${lt_HAVE_XSI_OPS=yes}
# The += operator was introduced in bash 3.1
test -z $lt_HAVE_PLUSEQ_OP \
   test 3000 -lt $((${BASH_VERSINFO[0]}*1000 + ${BASH_VERSINFO[1]})) \
   lt_HAVE_PLUSEQ_OP=yes
  fi
  $ dash foo.sh
  foo.sh: 7: Syntax error: Bad substitution
 Update: the same happens with NetBSD 5.1 /bin/sh (which is probably
 an ash-derivative).
 Thanks for the report.
 
 Unfortunately, I'm out of ideas on how to portably detect the bash version 
 without
 spending a fork, in which case it seems easiest to spend that fork actually 
 testing
 for += support rather than poking at the bash version.
 
 Can anyone think of something better than just removing the whole 
 lt_HAVE_PLUSEQ_OP
 clause from the patch quoted above, and letting the shell figure it by 
 itself later
 on?
 Adding an extra eval seems to do the trick:
 
  eval 'test 3000 -lt $((${BASH_VERSINFO[0]}*1000 + ${BASH_VERSINFO[1]}))'
 
 Of course, a comment about why this eval is needed would be definitely
 warranted.

Not that I've looked at the implementation, but isn't eval as bad as a fork on
Windows? (which is the only reason to avoid forks, since they are extremely 
cheap on
Unix.)

 Or, to be even safer, you could directly poke at $BASH_VERSION instead:
 
  case $BASH_VERSION in
[12].*|3.0.*) ;;
*) lt_HAVE_PLUSEQ_OP=yes;;
  esac

Ah, true... I guess I was too focussed on a straight forward one liner, and 
missed
the obvious one.  D'oh!  I'll switch to that and push presently.

Cheers,
-- 
Gary V. Vaughan (gary AT gnu DOT org)

FYI: [PATCH] libtool: make fork minimisation compatible with dash and zsh.

[Gary V. Vaughan]

* build-aub/general.m4sh (lt_HAVE_PLUSEQ_OP): Instead of using
$((..)) arithmetic, which causes an error on dash, use a case
based bash version check.
(lt_HAVE_ARITH_OP, lt_HAVE_XSI_OPS): Also short circuit the
feature probing forks and set these automatically when zsh is
detected.
Reported by Stefano Lattarini.

Signed-off-by: Gary V. Vaughan g...@gnu.org
---
 build-aux/general.m4sh |   12 +++-
 1 files changed, 7 insertions(+), 5 deletions(-)

diff --git a/build-aux/general.m4sh b/build-aux/general.m4sh
index e96c0e4..3cfecee 100644
--- a/build-aux/general.m4sh
+++ b/build-aux/general.m4sh
@@ -75,14 +75,16 @@ basename='s|^.*/||'
 
 
 # We should try to minimise forks, especially on Windows where they are
-# unreasonably slow, so skip the feature probes when bash is being used:
-if test set = ${BASH_VERSION+set}; then
+# unreasonably slow, so skip the feature probes when bash or zsh are
+# being used:
+if test set = ${BASH_VERSION+set}${ZSH_VERSION}; then
 : ${lt_HAVE_ARITH_OP=yes}
 : ${lt_HAVE_XSI_OPS=yes}
 # The += operator was introduced in bash 3.1
-test -z $lt_HAVE_PLUSEQ_OP \
-   test 3000 -lt $((${BASH_VERSINFO[0]}*1000 + ${BASH_VERSINFO[1]})) \
-   lt_HAVE_PLUSEQ_OP=yes
+case $BASH_VERSION in
+  [12].* | 3.0 | 3.0.*) ;;
+  *)lt_HAVE_PLUSEQ_OP=yes ;;
+esac
 fi
 
 
-- 
1.7.8

Cheers,
-- 
Gary V. Vaughan (gary AT gnu DOT org)

FYI [PATCH] libtool: minimise forks per invocation under bash.

[Gary V. Vaughan]

Thanks to Eric Blake, Peter O'Gorman and Bob Friesenhahn for steering
me in this direction.

* build-aux/general.m4sh (lt_HAVE_PLUSEQ_OP, lt_HAVE_ARITH_OP)
(lt_HAVE_XSI_OPS): Set these without forking a test script when
running under bash, to avoid a few unnecessary forks.

Signed-off-by: Gary V. Vaughan g...@gnu.org
---
 build-aux/general.m4sh |   21 -
 1 files changed, 12 insertions(+), 9 deletions(-)

diff --git a/build-aux/general.m4sh b/build-aux/general.m4sh
index 252b2d2..e96c0e4 100644
--- a/build-aux/general.m4sh
+++ b/build-aux/general.m4sh
@@ -74,12 +74,21 @@ dirname='s|/[^/]*$||'
 basename='s|^.*/||'
 
 
+# We should try to minimise forks, especially on Windows where they are
+# unreasonably slow, so skip the feature probes when bash is being used:
+if test set = ${BASH_VERSION+set}; then
+: ${lt_HAVE_ARITH_OP=yes}
+: ${lt_HAVE_XSI_OPS=yes}
+# The += operator was introduced in bash 3.1
+test -z $lt_HAVE_PLUSEQ_OP \
+   test 3000 -lt $((${BASH_VERSINFO[0]}*1000 + ${BASH_VERSINFO[1]})) \
+   lt_HAVE_PLUSEQ_OP=yes
+fi
+
+
 # lt_HAVE_PLUSEQ_OP
 # Can be empty, in which case the shell is probed, yes if += is useable
 # or anything else if += does not work.
-# NOTE: You can short-circuit the fork and test on every invocation (e.g.
-# on Windows where fork emulations are unreasonably slow) by setting this
-# in the environment of this script.
 test -z $lt_HAVE_PLUSEQ_OP \
  (eval 'x=a; x+= b; test a b = $x') 2/dev/null \
  lt_HAVE_PLUSEQ_OP=yes
@@ -117,9 +126,6 @@ fi
 # lt_HAVE_ARITH_OP
 # Can be empty, in which case the shell is probed, yes if $((...)) is
 # useable or anything else if it does not work.
-# NOTE: You can short-circuit the fork and test on every invocation (e.g.
-# on Windows where fork emulations are unreasonably slow) by setting this
-# in the environment of this script.
 test -z $lt_HAVE_ARITH_OP \
  (eval 'test 2 = $(( 1 + 1 ))') 2/dev/null \
  lt_HAVE_ARITH_OP=yes
@@ -141,9 +147,6 @@ fi
 # lt_HAVE_XSI_OPS
 # Can be empty, in which case the shell is probed, yes if XSI length
 # and matching operators are useable or anything else if they do not work.
-# NOTE: You can short-circuit the fork and test on every invocation (e.g.
-# on Windows where fork emulations are unreasonably slow) by setting this
-# in the environment of this script.
 test -z $lt_HAVE_XSI_OPS \
  (eval 'x=a/b/c;
   test 5aa/bb/cc = ${#x}${x%%/*}${x%/*}${x#*/}${x##*/}') 2/dev/null \
-- 
1.7.8

Cheers,
-- 
Gary V. Vaughan (gary AT gnu DOT org)

[PATCH] libtool: minimise forks per invocation on cygwin and mingw.

[Gary V. Vaughan]

The recently pushed series of patches included the controversial
introduction of an additional 3 forks per invocation, which might
add a minute or two of wall-clock time to giant builds on windows.
By assuming that windows will run shell scripts on some shell with
all the modern optional features that libtool wants, this patch
eliminates even those 3 new forks.

Okay to push?

* build-aux/general.m4sh (lt_HAVE_PLUSEQ_OP, lt_HAVE_ARITH_OP)
(lt_HAVE_XSI_OPS) [cygwin, mingw]: Set these without a test on
the assumption that a modern shell (i.e. bash) will be used to
run libtool and libtoolize.

Signed-off-by: Gary V. Vaughan g...@gnu.org
---
 build-aux/general.m4sh |   13 +
 1 files changed, 13 insertions(+), 0 deletions(-)

diff --git a/build-aux/general.m4sh b/build-aux/general.m4sh
index 252b2d2..2ac6238 100644
--- a/build-aux/general.m4sh
+++ b/build-aux/general.m4sh
@@ -56,6 +56,7 @@ test ${ECHO+set} = set || ECHO=${as_echo-'printf %s\n'}
 : ${SED=@SED@}
 : ${SHELL=${CONFIG_SHELL-/bin/sh}}
 : ${Xsed=$SED -e 1s/^X//}
+: ${host=@host_triplet@}
 
 # Global variables:
 EXIT_SUCCESS=0
@@ -74,6 +75,18 @@ dirname='s|/[^/]*$||'
 basename='s|^.*/||'
 
 
+# Forks are unreasonably slow under Windows, so we assume that, for at
+# least cygwin and mingw, /bin/sh is bash, and save at least 3 forks per
+# invocation:
+case $host in
+  *cygwin* | *mingw*)
+test -n $lt_HAVE_PLUSEQ_OP || lt_HAVE_PLUSEQ_OP=yes
+test -n $lt_HAVE_ARITH_OP  || lt_HAVE_ARITH_OP=yes
+test -n $lt_HAVE_XSI_OPS   || lt_HAVE_XSI_OPS=yes
+;;
+esac
+
+
 # lt_HAVE_PLUSEQ_OP
 # Can be empty, in which case the shell is probed, yes if += is useable
 # or anything else if += does not work.
-- 
1.7.8

Cheers,
-- 
Gary V. Vaughan (gary AT gnu DOT org)

Re: [PATCH] libtool: minimise forks per invocation on cygwin and mingw.

[Eric Blake]

On 12/08/2011 03:21 AM, Gary V. Vaughan wrote:
 The recently pushed series of patches included the controversial
 introduction of an additional 3 forks per invocation, which might
 add a minute or two of wall-clock time to giant builds on windows.
 By assuming that windows will run shell scripts on some shell with
 all the modern optional features that libtool wants, this patch
 eliminates even those 3 new forks.
 
 Okay to push?

I'm a bit reluctant to do this via a host check;

  
 +# Forks are unreasonably slow under Windows, so we assume that, for at
 +# least cygwin and mingw, /bin/sh is bash, and save at least 3 forks per
 +# invocation:
 +case $host in
 +  *cygwin* | *mingw*)

Instead of doing it this way, I'd almost rather see:

if test ${BASH_VERSION+set} = set; then

although if cygwin ever follows debian's lead of using dash for faster
/bin/sh, I'm not sure if there is a reliable forkless way to detect dash.

-- 
Eric Blake   ebl...@redhat.com+1-919-301-3266
Libvirt virtualization library http://libvirt.org



signature.asc
Description: OpenPGP digital signature

Re: [PATCH] libtool: minimise forks per invocation on cygwin and mingw.

[Gary V. Vaughan]

Hi Peter,

On 8 Dec 2011, at 20:40, Peter O'Gorman wrote:
 On 12/08/2011 04:21 AM, Gary V. Vaughan wrote:
 The recently pushed series of patches included the controversial
 introduction of an additional 3 forks per invocation, which might
 add a minute or two of wall-clock time to giant builds on windows.
 By assuming that windows will run shell scripts on some shell with
 all the modern optional features that libtool wants, this patch
 eliminates even those 3 new forks.
 
 Okay to push?
 
 The whole reason these checks were done in configure and not in libtool was 
 to avoid these forks, and the slow down involved. We did a lot of work at 
 speeding up libtool so that non-portable tools such as dolt would not be 
 necessary, including moving large chunks of compile mode script closer the 
 the top of libtool so that it would execute faster.

Ack.  However since I wrote all the hairy M4 code to do the configure time 
replacements, I've changed my mind about how well they work in the grand scheme 
of things... The usual mode of integrating libtool is to have your project's 
configure build a libtool script, which you then call as a compiler wrapper.  
With the exception of projects with a huge number of tiny files to compile, I 
seriously doubt that 3 additional forks per invocation would be noticable as it 
stands now, and after looking back through the replacement code I recently 
expunged, we probably save a few hundred forks from sed and perl invocations at 
configure time, which would mean you don't get any slow down overall in a 
'./configure; make; make install' sequence until you've invoked the libtool 
script at least several dozen times.

Also, I'm trying hard to make hacking on libtool much less infuriating to 
attract more outside patches and development.  Having configure switch out 
function definitions is an odd thing to do, and libtool is already hard enough 
to understand without having to worry about having configure rewriting some of 
libtools functions... hopefully it doesn't make any mistakes ;)

 Any additional forks will slow down the script and should be avoided on all 
 platforms.

Agreed.  And using a BASH_VERSION test will get us a good way there.  I'll also 
work on a follow up patch to set the new lt_HAVE_XSI_OPS and friends using the 
existing machinery for injecting configure time variables into libtool, so I 
can also throw out the last couple of M4 replacement macros.

 Simply removing $(SHELL) from the LIBTOOL variable should fix the bug that 
 this is attempting to fix, without slowing down libtool.

But then we go back to having bug reports about libtool not getting an execute 
bit.  I'm not in favour of making that change.

Cheers,
-- 
Gary V. Vaughan (gary AT gnu DOT org)

Re: [PATCH] libtool: minimise forks per invocation on cygwin and mingw.

[Gary V. Vaughan]

Hi Eric,

On 8 Dec 2011, at 19:56, Eric Blake wrote:
 On 12/08/2011 03:21 AM, Gary V. Vaughan wrote:
 The recently pushed series of patches included the controversial
 introduction of an additional 3 forks per invocation, which might
 add a minute or two of wall-clock time to giant builds on windows.
 By assuming that windows will run shell scripts on some shell with
 all the modern optional features that libtool wants, this patch
 eliminates even those 3 new forks.
 
 Okay to push?
 
 I'm a bit reluctant to do this via a host check;
 
 
 +# Forks are unreasonably slow under Windows, so we assume that, for at
 +# least cygwin and mingw, /bin/sh is bash, and save at least 3 forks per
 +# invocation:
 +case $host in
 +  *cygwin* | *mingw*)
 
 Instead of doing it this way, I'd almost rather see:
 
 if test ${BASH_VERSION+set} = set; then

Face palm!  Absolutely, that is far more sensible.  Assuming we decide
to push this patch, I'll do it that way and ditch the host check.  Thanks!

 although if cygwin ever follows debian's lead of using dash for faster
 /bin/sh, I'm not sure if there is a reliable forkless way to detect dash.

I think we can worry about that later, if it ever happens.

Cheers,
-- 
Gary V. Vaughan (gary AT gnu DOT org)

Re: [PATCH] libtool: minimise forks per invocation on cygwin and mingw.

[Bob Friesenhahn]

On Thu, 8 Dec 2011, Gary V. Vaughan wrote:


Instead of doing it this way, I'd almost rather see:

if test ${BASH_VERSION+set} = set; then


Face palm!  Absolutely, that is far more sensible.  Assuming we decide
to push this patch, I'll do it that way and ditch the host check.  Thanks!


Is the value of this variable inheritable by subordinate shells, or is 
it an internal shell variable which would never be exported to 
subordinate shells?


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

Re: [PATCH] libtool: minimise forks per invocation on cygwin and mingw.

[Eric Blake]

On 12/08/2011 08:04 AM, Bob Friesenhahn wrote:
 On Thu, 8 Dec 2011, Gary V. Vaughan wrote:

 Instead of doing it this way, I'd almost rather see:

 if test ${BASH_VERSION+set} = set; then

 Face palm!  Absolutely, that is far more sensible.  Assuming we decide
 to push this patch, I'll do it that way and ditch the host check. 
 Thanks!
 
 Is the value of this variable inheritable by subordinate shells, or is
 it an internal shell variable which would never be exported to
 subordinate shells?

By default, bash sets up $BASH_VERSION as an internal variable, and not
exported.  It is unwise for users (or scripts) to export BASH_VERSION to
child processes.

-- 
Eric Blake   ebl...@redhat.com+1-919-301-3266
Libvirt virtualization library http://libvirt.org



signature.asc
Description: OpenPGP digital signature

Re: [PATCH] libtool: minimise forks per invocation on cygwin and mingw.

[Charles Wilson]

On 12/8/2011 5:21 AM, Gary V. Vaughan wrote:
 The recently pushed series of patches included the controversial
 introduction of an additional 3 forks per invocation, which might
 add a minute or two of wall-clock time to giant builds on windows.
 By assuming that windows will run shell scripts on some shell with
 all the modern optional features that libtool wants, this patch
 eliminates even those 3 new forks.
 
 Okay to push?

Has anybody done a comparison between:

cygwin + libtool + dash/posh (e.g. small, fast shell -- without XSI)

cygwin + libtool + bash (e.g. big bloated slow shell -- with XSI)

to see which is better?

--
Chuck

Re: [PATCH] libtool: minimise forks per invocation on cygwin and mingw.

[Bob Friesenhahn]

On Thu, 8 Dec 2011, Peter O'Gorman wrote:


Any additional forks will slow down the script and should be avoided on all 
platforms.


I definitely agree with that.  Besides the Windows problem, it does 
not seem like fork performance improves linearly from adding processor 
cores so it is important to minimize forks so that parallel compiles 
don't hit an bottleneck.


Simply removing $(SHELL) from the LIBTOOL variable should fix the bug that 
this is attempting to fix, without slowing down libtool.


Will this approach work ok if the Cygwin/MinGW user is using something 
like zsh or dash rather than bash?


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

Re: [PATCH] libtool: minimise forks per invocation on cygwin and mingw.

[Eric Blake]

On 12/08/2011 08:29 AM, Charles Wilson wrote:
 On 12/8/2011 5:21 AM, Gary V. Vaughan wrote:
 The recently pushed series of patches included the controversial
 introduction of an additional 3 forks per invocation, which might
 add a minute or two of wall-clock time to giant builds on windows.
 By assuming that windows will run shell scripts on some shell with
 all the modern optional features that libtool wants, this patch
 eliminates even those 3 new forks.

 Okay to push?
 
 Has anybody done a comparison between:
 
 cygwin + libtool + dash/posh (e.g. small, fast shell -- without XSI)

Umm, dash has XSI features (where XSI features covers things like
${var##prefix}).  It is only shells like Solaris /bin/sh that lack this
mandatory POSIX feature.  Meanwhile, libtool is using more than just XSI
extensions; for example, it is probing for bash's += variable append
extension.  I'm not sure how much difference += makes (especially since
it is not shaving on forks, but is reducing O(n^2) malloc behavior for
large piece-wise constructions), but do know that XSI variable usage
definitely shaves a lot of forkes.

As for actual timing comparisons, I have not done any recently.

-- 
Eric Blake   ebl...@redhat.com+1-919-301-3266
Libvirt virtualization library http://libvirt.org



signature.asc
Description: OpenPGP digital signature

Re: [PATCH] libtool: minimise forks per invocation on cygwin and mingw.

[Charles Wilson]

On 12/8/2011 11:22 AM, Eric Blake wrote:
 On 12/08/2011 08:29 AM, Charles Wilson wrote:
 cygwin + libtool + dash/posh (e.g. small, fast shell -- without XSI)
 
 Umm, dash has XSI features (where XSI features covers things like
 ${var##prefix}). ... Meanwhile, libtool is using more than just XSI
 extensions; for example, it is probing for bash's += variable append
 extension.

Oh, I didn't realize.  I was primarily thinking about += -- I thought it
was one of the XSI extensions, not a bash-specific thing, and I knew
dash did not support it.

--
Chuck

Re: [PATCH] libtool: minimise forks per invocation on cygwin and mingw.

[Peter O'Gorman]

On 12/08/2011 09:29 AM, Charles Wilson wrote:

Has anybody done a comparison between:

cygwin + libtool + dash/posh (e.g. small, fast shell -- without XSI)

cygwin + libtool + bash (e.g. big bloated slow shell -- with XSI)

to see which is better?



Because I installed mingw32 yesterday on my rarely used windows vista 
home basic VM, I thought I'd do my compile an empty file 100 times test 
on it.


With todays git, bash:
time (for x in {1..100}; do lt_HAVE_XSI_OPS=yes lt_HAVE_PLUSEQ_OP=yes 
lt_HAVE_ARITH_OP=yes ./libtool --mode=compile --tag=CC gcc -c -o a.lo 
a.c; done)



real0m58.766s
user0m5.315s
sys 0m31.981s

real0m54.413s
user0m5.380s
sys 0m31.143s

With dash
time (for x in {1..100}; do lt_HAVE_XSI_OPS=yes lt_HAVE_PLUSEQ_OP=no 
lt_HAVE_ARITH_OP=yes dash ./libtool --mode=compile --tag=CC gcc -c -o 
a.lo a.c; done)


real0m32.089s
user0m1.657s
sys 0m9.330s

real0m29.905s
user0m1.637s
sys 0m9.125s

I think dash might be the winner.

Peter

Re: [PATCH] libtool -- don't print warnings with --silent

[Peter O'Gorman]

On 09/01/2011 06:51 PM, Peter O'Gorman wrote:


Though I am sorely tempted to simply delete those warnings altogether, I
think the --no-warn option is better.

I'll give you a day to veto this patch, if you don't then I will commit
on Saturday. It essentially copies the --no-warn flag from libtoolize to
libtool.


I pushed this patch on Saturday.

Dave, I've attached an approximation of what the patch would do to gcc's 
ltmain.sh and an addition to boehm-gc's .exp file. Both completely 
untested, of course :-)


Thanks,
Peter

Index: ltmain.sh
===
--- ltmain.sh	(revision 178501)
+++ ltmain.sh	(working copy)
@@ -43,6 +43,7 @@
 #   --quiet, --silentdon't print informational messages
 #   --no-quiet, --no-silent
 #print informational messages (default)
+#   --no-warndon't display warning messages
 #   --tag=TAGuse configuration variables from tag TAG
 #   -v, --verboseprint more informational messages than default
 #   --no-verbose don't print the extra informational messages
@@ -944,6 +945,11 @@
 			opt_verbose=:
 			;;
 
+  --no-warning|--no-warn)
+			preserve_args=$preserve_args $opt
+			opt_warning=false
+			;;
+
   --no-verbose)	preserve_args=$preserve_args $opt
 			opt_verbose=false
 			;;
Index: boehm-gc/testsuite/lib/boehm-gc.exp
===
--- boehm-gc/testsuite/lib/boehm-gc.exp	(revision 178501)
+++ boehm-gc/testsuite/lib/boehm-gc.exp	(working copy)
@@ -208,8 +208,8 @@
 # Set this once for reuse in boehm-gc.lib/lib.exp.
 set libtool ../libtool
 # We have to run silently to avoid DejaGnu lossage.
-lappend options compiler=$libtool --silent --tag=CC --mode=$mode \
-	$GCC_UNDER_TEST
+lappend options compiler=$libtool --silent --no-warn --tag=CC \
+--mode=$mode $GCC_UNDER_TEST
 
 lappend options additional_flags=-I${gc_include} -I${srcdir}/../include
 lappend options additional_flags=${threadcflags}

Re: [PATCH] libtool -- don't print warnings with --silent

[John David Anglin]

On 5-Sep-11, at 12:08 PM, Peter O'Gorman wrote:


I pushed this patch on Saturday.


Thanks.



Dave, I've attached an approximation of what the patch would do to  
gcc's ltmain.sh and an addition to boehm-gc's .exp file. Both  
completely untested, of course :-)


I'll give this patch a try in my next build.  Your original patch  
worked.


Dave

Re: [PATCH] libtool -- don't print warnings with --silent

[Bob Friesenhahn]

On Mon, 29 Aug 2011, Peter O'Gorman wrote:


This turns off warnings for --silent (and turns them on again for --verbose).

But I am not sure that --silent was meant to imply no warnings, rather it 
turns off the verbose compile/link messages.


Would a new --no-warnings option be more appropriate?


I agree that a new option would be more appropriate.  However, it 
should be a user-provided configuration option (when building the 
package) and not something which will be hard-coded into Makefiles by 
developers.  The --silent option should have been handled the same so 
that the person building the software can easily decide if the build 
should be silent.


If developers start producing packages which have 'silent' and 
'no-warnings' irreversably baked into the Makefiles, then it will be 
very difficult to diagnose the case that the sofware does not build 
or work due to a tool, build options, or platform issue.


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

Re: [PATCH] libtool -- don't print warnings with --silent

[Peter O'Gorman]

On 09/01/2011 09:25 AM, Bob Friesenhahn wrote:

On Mon, 29 Aug 2011, Peter O'Gorman wrote:


This turns off warnings for --silent (and turns them on again for
--verbose).

But I am not sure that --silent was meant to imply no warnings,
rather it turns off the verbose compile/link messages.

Would a new --no-warnings option be more appropriate?


I agree that a new option would be more appropriate. However, it should
be a user-provided configuration option (when building the package) and
not something which will be hard-coded into Makefiles by developers. The
--silent option should have been handled the same so that the person
building the software can easily decide if the build should be silent.


Hi Bob,

Well, it has to be an option that Dave can add to site.exp for the 
failing tests in gcc. The tests are failing on HP-UX because libtool is 
outputing this platform does not like uninstalled shared libraries 
crap to stderr.


Though I am sorely tempted to simply delete those warnings altogether, I 
think the --no-warn option is better.


I'll give you a day to veto this patch, if you don't then I will commit 
on Saturday. It essentially copies the --no-warn flag from libtoolize to 
libtool.


Peter

From dc28c2bfbcb4879bc04a73186d72ec0e7ef2ad4c Mon Sep 17 00:00:00 2001
From: Peter O'Gorman pe...@pogma.com
Date: Thu, 1 Sep 2011 18:45:03 -0500
Subject: [PATCH] Add flag to inhibit warnings.

* libltdl/config/ltmain.m4sh: Add --no-warn, --no-warning flags.
Reported by John Davd Anglin.
---
 ChangeLog  |6 ++
 libltdl/config/ltmain.m4sh |3 +++
 2 files changed, 9 insertions(+), 0 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index dcfab26..44b325b 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,9 @@
+2011-09-01  Peter O'Gorman  pe...@pogma.com
+
+	Add flag to inhibit warnings.
+	* libltdl/config/ltmain.m4sh: Add --no-warn, --no-warning flags.
+	Reported by John Davd Anglin.
+
 2011-04-10  Kurt Roeckx  k...@roeckx.be
 
 	tagdemo: do not rely on picking up symbols from indirect deps.
diff --git a/libltdl/config/ltmain.m4sh b/libltdl/config/ltmain.m4sh
index 9358ec5..511480f 100644
--- a/libltdl/config/ltmain.m4sh
+++ b/libltdl/config/ltmain.m4sh
@@ -42,6 +42,7 @@ m4_divert_push([SCRIPT])
 #   --quiet, --silentdon't print informational messages
 #   --no-quiet, --no-silent
 #print informational messages (default)
+#   --no-warndon't display warning messages
 #   --tag=TAGuse configuration variables from tag TAG
 #   -v, --verboseprint more informational messages than default
 #   --no-verbose don't print the extra informational messages
@@ -373,6 +374,8 @@ M4SH_GETOPTS(
 	esac],
   [],		[--no-silent|--no-quiet],	[false],		[
 	func_append preserve_args  $opt],
+  [],		[--no-warning|--no-warn],	[false],		[
+	func_append preserve_args  $opt],
   [],		[--no-verbose],			[false],		[
 	func_append preserve_args  $opt],
   [],		[--silent|--quiet],		[],			[
-- 
1.7.4.4

Re: [PATCH] libtool -- don't print warnings with --silent

[Peter O'Gorman]

On 07/29/2011 07:55 PM, John David Anglin wrote:

Ping?


Hi Dave,

ltmain.sh is a generated file, so this patch is not correct. Perhaps 
something like (pasted in mail, so wrapped):


diff --git a/libltdl/config/ltmain.m4sh b/libltdl/config/ltmain.m4sh
index 9358ec5..bd5736c 100644
--- a/libltdl/config/ltmain.m4sh
+++ b/libltdl/config/ltmain.m4sh
@@ -377,9 +377,11 @@ M4SH_GETOPTS(
func_append preserve_args  $opt],
   [],  [--silent|--quiet], [], [
func_append preserve_args  $opt
+opt_warning=false
 opt_verbose=false],
   [v], [--verbose],[], [
func_append preserve_args  $opt
+opt_warning=:
opt_silent=false],
   [!], [--tag],[], [
func_append preserve_args  $opt $optarg

This turns off warnings for --silent (and turns them on again for 
--verbose).


But I am not sure that --silent was meant to imply no warnings, rather 
it turns off the verbose compile/link messages.


Would a new --no-warnings option be more appropriate?

Peter



On 9-Jul-11, at 7:03 PM, John David Anglin wrote:


The attached patch fixes the boehm-gc testsuite on hppa2.0w-hp-hpux11.11.
Without it, libtool always generates an informational warning when
linking
causing the entire boehm-gc testsuite to fail.

Ok? Ralf would you please install in libtool tree if ok.

2011-07-09 John David Anglin dave.ang...@nrc-cnrc.gc.ca

PR boehm-gc/48494
* ltmain.sh (func_warning): Don't print warnings if opt_silent is true.

Index: ltmain.sh
===
--- ltmain.sh (revision 176045)
+++ ltmain.sh (working copy)
@@ -437,7 +437,9 @@
# Echo program name prefixed warning message to standard error.
func_warning ()
{
- $opt_warning  $ECHO $progname${mode+: }$mode: warning: ${1+$@}
12
+ ${opt_silent-false} || {
+ $opt_warning  $ECHO $progname${mode+: }$mode: warning: ${1+$@}
12
+ }

# bash bug again:
:

Dave
--
J. David Anglin dave.ang...@nrc-cnrc.gc.ca
National Research Council of Canada (613) 990-0752 (FAX: 952-6602)

[PATCH] libtool -- don't print warnings with --silent

[John David Anglin]

The attached patch fixes the boehm-gc testsuite on hppa2.0w-hp-hpux11.11.
Without it, libtool always generates an informational warning when linking
causing the entire boehm-gc testsuite to fail.

Ok?  Ralf would you please install in libtool tree if ok.

2011-07-09  John David Anglin  dave.ang...@nrc-cnrc.gc.ca

PR boehm-gc/48494
* ltmain.sh (func_warning): Don't print warnings if opt_silent is true.

Index: ltmain.sh
===
--- ltmain.sh   (revision 176045)
+++ ltmain.sh   (working copy)
@@ -437,7 +437,9 @@
 # Echo program name prefixed warning message to standard error.
 func_warning ()
 {
-$opt_warning  $ECHO $progname${mode+: }$mode: warning: ${1+$@} 12
+${opt_silent-false} || {
+  $opt_warning  $ECHO $progname${mode+: }$mode: warning: ${1+$@} 12
+}
 
 # bash bug again:
 :

Dave
-- 
J. David Anglin  dave.ang...@nrc-cnrc.gc.ca
National Research Council of Canada  (613) 990-0752 (FAX: 952-6602)

Re: ping: [PATCH libtool] hardcoded path to dependent shared libraries on 32-bit hpux (libquadmath)

[John David Anglin]

On Sun, 19 Dec 2010, Ralf Wildenhues wrote:

 Sorry for the delay, I really would like to test the patch on the
 Libtool tree on a couple of systems, and write a Libtool testsuite
 addition for it, so we don't regress in the future.  I hope to get
 to it before the end of the calendar year.
 
 If you'd like to help, you can download the Libtool source tree
 (git or nightly tarball from the website), apply the patch, run
 'make -k check' and send the log files the output tells to send,
 on the HP systems you have available for testing.

I installed git and the other tools needed to build the Libtool source.
The file `tests/testsuite.log' was sent to bug-libt...@gnu.org yesterday.

There was no difference in test results with and without the patch.
The only significant fail that I see on hppa2.0w-hp-hpux11.11 is:
 41: shlibpath_overrides_runpath FAILED (shlibpath.at:71)

The failure of 115 appears to be caused by 41.

If you come up with a testsuite addition, I can now easily test it.

Dave

ping: [PATCH libtool] hardcoded path to dependent shared libraries on 32-bit hpux (libquadmath)

[John David Anglin]

Ping.

On Fri, 10 Dec 2010, John David Anglin wrote:

 On Sun, 28 Nov 2010, Ralf Wildenhues wrote:
 
  * John David Anglin wrote on Sun, Nov 28, 2010 at 09:42:43PM CET:
   The current relative path to libquadmath can be incorrectly interpreted
   on systems that hard code library paths.  In particular, on 32-bit
   hppa*-*hpux*, the '..' part of the path is relative to the final 
   executable.
   As a result, all libgfortran tests fail due to a dynamic loader error.
   
   The patch changes the path to an absolute path.
   
   Tested on hppa2.0w-hp-hpux11.11 and i686-apple-darwin9 with no observed
   regressions.
   
   OK for trunk?
  
  That doesn't seem to make sense to me.  The fix should be in ltmain.sh
  or in libtool.m4.  Please post the output of how libquadmath is linked
  on your system (the 'libtool --mode=link' command plus all of its
  output).
 
 The attached change to ltmain.sh fixes the above problem on on 32-bit
 hppa*-*hpux*.  Tested on hppa2.0w-hp-hpux11.11 and hppa64-hp-hpux11.11.
 
 Would you please apply if ok to libtool, gcc and sourceware?
 
 Thanks,
 Dave
 -- 
 J. David Anglin  dave.ang...@nrc-cnrc.gc.ca
 National Research Council of Canada  (613) 990-0752 (FAX: 
 952-6602)
 
 2010-12-10  John David Anglin  dave.ang...@nrc-cnrc.gc.ca
 
   * ltmain.sh (relink): Use absolute path when hardcoding with -L.
 
 Index: ltmain.sh
 ===
 --- ltmain.sh (revision 167668)
 +++ ltmain.sh (working copy)
 @@ -5928,7 +5928,7 @@
test $hardcode_direct_absolute = no; then
   add=$dir/$linklib
 elif test $hardcode_minus_L = yes; then
 - add_dir=-L$dir
 + add_dir=-L$absdir
   # Try looking first in the location we're being installed to.
   if test -n $inst_prefix_dir; then
 case $libdir in

Dave
-- 
J. David Anglin  dave.ang...@nrc-cnrc.gc.ca
National Research Council of Canada  (613) 990-0752 (FAX: 952-6602)

Re: ping: [PATCH libtool] hardcoded path to dependent shared libraries on 32-bit hpux (libquadmath)

[Ralf Wildenhues]

* John David Anglin wrote on Sun, Dec 19, 2010 at 05:04:36PM CET:
 Ping.
 
 On Fri, 10 Dec 2010, John David Anglin wrote:
  The attached change to ltmain.sh fixes the above problem on on 32-bit
  hppa*-*hpux*.  Tested on hppa2.0w-hp-hpux11.11 and hppa64-hp-hpux11.11.
  
  Would you please apply if ok to libtool, gcc and sourceware?

Sorry for the delay, I really would like to test the patch on the
Libtool tree on a couple of systems, and write a Libtool testsuite
addition for it, so we don't regress in the future.  I hope to get
to it before the end of the calendar year.

If you'd like to help, you can download the Libtool source tree
(git or nightly tarball from the website), apply the patch, run
'make -k check' and send the log files the output tells to send,
on the HP systems you have available for testing.

Thanks,
Ralf

  2010-12-10  John David Anglin  dave.ang...@nrc-cnrc.gc.ca
  
  * ltmain.sh (relink): Use absolute path when hardcoding with -L.
  
  Index: ltmain.sh
  ===
  --- ltmain.sh   (revision 167668)
  +++ ltmain.sh   (working copy)
  @@ -5928,7 +5928,7 @@
   test $hardcode_direct_absolute = no; then
  add=$dir/$linklib
elif test $hardcode_minus_L = yes; then
  -   add_dir=-L$dir
  +   add_dir=-L$absdir
  # Try looking first in the location we're being installed to.
  if test -n $inst_prefix_dir; then
case $libdir in

FYI: revert broken part of the recent libtoolize func_serial_check patch [libtool--devo--1.0--patch-337]

[Gary V. Vaughan]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Applied to HEAD.

  * looking for [EMAIL PROTECTED]/libtool--devo--1.0--patch-336 to compare with
  * comparing to [EMAIL PROTECTED]/libtool--devo--1.0--patch-336
  M  libtoolize.m4sh
  M  ChangeLog
  
  * modified files
  
  Index: Changelog
  from  Gary V. Vaughan  [EMAIL PROTECTED]
* libtoolize.m4sh: Put back the func_serial_update callback for
func_copy_some_files so that the testsuite passes again.  We'll
have to find a better way of handling serial numbers in libtool
macro files.
  
  --- orig/libtoolize.m4sh
  +++ mod/libtoolize.m4sh
  @@ -1101,7 +1101,8 @@
 func_verbose Not copying \`$m4dir/ltdl.m4', libltdl not used.
   fi
   
  -func_copy_some_files $pkgmacro_files $aclocaldir $m4dir
  +func_copy_some_files $pkgmacro_files $aclocaldir \
  +  $m4dir func_serial_update
 fi
   
 $opt_quiet || func_check_macros
  
  
  
- -- 
Gary V. Vaughan  ())_.  [EMAIL PROTECTED],gnu.org}
Research Scientist   ( '/   http://tkd.kicks-ass.net
GNU Hacker   / )=   http://www.gnu.org/software/libtool
Technical Author   `(_~)_   http://sources.redhat.com/autobook
_
This patch notification generated by tlaapply version 1.0
http://tkd.kicks-ass.net/arch/[EMAIL PROTECTED]/cvs-utils--tla--1.0
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (Darwin)

iD8DBQFDX5DrFRMICSmD1gYRAndQAKCkPxRpugIo3U7aSvh/tt1vfgMH8QCZATrG
bulDd+8xLEjd+FtZfYVsWH4=
=DK7N
-END PGP SIGNATURE-

Re: [PATCH]: libtool-1.9f: Added option quiet - only errors and warnings go through, now

[Juergen Leising]

On Tue, Aug 02, 2005 at 05:29:54PM +0200, Ralf Wildenhues wrote:

(...)

 Well, you could just use
   make -s LIBTOOLFLAGS=--silent
 (portable make version:
   LIBTOOLFLAGS=--silent make -e -s
 or even
   LIBTOOLFLAGS=--silent; export LIBTOOLFLAGS; make -e -s
 ) which would not require the package author to change anything, or put
   LIBTOOLFLAGS = --silent
 in the respective Makefile.am(s)
 or even
   LIBTOOLFLAGS=--silent
   AC_SUBST(LIBTOOLFLAGS)
 in configure.ac to have it in all Makefile's.
 
 All of these possibilities are less intrusive than your patch, the first
 one even allows the user the choice instead of relying on the compiler.
 Maybe you can convince me why your patch would be better to use?

yes, you are right, I know them, but...

 OTOH, there is a different, and IMHO orthogonal component: even with
 --silent, libtool outputs a little bit of information (which I believe
 your patch works on as well).  The question is: Should we add another 
 option to be completely silent, or maybe just make --silent be
 completely silent?  What do you/the others think?

(...)

..., exactly, this is what my patch was meant to be about: 
Complete silence. It's really useful when you try and find
errors in third party software you are not too much familiar
with.

This has been a discussion among make developers and
users for a long time. And after having seen the default make
behaviour with kernel-2.6, I must say, the complete silence
version is the superior one.

But anyway, it's not that important. As I have seen in the
meantime, my patch still does not reach complete silence
(regarding install and uninstall). And you are absolutely right:
there are ways to enforce silence in any respect...

Bye, bye, 

Juergen

-- 

Re: [PATCH]: libtool-1.9f: Added option quiet - only errors and warnings go through, now

[Ralf Wildenhues]

Hi Juergen,

Sorry for the late response.

* Juergen Leising wrote on Tue, Jul 19, 2005 at 11:02:34PM CEST:
 
 I'd like to present a patch for libtool-1.9f, that introduces the
 quiet option, as, for example, in configure.ac:
 
 LT_INIT([dlopen quiet])
 
 Additionally, the patch adjusts the output behaviour of libtool a
 little bit to what is usual in make/automake. That means, if I type in make
 -s, only warnings and errors are displayed, and any informational output,
 such as all those gcc options, is suppressed. 
 
 This is quite useful, if you want/have to debug buggy software, because this 
 way 
 it is optically easier to focus on all the warnings about sloppy source code.
 
 Opposedly to what is already contained in ltmain.sh, I do not
 make a difference between whether or not we have already compiled a pic 
 object.
 Instead, my quiet redirects every output, that would have been sent to 
 stdout, 
 to /dev/null. And everything, that is sent to stderr, keeps its way and still
 gets through to the screen, for instance.
*snip*
 I'm sure I am not the first one who has dealt with that problem, 
 as more and more people are unhappy with too much make output. 
 But I couldn't find a solution in google, and after all, writing that
 simple patch on my own was faster than searching for hours.

Well, you could just use
  make -s LIBTOOLFLAGS=--silent
(portable make version:
  LIBTOOLFLAGS=--silent make -e -s
or even
  LIBTOOLFLAGS=--silent; export LIBTOOLFLAGS; make -e -s
) which would not require the package author to change anything, or put
  LIBTOOLFLAGS = --silent
in the respective Makefile.am(s)
or even
  LIBTOOLFLAGS=--silent
  AC_SUBST(LIBTOOLFLAGS)
in configure.ac to have it in all Makefile's.

All of these possibilities are less intrusive than your patch, the first
one even allows the user the choice instead of relying on the compiler.
Maybe you can convince me why your patch would be better to use?

OTOH, there is a different, and IMHO orthogonal component: even with
--silent, libtool outputs a little bit of information (which I believe
your patch works on as well).  The question is: Should we add another 
option to be completely silent, or maybe just make --silent be
completely silent?  What do you/the others think?

As another note (_not_ meant to be flaming): I know two widely used
editors which are really good at filtering warning/error messages from
compilers, with minimal setup.

Cheers,
Ralf

Re: [PATCH]: libtool-1.9f: Added option quiet - only errors and warnings go through, now

[Ralf Wildenhues]

* Ralf Wildenhues wrote on Tue, Aug 02, 2005 at 05:29:54PM CEST:
 
 Well, you could just use
   make -s LIBTOOLFLAGS=--silent

 which would not require the package author to change anything, or put
   LIBTOOLFLAGS = --silent
 in the respective Makefile.am(s)

Sorry, the following part was wrong:

 or even
   LIBTOOLFLAGS=--silent
   AC_SUBST(LIBTOOLFLAGS)
 in configure.ac to have it in all Makefile's.

Use
  AM_LIBTOOLFLAGS=--silent
  AC_SUBST(AM_LIBTOOLFLAGS)

instead.

Cheers,
Ralf

Re: Patch libtool for m4 cvs in mingw/msys

[earnie]

Ralf Wildenhues Ralf.Wildenhues at gmx.de writes:

  
  ../m4/configure -C --prefix=/usr --disable-nls --disable-shared
  
  works. So there is no need to do this patch, just delete 
  /etc/config.site.
 
 Who created /etc/config.site (resp. which software package contains the
 one you had installed) and what are its contents?
 

I did, a long time ago.  It was to resolve issues in older versions of libtool.
 The /etc/config.site will disappear in the next release of MSYS.

I removed it from my environment sometime ago and tend to forget that it is
included in the releases.

Earnie

Re: Patch libtool for m4 cvs in mingw/msys

[Ralf Wildenhues]

Hi Earnie,

* earnie wrote on Tue, Jun 28, 2005 at 02:16:54AM CEST:
 Ralf Wildenhues Ralf.Wildenhues at gmx.de writes:
  
  Who created /etc/config.site (resp. which software package contains the
  one you had installed) and what are its contents?
  
 
 I did, a long time ago.  It was to resolve issues in older versions of 
 libtool.
  The /etc/config.site will disappear in the next release of MSYS.

OK.  Thanks for doing this!

Cheers,
Ralf

Re: Patch libtool for m4 cvs in mingw/msys

[Ralf Wildenhues]

Hi Peter, heromyth,

Sorry for the late response.

* Peter Ekberg wrote on Sun, Jun 19, 2005 at 09:31:27PM CEST:
 Ralf Wildenhues wrote:
  heromyth wrote:
   works. So there is no need to do this patch, just delete 
   /etc/config.site.
  
  Who created /etc/config.site (resp. which software package 
  contains the one you had installed) and what are its contents?
 
 I think the one on my system -- currently renamed to
 /etc/config.shite :-)

  configure CONFIG_SITE=
should do as well.

 -- was installed by the MinGW
 installation (i.e. gcc et al.) for MSYS.

Hmm.  Would an MSYS update be able to overwrite/replace/remove it?
(Yes, I know next to nothing about MSYS, sorry.)

 Contents:
*snip*
 lt_cv_sys_global_symbol_pipe=${lt_cv_sys_global_symbol_pipe=}
 lt_cv_sys_path_separator=${lt_cv_sys_path_separator=:}

Hmm.  Both of these are problematic, at least.  Even without using MSVC.

 I was just about to ask nicely on the MinGW list to have it
 zapped since it interferes with my MSYS+MSVC patch, and I
 can't for the world figure out what good it does...

That might be a good idea, yes.

Thanks,
Ralf

Patch libtool for m4 cvs in mingw/msys

[heromyth]

Recently I use Libtool CVS to compile M4 CVS in mingw/msys.I have 
configureed M4 like this:

../m4/configure -C --prefix=/usr --disable-nls --disable-shared

When I make it and get these message:

/bin/sh ./libtool --tag=CC   --mode=link gcc  -O2 -no-undefined 
-export-dynamic -dlpreopen force -dlpreopen modules/m4.la -dlpreopen 
modules/traditional.la -dlpreopen modules/gnu.la  -o src/m4.exe 
src/src_m4-getopt.o src/src_m4-getopt1.o src/src_m4-version-etc-fsf.o 
src/src_m4-version-etc.o src/src_m4-main.o src/src_m4-freeze.o 
src/src_m4-stackovf.o m4/libm4.la
libtool: link: not configured to extract global symbols from dlpreopened 
files
libtool: link: gcc -O2 -o src/m4.exe src/src_m4-getopt.o 
src/src_m4-getopt1.o src/src_m4-version-etc-fsf.o 
src/src_m4-version-etc.o src/src_m4-main.o src/src_m4-freeze.o 
src/src_m4-stackovf.o -Wl,--export-dynamic  modules/.libs/m4.a 
modules/.libs/traditional.a modules/.libs/gnu.a 
/home/zxp/savannah/dist-m4-mingw/m4/.libs/libm4.a m4/.libs/libm4.a 
/usr/lib/libltdl.dll.a
src/src_m4-main.o:main.c:(.text+0x1bb): undefined reference to 
`lt__PROGRAM__LTX_preloaded_symbols'



I trace into libtool, and found it is because of $global_symbol_pipe 
which is always empty. I don't konw where I am wrong. In file libtool 
(exactly speaking, it should be ltmain.sh or ltmain.m4sh) I change those:


if test -n $dlfiles$dlprefiles || test $dlself != no; then
  if test -n $NM  test -n $global_symbol_pipe; then
my_dlsyms=${my_outputname}S.c
  else
	func_error not configured to extract global symbols from dlpreopened 
files

  fi
fi

into these:

if test -n $dlfiles$dlprefiles || test $dlself != no; then
  if test -n $NM ; then
my_dlsyms=${my_outputname}S.c
if test -n $global_symbol_pipe ; then
			func_warning not configured to extract global symbols from 
dlpreopened files

fi
  fi
fi

Now I can make M4 sucessfully. Maybe I should to do more tests.

Re: Patch libtool for m4 cvs in mingw/msys

[heromyth]

fi

into these:

if test -n $dlfiles$dlprefiles || test $dlself != no; then
  if test -n $NM ; then
my_dlsyms=${my_outputname}S.c

Sorry for this line:

if test -n $global_symbol_pipe ; then

It should be:
  if test -z $global_symbol_pipe ; then
func_warning not configured to extract global symbols from 
dlpreopened files