[PATCH] libtool: Empty old_archive_from_new_cmds on OS/2

old_archive_from_new_cmds is not used at all. In addition, if this is defined static libs are not generated. This is a regression of commit e60044. * m4/libtool.m4: Do not define old_archive_from_new_cmds on OS/2. --- m4/libtool.m4 | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) dif

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

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:

[PATCH] libtool: Add support for SerenityOS

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

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

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 can

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

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

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

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 libto

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

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 -

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

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

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 cha

Re: [PATCH] libtool: remove bitrig support.

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.

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

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

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 -

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

* 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

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

* 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/bui

[PATCH] libtool

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 f

[PATCH] libtool: remove stray \ before -

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_caugh

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

Update of patch #9996 (project libtool): Status:None => Done Assigned to:None => growpotkin Open/Closed:Open => Closed

[PATCH] libtool with mingw hangs in func_convert_core_msys_to_w32

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

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

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

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

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/li

[PATCH] libtool: consistently pass compiler_flags for darwin

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

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

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

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

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.

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

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

[PATCH] libtool: pass more flags to the linker

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-

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

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..d97

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

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

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

May 4, 2016 at 2:41 PM To: "libt...@gnu.org<mailto:libt...@gnu.org>" mailto:libt...@gnu.org>>, "libtool-patches@gnu.org<mailto:libtool-patches@gnu.org>" mailto:libtool-patches@gnu.org>> Cc: Eric Bavier mailto:bav...@cray.com>> Subject: Re: [PATCH]

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

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

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(-)

[PATCH] libtool: fix clang linking with -fsanitize=address or -fsanitize=memory

From: Jeremy Huddleston Sequoia References: https://lists.gnu.org/archive/html/libtool/2014-04/msg00026.html * build-aux/ltmain.in (func_mode_link): Pass -fsanitize=* to the linker to allow trivial use of the clang address sanitizer Signed-off-by: Jeremy Huddleston Sequoia --- build-aux/ltma

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

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 | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)

[PATCH] libtool: handle the -pthread{,s} options for g++

As we are forced to pass -nostdlib to g++ for linking, this option expectedly disables the effectiveness of passed -pthread flag - so add the -lpthread explicitly to $deplibs to link correctly. References: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25460 https://bugzilla.redhat.com/show_bug.cgi?i

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

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

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

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 Date: Mon, 11 Nov 2013 10:00:28 +0100 Subject: [PATCH] libt

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

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!) a

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

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

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

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

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

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

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

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

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

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 R

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

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

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

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

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

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 th

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

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

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

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

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

* 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 Stef

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

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 m

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

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 +# unreasonab

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

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 whe

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

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 +: $

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

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="y

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

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. V

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

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 rar

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

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 X

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

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.

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

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 importan

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

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

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

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 pat

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

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

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

On 12/08/2011 08:03 AM, Gary V. Vaughan wrote: Any additional forks will slow down the script and should be avoided on all platforms. Agreed. Following up just because "slow down" is not a number: touch a.c time (for x in {1..100}; do ./libtool --mode=compile --tag=CC gcc -c -o a.lo a.c;

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

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

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

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 buil

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

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 s

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

Hi Eric. On Thursday 08 December 2011, Eric Blake wrote: > > 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 t

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

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 script

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

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 t

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

On 9/5/2011 12:08 PM, Peter O'Gorman wrote: 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 :-) Peter, this works for me. Dave -- John David Anglindave.ang...@bell.net

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

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 m

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

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 libtool

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

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. Woul

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

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 appropria

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

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/

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

Ping? 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

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

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 PR

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

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

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

* 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 pleas

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

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.

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

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

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

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 p

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

* 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 wro

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

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

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

Hello everybody, 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. Tha

Re: Patch libtool for m4 cvs in mingw/msys

Hi Earnie, * earnie wrote on Tue, Jun 28, 2005 at 02:16:54AM CEST: > Ralf Wildenhues 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 i

Re: Patch libtool for m4 cvs in mingw/msys

Ralf Wildenhues 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) a

Re: Patch libtool for m4 cvs in mingw/msys

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 so

Re: Patch libtool for m4 cvs in mingw/msys

Ralf Wildenhues wrote: Hi heromyth, * heromyth wrote on Fri, Jun 17, 2005 at 05:06:05PM CEST: heromyth wrote: 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 I trace into libtool,

RE: Patch libtool for m4 cvs in mingw/msys

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

Re: Patch libtool for m4 cvs in mingw/msys

Hi heromyth, * heromyth wrote on Fri, Jun 17, 2005 at 05:06:05PM CEST: > heromyth wrote: > >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 > > > >I trace into libtool, and found

Re: Patch libtool for m4 cvs in mingw/msys

heromyth wrote: 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 I trace into libtool, and found it is because of $global_symbol_pipe which is always empty. I don't konw where I

Re: Patch libtool for m4 cvs in mingw/msys

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

Patch libtool for m4 cvs in mingw/msys

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 f