Re: [libtool-2.2.2] testsuite on NFS mount on AIX

On Mon, 2008-04-21 at 09:29 +0200, Michael Haubenwallner wrote: On Sat, 2008-04-19 at 18:40 +0200, Ralf Wildenhues wrote: Hello Michael, * Michael Haubenwallner wrote on Fri, Apr 18, 2008 at 04:59:43PM CEST: when doing the libtool testsuite in some NFS mounted directory on AIX

[2.2.7a] (patch) AIX can statically link against shared libraries

following up http://lists.gnu.org/archive/html/bug-libtool/2008-12/msg6.html started at http://lists.gnu.org/archive/html/bug-libtool/2008-11/msg00082.html On Tue, 2008-12-09 at 06:51 +0100, Ralf Wildenhues wrote: * Michael Haubenwallner wrote on Mon, Dec 08, 2008 at 11:19:41PM CET: On Mon

Re: [2.2.7a] (patch) AIX can statically link against shared libraries

On Thu, 2008-12-18 at 18:09 +0100, Michael Haubenwallner wrote: following up http://lists.gnu.org/archive/html/bug-libtool/2008-12/msg6.html started at http://lists.gnu.org/archive/html/bug-libtool/2008-11/msg00082.html + _LT_TAGVAR(lt_prog_compiler_shared_as_static, $1

DESTDIR install on hppa-hpux

b01a42f..4999ea3 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,15 @@ +2009-05-26 Michael Haubenwallner michael.haubenwall...@salomon.at + + Fix DESTDIR install for hppa-hpux10 and hppa-hpux11. + * libltdl/m4/libtool.m4: Set hardcode_into_libs=yes. + Set hardcode_minus_L back

hppa64-,ia64-hpux does not support 'hardcode_shlibpath_var'

Hi, another minor one: while doing the DESTDIR patch for hppa-hpux, I've noticed that 'hardcode_shlibpath_var=no' is wrong for hppa*64|ia64*, it needs to be 'unsupported' to allow for PASSing tests/demo-hardcode.test. While it is correct that LD_LIBRARY_PATH is not hardcoded, the native linker

Re: DESTDIR install on hppa-hpux

On Wed, 2009-06-03 at 20:54 +0200, Ralf Wildenhues wrote: With this patch, 10 tests (demo-nofast.test to depdemo-unst.test) change from SKIP to PASS, and both Simple DESTDIR install and DESTDIR with in-package deplibs (destdir.at) change from expected failure to ok, for the 32bit hppa

Re: DESTDIR install on hppa-hpux

On Thu, 2009-06-04 at 23:45 +0200, Ralf Wildenhues wrote: * Michael Haubenwallner wrote on Thu, Jun 04, 2009 at 01:35:11PM CEST: On Wed, 2009-06-03 at 20:54 +0200, Ralf Wildenhues wrote: The most important part of the fix is already suggested in comments around 'hardcode_minus_L=yes

Re: DESTDIR install on hppa-hpux

On Thu, 2009-06-04 at 23:45 +0200, Ralf Wildenhues wrote: * Michael Haubenwallner wrote on Thu, Jun 04, 2009 at 01:35:11PM CEST: On Wed, 2009-06-03 at 20:54 +0200, Ralf Wildenhues wrote: The most important part of the fix is already suggested in comments around 'hardcode_minus_L=yes

Re: DESTDIR install on hppa-hpux

On Sun, 2009-06-14 at 16:21 +0200, Ralf Wildenhues wrote: + Set hardcode_libdir_flag_spec_ld along direct use of $LD only (hpux10). ... this line is problematic, because ... Hmm, ... @@ -4713,20 +4716,20 @@ _LT_EOF hpux10*) if test $GCC = yes test $with_gnu_ld =

[libtool 2.2.7a] testsuite: ... 80 ... failed

Hi, Attached patch turns 80: build tree relpaths (deplibs-ident.at) from FAIL to XFAIL for hppa64-hpux. While hppa-hpux (32bit) is explicitly mentioned to PASS this test, hppa64-hpux should not match there and be treated like others instead. Thanks! /haubi/ diff --git a/tests/deplibs-ident.at

Re: DESTDIR install on hppa-hpux

Hi Ralf, On Fri, 2009-06-12 at 21:57 +0200, Michael Haubenwallner wrote: Hmm. This does open a small security issue, no? That's precisely the reason we haven't gone this way before. Asking HP people (or more carefully reading the manpage) does help: The linker does have the +cdp

Re: DESTDIR install on hppa-hpux #3

On Wed, 2009-06-24 at 11:25 +0200, Michael Haubenwallner wrote: On Wed, 2009-05-27 at 00:16 +0200, Michael Haubenwallner wrote: Hi, now I've managed to get 'make install DESTDIR=...' working on hppa-hpux10 and hppa-hpux11 with libtool. But wait, there's another subtlety: When

Re: DESTDIR install on hppa-hpux #3

On Tue, 2009-06-30 at 20:35 +0200, Ralf Wildenhues wrote: Hello Michael, I'm pretty short on review time ATM; sorry for not providing a detailed review. No problem. It's just that the hpux10.20 box is shot down tomorrow, so I cannot test this platform any more. * Michael Haubenwallner

Re: DESTDIR install on hppa-hpux #4

On Wed, 2009-07-01 at 16:04 +0200, Michael Haubenwallner wrote: No problem. It's just that the hpux10.20 box is shot down tomorrow, so I cannot test this platform any more. The hpux10.20 box finally has been brought down now, and I have less hope to get it up again even for testing only

[PATCH] Correctly concat commands when export_symbols_cmds starts with some 'word'.

with shared library versioning support for AIX. Thank you! /haubi/ diff --git a/ChangeLog b/ChangeLog index dcfab26..aa5c9a3 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,11 @@ +2011-06-22 Michael Haubenwallner michael.haubenwall...@salomon.at + + Correctly concat commands when

Re: [PATCH] Correctly concat commands when export_symbols_cmds starts with some 'word'.

On 06/27/2011 11:12 PM, Ralf Wildenhues wrote: Hi Michael, * Michael Haubenwallner wrote on Mon, Jun 27, 2011 at 04:28:38PM CEST: Concatening commands breaks when export_symbols_cmds starts with something like dump, which does not need another shell expansion step. Instead, it is merged

Re: [PATCH] Correctly concat commands when export_symbols_cmds starts with some 'word'.

On 06/28/2011 12:33 PM, Michael Haubenwallner wrote: Sample 2 (which breaks): export_symbols_cmds='dump ...' Step 0: eval concat_cmds=\\$concat_cmds$export_symbols_cmds\ # the original line Step 1: eval 'concat_cmds=$concat_cmdsdump ...' # concat_cmds not expanded yet Step 2

[PATCH] give the -no-undefined flag an effect with AIX runtime linking enabled

switch useless when runtime linking is active. Thank you! diff --git a/ChangeLog b/ChangeLog --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,19 @@ +2011-06-29 Michael Haubenwallner michael.haubenwall...@salomon.at + + With AIX runtime linking, undefined symbols are allowed by default

[PATCH] Respect CONFIG_SHELL in make dist.

* Makefile.am: Set CONFIG_SHELL for subdir-configure during 'make dist'. --- Makefile.am |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/Makefile.am b/Makefile.am index c55dfdd..85cf654 100644 --- a/Makefile.am +++ b/Makefile.am @@ -329,7 +329,7 @@ $(DIST_MAKEFILE_LIST):

[PATCH 00/12] Improve AIX support: libltdl, filename-based versioning.

Hi, here's a set of patches to fix the two major problems with current AIX support in libtool, that is: *) libltdl: lt_dlopen() does work /with/ runtime linking (LDFLAGS=-brtl) only. *) libtool: /Without/ runtime linking, there is some versioning support, but still far from being ideal for

[PATCH 01/12] Support loading shared library archive members.

AIX supports shared objects as members of archive libraries, loadable with dlopen using the RTLD_MEMBER flag. * libltdl/ltdl.c: For AIX, define LT_SHARED_LIB_MEMBER to hold the parentheses used to identify the shared archive member. (lt_dlopenadvise) When LT_SHARED_LIB_MEMBER is defined, allow for

[PATCH 11/12] No cross-library undefined symbols test on AIX.

While AIX does support undefined symbols in general, undefined symbols in one shared library do not trigger another shared library to be marked as needed by the linker. * tests/template.at: Skip test with undef syms across libraries on AIX. --- tests/template.at |6 +- 1 files changed, 5

[PATCH 06/12] Drop useless symlinks with AIX runtime linking.

On AIX, the standalone Shared Object we create when runtime linking is active does not support versioning at all, so the versioning symlinks are plain useless. * m4/libtool.m4: (library_names_spec) No versioning with AIX runtime linking. --- m4/libtool.m4 |4 ++-- 1 files changed, 2

[PATCH 08/12] Implement enable/disable aix-soname options.

Support filename-based shared library versioning on AIX with the lib.so library filename extension, which is used with runtime linking only. Runtime linking is enabled by the -brtl linker flag for executables and the -G linker flag for Shared Objects. (aix-soname=no): Default, also known as

[PATCH 05/12] AIX runtime linking allows undef syms by default.

On AIX, when runtime linking is active, undefined symbols are allowd by default. Additionally, the '-G' linker flag needs to be specified before the '-bernotok' and any other user-defined linker flag, or '-G' would override some of them again. * m4/libtool.m4: (no_undefined_flag) Define for AIX

[PATCH 12/12] Set aix-soname=yes as default.

--- m4/ltoptions.m4 |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/m4/ltoptions.m4 b/m4/ltoptions.m4 index 6f53562..95c8eed 100644 --- a/m4/ltoptions.m4 +++ b/m4/ltoptions.m4 @@ -83,7 +83,7 @@ m4_if([$1],[LT_INIT],[ _LT_UNLESS_OPTIONS([LT_INIT], [fast-install

[PATCH 07/12] Declare enable/disable aix-soname options.

Declare filename based shared library versioning on AIX. * m4/ltoptions.m4: (_LT_ENABLE_AIX_SONAME) New. Provides --enable-aix-soname commandline option. Declares the 'shared_archive_member_spec' libtool variable. (_LT_SET_OPTIONS) Add LT_INIT options aix-soname, disable-aix-soname. Default is

[PATCH 02/12] Prepare -dlopen option for shared archive members.

* build-aux/ltmain.m4sh: (func_mode_execute) For the -dlopen option, when testing if the file to be dlopen'ed exists, strip the optional shared archive member (seen on AIX) from dlname first. --- build-aux/ltmain.m4sh | 14 -- 1 files changed, 12 insertions(+), 2 deletions(-) diff

[PATCH 10/12] Detect XFAIL based on hardcode configuration.

* tests/deplibs-ident.at: To define whether this test should XFAIL, use hardcode_action, hardcode_direct, hardcode_direct_absolute configuration settings instead of platforms aix, hppa-hpux, interix or openbsd. --- tests/deplibs-ident.at | 11 +++ 1 files changed, 7 insertions(+), 4

[PATCH 09/12] Run versioning checks on aix with 'aix-soname'.

* tests/versioning.at: On AIX, when shared_archive_member_spec is defined, we can run the versioning check. --- tests/versioning.at |9 + 1 files changed, 5 insertions(+), 4 deletions(-) diff --git a/tests/versioning.at b/tests/versioning.at index b66c816..226b329 100644 ---

Re: [PATCH 00/12] Improve AIX support: libltdl, filename-based versioning.

On 10/02/2012 05:34 PM, Michael Haubenwallner wrote: here's a set of patches to fix the two major problems with current AIX support in libtool, that is: *) libltdl: lt_dlopen() does work /with/ runtime linking (LDFLAGS=-brtl) only. *) libtool: /Without/ runtime linking, there is some

[PATCH] question mark is extended regex for non-GNU grep

Accepting \? for at-most-once in basic regex is a GNU grep extension, not accepted by AIX grep for example. * tests/libtool.at: Need EGREP for ? operator, and ? without \ then. With EGREP, need one more \ for $. --- tests/libtool.at | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff

[PATCH] Do not test undef symbols across shlibs on AIX.

On AIX, undefined symbols across shared libraries can work only when the main program explicitly exports those symbols. As this is bad practice anyway and -no-undefined should be preferred, we skip this. * tests/template.at: Skip test with undef syms across libraries on AIX. --- tests/template.at

Re: [PATCH] question mark is extended regex for non-GNU grep

On 11/21/2014 03:06 PM, Eric Blake wrote: On 11/21/2014 05:11 AM, Michael Haubenwallner wrote: Accepting \? for at-most-once in basic regex is a GNU grep extension, not accepted by AIX grep for example. * tests/libtool.at: Need EGREP for ? operator, and ? without \ then. With EGREP, need one

[PATCH] AIX: Optional filename-based shlib versioning

Support filename-based shared library versioning on AIX with the lib.so library filename extension, which is used with runtime linking only. Runtime linking is enabled by the -brtl linker flag for executables and the -G linker flag for Shared Objects. The behaviour is similar to Linux/SVR4

Re: [PATCH] AIX: Optional filename-based shlib versioning

Hi, for the curious, this is how I've done the testing: On 11/24/2014 02:09 PM, Michael Haubenwallner wrote: Support filename-based shared library versioning on AIX with the lib.so library filename extension, which is used with runtime linking only. (--with-aix-soname=aix): Default

Re: [PATCH] AIX: Optional filename-based shlib versioning

On 12/03/2014 11:09 PM, Gary V. Vaughan wrote: Hi Michael, I sorry I forgot to thank you for this patch, which I applied in time for the recent 2.4.4 release. On Nov 24, 2014, at 1:09 PM, Michael Haubenwallner michael.haubenwall...@ssi-schaefer.com wrote: Support filename-based shared

Re: [PATCH] AIX SONAME emulation, simplified implementation

Hi Daniel, (I'm not a libtool maintainer, but the author of current --with-aix-soname impl) On 06/24/2015 03:34 PM, Daniel Ruoso (BLOOMBERG/ 731 LEX) wrote: This patch offers a simplified implementation of a SONAME-like behavior emulation. I've tried this variant of soname-emulation too, but

[PATCH 0/2] AIX: Do not rely on OBJECT_MODE env var being set.

Hi! While testing --with-aix-soname=[aix|both|svr4] libtool patches within gcc, I've discovered that gcc does not set OBJECT_MODE during multilib build. Instead, the only settings done are: CC='xgcc -maix64' CXX='xg++ -maix64', besides AR=$AR -X32_64 NM=$NM -X32_64 - which feels like a workaround

[PATCH 1/2] Fix func_echo_all inside configure.

* m4/libtool.m4 (func_echo_all): Properly get $* through m4. --- m4/libtool.m4 | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/m4/libtool.m4 b/m4/libtool.m4 index a3bc337..c42a418 100644 --- a/m4/libtool.m4 +++ b/m4/libtool.m4 @@ -1218,7 +1218,7 @@ fi # Invoke $ECHO with all

[PATCH 2/2] AIX: Do not rely on OBJECT_MODE env var being set.

To compile 64-bit, AIX toolchain provides support to set the environment variable OBJECT_MODE=64, to avoid the need for changing anything else in the build environment. However, gcc ignores OBJECT_MODE, and does not set it while building gcc itself during its multi-lib build either. Also, CC may

Re: [PATCH] AIX SONAME emulation, simplified implementation

(now with my correct From: address, sorry) Hi Daniel, (I'm not a libtool maintainer, but the author of current --with-aix-soname impl) On 06/24/2015 03:34 PM, Daniel Ruoso (BLOOMBERG/ 731 LEX) wrote: This patch offers a simplified implementation of a SONAME-like behavior emulation. I've

Re: [PATCH] AIX SONAME emulation, simplified implementation

Hi Daniel, On 07/07/2015 04:30 PM, Daniel Ruoso (BLOOMBERG/ 731 LEX) wrote: From: michael.haubenwall...@ssi-schaefer.com At: Jul 6 2015 10:50:50 On 06/24/2015 03:34 PM, Daniel Ruoso (BLOOMBERG/ 731 LEX) wrote: This patch offers a simplified implementation of a SONAME-like behavior

Re: [PATCH 2/2] AIX: Do not rely on OBJECT_MODE env var being set.

Patch updated to conform to recent styleguide checks. Thanks! On 05/22/2015 01:14 PM, Michael Haubenwallner wrote: > To compile 64-bit, AIX toolchain provides support to set the environment > variable OBJECT_MODE=64, to avoid the need for changing anything else in > the build environment

[PATCH PING] rebased AIX-driven libtool improvement patches

Hi Pavel, as requested, here's two sets of rebased improvement patches to simplify fixing AIX problems (at least), to be subsequently imported into gcc. The original posts were: 1: http://lists.gnu.org/archive/html/libtool-patches/2015-05/msg1.html 2:

[PATCH 1/4] Fix func_echo_all inside configure.

* m4/libtool.m4 (func_echo_all): Properly get $* through m4. --- m4/libtool.m4 | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/m4/libtool.m4 b/m4/libtool.m4 index ee292af..7b8b591 100644 --- a/m4/libtool.m4 +++ b/m4/libtool.m4 @@ -1218,7 +1218,7 @@ fi # Invoke $ECHO with all

[PATCH 3/4] Use POSIX nm to simplify AIX export_symbols_cmds.

* m4/libtool.m4 (LT_PATH_NM): Detect POSIX-compatible nm for AIX. In BSD mode, the AIX nm does not tell whether a symbol is weak, need to use POSIX mode instead. (_LT_CMD_GLOBAL_SYMBOLS): Support POSIX-compatible nm. Reorder to allow for platform specific hooks during transformation of

[PATCH 4/4] AIX: Stop exporting any _GLOBAL__ symbol.

* m4/libtool.m4 (_LT_LINKER_SHLIBS): On AIX, GNU g++ generates _GLOBAL__* symbols as, amongst others, landing pads for C++ exceptions. These symbols must not be exported from shared libraries, or exception handling may break for applications with runtime linking enabled. --- m4/libtool.m4 | 2 ++

[PATCH 2/4] AIX: Do not rely on OBJECT_MODE env var being set.

To compile 64-bit, AIX toolchain provides support to set the environment variable OBJECT_MODE=64, to avoid the need for changing anything else in the build environment. However, gcc ignores OBJECT_MODE, and does not set it while building gcc itself during its multi-lib build either. Also, CC may

Re: [PATCH 3/4] Use POSIX nm to simplify AIX export_symbols_cmds.

in your version. > > On 2016-03-10 10:01, Michael Haubenwallner wrote: >> * m4/libtool.m4 (LT_PATH_NM): Detect POSIX-compatible nm for AIX. In >> BSD mode, the AIX nm does not tell whether a symbol is weak, need to use >> POSIX mode instead. >> (_LT_CMD_GLOBAL_SY

Re: [PATCH 1/4] Fix func_echo_all inside configure.

On 03/10/2016 05:44 PM, Eric Blake wrote: > On 03/10/2016 02:01 AM, Michael Haubenwallner wrote: >> * m4/libtool.m4 (func_echo_all): Properly get $* through m4. >> --- >> m4/libtool.m4 | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> fun

Re: [PATCH 3/4] Use POSIX nm to simplify AIX export_symbols_cmds.

On 03/12/2016 12:13 AM, Peter Rosin wrote: > On 2016-03-11 22:22, Michael Haubenwallner wrote: >> Hi Peter, >> >> thanks for looking at the patch! >> >> On 03/10/2016 12:29 PM, Peter Rosin wrote: >>> Hi Michael, >>> >>> I had a l

[PATCH] bump gl-mod/bootstrap for AIX sed

gl-mod/bootstrap: Update. bootstrap: Recreate. --- bootstrap| 10 +- gl-mod/bootstrap | 2 +- 2 files changed, 6 insertions(+), 6 deletions(-) diff --git a/bootstrap b/bootstrap index 82b28d7..d1f54d3 100755 --- a/bootstrap +++ b/bootstrap @@ -2302,20 +2302,20 @@ func_version ()

Re: [PATCH 2/4] AIX: Do not rely on OBJECT_MODE env var being set.

On 03/10/2016 10:01 AM, Michael Haubenwallner wrote: > To compile 64-bit, AIX toolchain provides support to set the environment > variable OBJECT_MODE=64, to avoid the need for changing anything else in > the build environment. However, gcc ignores OBJECT_MODE, and does not >

ping (regression fix) [PATCH] bump gl-mod/bootstrap for AIX sed

ling since commit 08c5524fb24b923ad91c2bdca836f1eafa56fd6c Author: Pavel Raiskup <prais...@redhat.com> Date: Tue Feb 23 00:38:39 2016 +0100 bootstrap: use the upstream repo as git module Thanks! /haubi/ On 03/15/2016 12:23 PM, Michael Haubenwallner wrote: > gl-mod/bootstrap:

Re: [PATCH 1/2] Use POSIX nm to simplify AIX export_symbols_cmds.

s odd. why aren't these > complementary? The awk argument is passed between ['], as it contains ["]. Escaping [\] the ['] is done outside any other string. Read as: _LT_TAGVAR(...)=['$NM ... | awk '][\']['{ ... }'][\'][' | sort ...'] Indeed I can add [] here if you like. Thanks! /haubi/ &

Re: [PATCH 1/2] Use POSIX nm to simplify AIX export_symbols_cmds.

On 03/21/2016 03:47 PM, David Edelsohn wrote: > On Mon, Mar 21, 2016 at 4:49 AM, Michael Haubenwallner > <michael.haubenwall...@ssi-schaefer.com> wrote: >> >> On 03/20/2016 01:04 AM, David Edelsohn wrote: >>> I agree with this in principle, but I'm not co

[PATCH 2/3] support POSIX nm, prefer POSIX nm for AIX

In BSD mode, the AIX nm does not tell whether a symbol is weak, we need to use POSIX mode instead. * m4/libtool.m4 (LT_PATH_NM): For AIX, search for nm supporting the -P flag (POSIX mode). When AIX nm is found, add the -C and -l flags. Add detection of POSIX compatible nm.

[PATCH 1/3] AIX: use proper ABI flags in search for toolchain

The native PowerPC AIX toolchain does accept only 32 bit objects by default. They either need the -X32_64 flag to accept both, or the OBJECT_MODE=64 environment variable to accept 64 bit only. We rely on the new gl_POWERPC_AIX_OBJECT_MODE early gnulib macro setting the

[PATCH 3/3] AIX: Stop exporting any _GLOBAL__ symbol.

* m4/libtool.m4 (_LT_LINKER_SHLIBS): On AIX, GNU g++ generates _GLOBAL__* symbols as, amongst others, landing pads for C++ exceptions. These symbols must not be exported from shared libraries, or exception handling may break for applications with runtime linking enabled. --- m4/libtool.m4 | 2 ++

[PATCH 1/2] Use POSIX nm to simplify AIX export_symbols_cmds.

* m4/libtool.m4 (LT_PATH_NM): Detect POSIX-compatible nm for AIX. In BSD mode, the AIX nm does not tell whether a symbol is weak, need to use POSIX mode instead. (_LT_CMD_GLOBAL_SYMBOLS): Support POSIX-compatible nm. Reorder to allow for platform specific hooks during transformation of

[PATCH 2/2] AIX: Stop exporting any _GLOBAL__ symbol.

* m4/libtool.m4 (_LT_LINKER_SHLIBS): On AIX, GNU g++ generates _GLOBAL__* symbols as, amongst others, landing pads for C++ exceptions. These symbols must not be exported from shared libraries, or exception handling may break for applications with runtime linking enabled. --- m4/libtool.m4 | 2 ++

Introducing support for POSIX-nm, required for AIX.

Hi! On AIX, when _GLOBAL__* symbols are exported from shared libraries, and the final executable is linked with runtime linking enabled, GNU C++ exception handling may break. Unfortunately, the command to create the list of exported symbols for AIX is quite complicated at the moment, not only

[patch #9313] _LT_SYS_DYNAMIC_LINKER: Untagged variable values may be inconsistent across tags.

URL: Summary: _LT_SYS_DYNAMIC_LINKER: Untagged variable values may be inconsistent across tags. Project: GNU Libtool Submitted by: haubi Submitted on: Thu 20 Apr 2017 04:25:04 PM CEST

[patch #9313] _LT_SYS_DYNAMIC_LINKER: Untagged variable values may be inconsistent across tags.

Additional Item Attachment, patch #9313 (project libtool): File name: 0001-check-dynamic-linker-characteristics-for-CC-only.patch Size:3 KB ___ Reply to this item at:

[patch #9341] testsuite.at: prefer diff --strip-trailing-cr

URL: Summary: testsuite.at: prefer diff --strip-trailing-cr Project: GNU Libtool Submitted by: haubi Submitted on: Wed 10 May 2017 04:24:08 PM CEST Category: None

[patch #9341] testsuite.at: prefer diff --strip-trailing-cr

Follow-up Comment #2, patch #9341 (project libtool): Then I'm wondering why libtool does actually support the cc_basename=cl with host_os=cygwin at all. Anyway, my final goal is beyond the MSVC toolchain: I'm about to rework the old patches

[patch #9349] libtool.m4: For MS dumpbin drop CR first.

URL: Summary: libtool.m4: For MS dumpbin drop CR first. Project: GNU Libtool Submitted by: haubi Submitted on: Tue 16 May 2017 08:46:49 AM CEST Category: None

[patch #9361] libtool.m4: preload valid C symbol names only

URL: Summary: libtool.m4: preload valid C symbol names only Project: GNU Libtool Submitted by: haubi Submitted on: Fri 26 May 2017 08:30:24 PM CEST Category: None

[patch #9313] _LT_SYS_DYNAMIC_LINKER: Untagged variable values may be inconsistent across tags.

Follow-up Comment #1, patch #9313 (project libtool): On another thought: Is is advised to configure libtool itself with F77=no and FC=no when these would be found by PATH search but are not msvc based ones? ___ Reply to this item at:

[patch #9349] libtool.m4: For MS dumpbin drop CR first.

Follow-up Comment #1, patch #9349 (project libtool): This patch still is necessary when using Cygwin as build environment to use MSVC cl.exe (or similar, e.g. icc.exe), which uses dumpbin instead of nm. After setting environment variables to locate MSVC 2010, the configure options used are: >

[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

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