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

2019-10-14 Thread 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

2019-10-09 Thread 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 #9349] libtool.m4: For MS dumpbin drop CR first.

2019-10-09 Thread Michael Haubenwallner
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:
> ./configure --host=i686-msvc10.0-mingw32 GCJ=no GOC=no F77=no FC=no CC=cl
CXX=cl OBJDUMP=no NM=no CFLAGS= CXXFLAGS=
Adding rebased patch.

(file #47630)
___

Additional Item Attachment:

File name: 0001-libtool.m4-For-MS-dumpbin-drop-CR-first.patch Size:1 KB
   




___

Reply to this item at:

  

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




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

2017-05-26 Thread Michael Haubenwallner
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
Priority: 5 - Normal
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any

___

Details:

Hi,

the current $global_symbol_pipe for 'MS dumpbin' yields symbol names starting
with @ or ? on purpose.

As these symbol names are not valid C symbol names, this breaks following test
cases with 64bit MSVC compiler, and even with 32bit since MSVC 14 (=VS 2015):

 27: link against a preloaded static library
 28: build and dynamically load a module
 29: preload static and dynamic module
 31: disable fast install
 32: force PIC objects
 34: hardcoding library path
 36: uninstalled libraries have priority
 37: linking with long file names

Attached patches does fix these test cases for 64bit MSVC (tested 10.0, 12.0,
14.0, 15.0) as well as for 32bit MSVC 14.0 and 15.0 (=VS 2017), in that it
does accept only valid C symbol names for ltdl preloading.

Thanks!
/haubi/



___

File Attachments:


---
Date: Fri 26 May 2017 08:30:24 PM CEST  Name:
0001-libtool.m4-preload-valid-C-symbol-names-only.patch  Size: 3kB   By: haubi



___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/




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

2017-05-16 Thread Michael Haubenwallner
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
(http://lists.gnu.org/archive/html/libtool-patches/2008-02/msg00014.html)
adding support for the MSVC wrapper called "Parity" (at
https://github.com/haubi/parity/ for now), which does:
* not require specific environment variables for MSVC, but can find MSVC from
the Registry
* convert Unix to Windows path names as necessary
* provide GCC like commandline options
* provide gcc3-style dependency tracking
* set up the final binary's std-stream mode to O_BINARY
* provide some additional system headers (stdint.h, dlfcn.h, ...)
* emulate some runtime loader features, on Linux known as embedded runpath,
embedded soname, LD_BIND_NOW, LD_LIBRARY_PATH, LD_PRELOAD
* probably more

We do use it on Cygwin (now, since Interix is gone) within Gentoo Prefix, to
maintain an ecosystem using the native MSVC toolchain, configured in the
"lying" way with --build=i586-pc-winnt --host=i586-pc-winnt - which is similar
to "multilib" actually.

That is, I'm about to prepare libtool patches to support the *-*-winnt host
triplet, which feels a lot more correct for MSVC than using --host=mingw32 -
and should support unwrapped cl.exe as well.

But as the application's O_BINARY setting may vary for host_os=winnt then, I
prefer to 'diff --strip-trailing-cr' rather than testing for another host_os -
or even current binary setting.

Thus the idea is to have the testsuite setup not depend on $host_os, but just
ignore CR if possible - as the test programs all have textual output only.

Thanks!
/haubi/

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/




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

2017-05-16 Thread Michael Haubenwallner
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
Priority: 5 - Normal
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any

___

Details:

On Cygwin, gawk-4.1.4-3 and newer do not treat the input stream as text any
more, leaving libtool behind with carriage return in symbol names.

Upstream gawk commit is:
http://git.savannah.gnu.org/cgit/gawk.git/commit/?id=5db38f775d9ba239e125d81dff2010a2ddacb48e

These tests switch back from FAILED to ok with MSVC and gawk-4.1.4-3 on
Cygwin:
 28: build and dynamically load a module
 29: preload static and dynamic module
 31: disable fast install
 32: force PIC objects
 34: hardcoding library path
 36: uninstalled libraries have priority
 37: linking with long file names

Thanks!
/haubi/



___

File Attachments:


---
Date: Tue 16 May 2017 08:46:49 AM CEST  Name:
0001-libtool.m4-For-MS-dumpbin-drop-CR-first.patch  Size: 1kB   By: haubi



___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/




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

2017-05-10 Thread Michael Haubenwallner
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
Priority: 5 - Normal
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any

___

Details:

On Cygwin, when using CC=cl.exe (MSVC) as the compiler, some test cases fail
just because of unexpected carriage return output from test binaries.

Fortunately, with GNU diff there is the --strip-trailing-cr flag, which allows
to easily get the libtool test suite agnostic to CR, independent of any host
triplet used:

If 'diff --help' tells about the --strip-trailing-cr flag, attached patch does
wrap the host diff command to add that flag for when run as 'diff -u' via
$at_diff in the test suite, in addition to stop adding CR to expected output
files for mingw.

This allows to succeed following test cases when run on Cygwin with MSVC
environment and these configure options: CC=cl CXX="cl /TP" GCJ=no GOC=no
F77=no FC=no NM=no CFLAGS= CXXFLAGS=

  27: link against a preloaded static library
  30: deplibs_check_method
  40: build and link against a static library
  41: build and link against a dynamic library
  42: build both static and dynamic
  43: allow_undefined_flag
  49: static library interdependencies
 112: dlloader API

Thanks!
/haubi/



___

File Attachments:


---
Date: Wed 10 May 2017 04:24:08 PM CEST  Name:
0001-testsuite.at-prefer-diff-strip-trailing-cr.patch  Size: 3kB   By: haubi
[PATCH] testsuite.at: prefer diff --strip-trailing-cr


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/




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

2017-05-02 Thread Michael Haubenwallner
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:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/




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

2017-04-20 Thread Michael Haubenwallner
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:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/




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

2017-04-20 Thread Michael Haubenwallner
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
Category: None
Priority: 5 - Normal
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any

___

Details:

Although _LT_SYS_DYNAMIC_LINKER does support the [TAG] argument, almost all of
the variables it does set are untagged variables.

While untagged variables are (expected to be) defined using the "C" language
compiler, their values apply for each other language (=tag) as well.

As _LT_SYS_DYNAMIC_LINKER is run for multiple tags, these untagged variables
are redefined again for no good reason. While this is not a problem by itself,
it is a needless slowdown for the configure script.

However, a problem does arise when their values change with different language
compilers, for example when using MSVC cl.exe as the C compiler (with Cygwin
as the POSIX system):

*./configure CC=cl.exe CXX='cl.exe /TP'* results in libname_spec='ltdl' for
the empty tag, which is incorporated into LTDLOPEN, causing libltdl/ltdl.c to
refer lt_ltdl__LTX_preloaded_symbols.

But subsequent checks for F77 and FC run _LT_SYS_DYNAMIC_LINKER with
$cc_basename != "cl.exe", causing libname_spec='libltdl', which finally ends
up in the libtool script, causing lt_libltdl__LTX_preloaded_symbols to be
generated.
Note "libltdl" != "ltdl" in the symbol name.

The error message seen here is:

   Creating library libltdl/.libs/libltdl.dll.lib and object
libltdl/.libs/libltdl.dll.exp
libltdl_libltdl_la-ltdl.obj : error LNK2019: unresolved external symbol
_lt_ltdl_LTX_preloaded_symbols referenced in function _lt_dlinit
libltdl/.libs/libltdl-7.dll : fatal error LNK1120: 1 unresolved externals
make[2]: *** [Makefile:1139: libltdl/libltdl.la] Error 2





___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/




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

2016-03-21 Thread Michael Haubenwallner
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.
(_LT_CMD_GLOBAL_SYMBOLS): Support POSIX-compatible nm.  Reorder to allow
for platform specific hooks during transformation of global_symbol_pipe
into C source code.  For AIX, set hook to transform even weak text
symbols as normal text symbols, like before with AIX nm in BSD mode.
For AIX, update symcode to support nm in any known mode.
(_LT_LINKER_SHLIBS): For AIX, use global_symbol_pipe to simplify forming
the export_symbols_cmds, add check for C++ to warn when nm fails to mark
symbols as weak.
---
 m4/libtool.m4 | 118 +++---
 1 file changed, 71 insertions(+), 47 deletions(-)

diff --git a/m4/libtool.m4 b/m4/libtool.m4
index 513e2ae..131dd48 100644
--- a/m4/libtool.m4
+++ b/m4/libtool.m4
@@ -3696,10 +3696,10 @@ _LT_DECL([], [want_nocaseglob], [1],
 
 # LT_PATH_NM
 # --
-# find the pathname to a BSD- or MS-compatible name lister
+# find the pathname to a BSD-, POSIX- or MS-compatible name lister
 AC_DEFUN([LT_PATH_NM],
 [AC_REQUIRE([AC_PROG_CC])dnl
-AC_CACHE_CHECK([for BSD- or MS-compatible name lister (nm)], lt_cv_path_NM,
+AC_CACHE_CHECK([for BSD-, POSIX- or MS-compatible name lister (nm)], 
lt_cv_path_NM,
 [if test -n "$NM"; then
   # Let the user override the test.
   lt_cv_path_NM=$NM
@@ -3720,10 +3720,11 @@ else
#   nm: unknown option "B" ignored
# Tru64's nm complains that /dev/null is an invalid object file
# MSYS converts /dev/null to NUL, MinGW nm treats NUL as empty
-   # AIX nm needs -X32_64 to accept both 32 and 64 bit objects
+   # AIX nm needs -X32_64 to accept both 32 and 64 bit objects,
+   # and never tells weakiness of symbols in BSD mode
tmp_nmflags=-B
if test no != "$gl_cv_powerpc_aix_object_mode"; then
- tmp_nmflags='-X32_64 -B'
+ tmp_nmflags='-X32_64 -P'
fi
case $build_os in
mingw*) lt_bad_file=conftest.nm/nofile ;;
@@ -3752,6 +3753,14 @@ else
 IFS=$lt_save_ifs
   done
   : ${lt_cv_path_NM=no}
+  if test no != "$lt_cv_path_NM" -a no != "$gl_cv_powerpc_aix_object_mode"; 
then
+# AIX nm needs the '-C' flag to disable demangling,
+# and the '-l' flag to tell the weakiness of symbols.
+case `$lt_cv_path_NM -V 2>&1` in
+*GNU* | *'with BFD'*) ;;
+*) lt_cv_path_NM="$lt_cv_path_NM -Cl" ;;
+esac
+  fi
 fi])
 if test no != "$lt_cv_path_NM"; then
   NM=$lt_cv_path_NM
@@ -3777,7 +3786,7 @@ else
 fi
 test -z "$NM" && NM=nm
 AC_SUBST([NM])
-_LT_DECL([], [NM], [1], [A BSD- or MS-compatible name lister])dnl
+_LT_DECL([], [NM], [1], [A BSD-, POSIX- or MS-compatible name lister])dnl
 
 AC_CACHE_CHECK([the name lister ($NM) interface], [lt_cv_nm_interface],
   [lt_cv_nm_interface="BSD nm"
@@ -3792,6 +3801,8 @@ AC_CACHE_CHECK([the name lister ($NM) interface], 
[lt_cv_nm_interface],
   cat conftest.out >_MESSAGE_LOG_FD
   if $GREP 'External.*some_variable' conftest.out > /dev/null; then
 lt_cv_nm_interface="MS dumpbin"
+  elif $GREP '^[[   ]]*_*some_variable[[]][[]]*[[BD]]' 
conftest.out > /dev/null; then
+lt_cv_nm_interface="POSIX nm"
   fi
   rm -f conftest*])
 ])# LT_PATH_NM
@@ -3957,8 +3968,30 @@ symcode='[[BCDEGRST]]'
 # Regexp to match symbols that can be accessed directly from C.
 sympat='\([[_A-Za-z]][[_A-Za-z0-9]]*\)'
 
+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'"
+  # 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_c_name_lib_hook="\
+  -e 's/^I .* \(lib.*\)$/  {\"\1\", (void *) 0},/p'\
+  -e 's/^I .* \(.*\)$/  {\"lib\1\", (void *) 0},/p'"
+else
+  # Disable hooks by default.
+  lt_cv_sys_global_symbol_to_import=
+  lt_cdecl_hook=
+  lt_c_name_hook=
+  lt_c_name_lib_hook=
+fi
+
 # Define system-specific variables.
 case $host_os in
+aix[[4-9]]*)
+  # in default mode, AIX nm with -l marks weak symbols by an extra '*'
+  symcode='[[BDLTVWZ\*]]'
+  lt_cdecl_hook=" -e 's/^W/T/p'" # weak text symbol
+  ;;
 aix*)
   symcode='[[BCDT]]'
   ;;
@@ -3999,23 +4032,6 @@ case `$NM -V 2>&1` in
   symcode='[[ABCDGIRSTW]]' ;;
 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'"
-  # 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_c_name_lib_hook="\
-  -e 

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

2016-03-21 Thread Michael Haubenwallner
* 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 ++
 1 file changed, 2 insertions(+)

diff --git a/m4/libtool.m4 b/m4/libtool.m4
index 131dd48..6039bea 100644
--- a/m4/libtool.m4
+++ b/m4/libtool.m4
@@ -5000,6 +5000,7 @@ m4_if([$1], [CXX], [
 # '[[BDLT]]*' with AIX nm in default mode (POSIX like)
 # '[[CVW]]'   with GNU nm in either BSD or POSIX mode
 _LT_TAGVAR(export_symbols_cmds, $1)='$NM -gp $libobjs $convenience | 
$global_symbol_pipe | $EGREP -v " ($exclude_expsyms)$" | awk '\''{ kw = "" } 
/^([[CVWZ]]|[[BDLT]]\*) / { kw = " weak" } { print $ 3 kw }'\'' | sort -u > 
$export_symbols'
+_LT_TAGVAR(exclude_expsyms, $1)='_GLOBAL_OFFSET_TABLE_|_GLOBAL__.*'
 ;;
   pw32*)
 _LT_TAGVAR(export_symbols_cmds, $1)=$ltdll_cmds
@@ -5446,6 +5447,7 @@ _LT_EOF
# symbols only, and the '-p' flag disables sorting to improve
# performance.  For the weak symbol handling see the CXX tag.
_LT_TAGVAR(export_symbols_cmds, $1)='$NM -gp $libobjs $convenience | 
$global_symbol_pipe | $EGREP -v " ($exclude_expsyms)$" | awk '\''{ kw = "" } 
/^([[CVWZ]]|[[BDLT]]\*) / { kw = " weak" } { print $ 3 kw }'\'' | sort -u > 
$export_symbols'
+   _LT_TAGVAR(exclude_expsyms, $1)='_GLOBAL_OFFSET_TABLE_|_GLOBAL__.*'
aix_use_runtimelinking=no
 
# Test if we are trying to use run time linking or normal
-- 
2.4.6




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

2016-03-21 Thread Michael Haubenwallner
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
gl_cv_powerpc_aix_object_mode configure variable, and then use the
proper abi flags to search for the PowerPC AIX tools, to ensure they
actually work with the object file format the compiler generates.
* gnulib: Bump, for the gl_POWERPC_AIX_OBJECT_MODE macro.
* m4/libtool.m4 (LT_INIT): Require gl_POWERPC_AIX_OBJECT_MODE.
(_LT_PROG_AR): When gl_cv_powerpc_aix_object_mode != no, use the -X32_64
flag to search for the ar tool.
(_LT_CMD_OLD_ARCHIVE): Ditto for strip, ranlib.
(LT_PATH_NM): Ditto for nm.
(LT_PATH_LD): When gl_cv_powerpc_aix_object_mode != no, use the -b32
or -b64 flag to search for the ld program.
(_LT_LINKER_SHLIBS): Instead of testing the shared_archive_member_spec
value, use gl_cv_powerpc_aix_object_mode directly.
* m4/ltoptions.m4 (_LT_WITH_AIX_SONAME): Instead of testing the
OBJECT_MODE environment variable, use gl_cv_powerpc_aix_object_mode to
define the shared_archive_member_spec value.
---
 gnulib  |  2 +-
 m4/libtool.m4   | 38 +++---
 m4/ltoptions.m4 |  4 +---
 3 files changed, 33 insertions(+), 11 deletions(-)

diff --git a/gnulib b/gnulib
index 5be7728..2575bf3 16
--- a/gnulib
+++ b/gnulib
@@ -1 +1 @@
-Subproject commit 5be7728cf7c0fb61be1ccbfbd302764ef7e6b72d
+Subproject commit 2575bf3fae3c42e4f90b95437a7692f52e0bf99d
diff --git a/m4/libtool.m4 b/m4/libtool.m4
index ee292af..513e2ae 100644
--- a/m4/libtool.m4
+++ b/m4/libtool.m4
@@ -61,6 +61,7 @@ esac
 AC_DEFUN([LT_INIT],
 [AC_PREREQ([2.62])dnl We use AC_PATH_PROGS_FEATURE_CHECK
 AC_REQUIRE([AC_CONFIG_AUX_DIR_DEFAULT])dnl
+AC_REQUIRE([gl_POWERPC_AIX_OBJECT_MODE])dnl
 AC_BEFORE([$0], [LT_LANG])dnl
 AC_BEFORE([$0], [LT_OUTPUT])dnl
 AC_BEFORE([$0], [LTDL_INIT])dnl
@@ -1491,7 +1492,11 @@ need_locks=$enable_libtool_lock
 # _LT_PROG_AR
 # ---
 m4_defun([_LT_PROG_AR],
-[AC_CHECK_TOOLS(AR, [ar], false)
+[if test no != "$gl_cv_powerpc_aix_object_mode"; then
+  AC_CHECK_TOOLS(AR, ["ar -X32_64"], false)
+else
+  AC_CHECK_TOOLS(AR, [ar], false)
+fi
 : ${AR=ar}
 _LT_DECL([], [AR], [1], [The archiver])
 
@@ -1543,11 +1548,19 @@ _LT_DECL([], [archiver_list_spec], [1],
 m4_defun([_LT_CMD_OLD_ARCHIVE],
 [_LT_PROG_AR
 
-AC_CHECK_TOOL(STRIP, strip, :)
+if test no != "$gl_cv_powerpc_aix_object_mode"; then
+  AC_CHECK_TOOL(STRIP, strip -X32_64, :)
+else
+  AC_CHECK_TOOL(STRIP, strip, :)
+fi
 test -z "$STRIP" && STRIP=:
 _LT_DECL([], [STRIP], [1], [A symbol stripping program])
 
-AC_CHECK_TOOL(RANLIB, ranlib, :)
+if test no != "$gl_cv_powerpc_aix_object_mode"; then
+  AC_CHECK_TOOL(RANLIB, ranlib -X32_64, :)
+else
+  AC_CHECK_TOOL(RANLIB, ranlib, :)
+fi
 test -z "$RANLIB" && RANLIB=:
 _LT_DECL([], [RANLIB], [1],
 [Commands used to install an old-style archive])
@@ -3293,6 +3306,9 @@ if test yes = "$GCC"; then
   while $ECHO "$ac_prog" | $GREP "$re_direlt" > /dev/null 2>&1; do
ac_prog=`$ECHO $ac_prog| $SED "s%$re_direlt%/%"`
   done
+  if test no != "$gl_cv_powerpc_aix_object_mode"; then
+   ac_prog="$ac_prog -b$gl_cv_powerpc_aix_object_mode"
+  fi
   test -z "$LD" && LD=$ac_prog
   ;;
   "")
@@ -3331,6 +3347,9 @@ AC_CACHE_VAL(lt_cv_path_LD,
 fi
   done
   IFS=$lt_save_ifs
+  if test no != "$gl_cv_powerpc_aix_object_mode"; then
+lt_cv_path_LD="$lt_cv_path_LD -b$gl_cv_powerpc_aix_object_mode"
+  fi
 else
   lt_cv_path_LD=$LD # Let the user override the test with a path.
 fi])
@@ -3701,13 +3720,18 @@ else
#   nm: unknown option "B" ignored
# Tru64's nm complains that /dev/null is an invalid object file
# MSYS converts /dev/null to NUL, MinGW nm treats NUL as empty
+   # AIX nm needs -X32_64 to accept both 32 and 64 bit objects
+   tmp_nmflags=-B
+   if test no != "$gl_cv_powerpc_aix_object_mode"; then
+ tmp_nmflags='-X32_64 -B'
+   fi
case $build_os in
mingw*) lt_bad_file=conftest.nm/nofile ;;
*) lt_bad_file=/dev/null ;;
esac
-   case `"$tmp_nm" -B $lt_bad_file 2>&1 | sed '1q'` in
+   case `"$tmp_nm" $tmp_nmflags $lt_bad_file 2>&1 | sed '1q'` in
*$lt_bad_file* | *'Invalid file or object type'*)
- lt_cv_path_NM="$tmp_nm -B"
+ lt_cv_path_NM="$tmp_nm $tmp_nmflags"
  break 2
  ;;
*)
@@ -5548,7 +5572,7 @@ _LT_EOF
_LT_TAGVAR(archive_expsym_cmds, 
$1)="$_LT_TAGVAR(archive_expsym_cmds, $1)"'~$CC '$shared_flag_aix' -o 
$output_objdir/$realname.d/$soname $libobjs $deplibs $wl-bnoentry 
'$compiler_flags_filtered'$wl-bE:$export_symbols$allow_undefined_flag~$AR 
$AR_FLAGS $output_objdir/$libname$release.a $output_objdir/$realname.d/$soname'
  fi
  if test aix != "$with_aix_soname"; then
-   _LT_TAGVAR(archive_expsym_cmds, 

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

2016-03-21 Thread Michael Haubenwallner

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 convinced that the patch
>>> itself is correct.
>>
>> Thanks!
>>
>>> I also would have split the MS-compatible part of the patch as a
>>> separate step.  It is not listed in the ChangeLog and just confuses
>>> the patch.
>>
>> This is just a reordering of existing code - these lines are removed
>> below, and the ChangeLog part is "Reorder to allow for platform specific
>> hooks during transformation of global_symbol_pipe into C source code."
>>
>>> I don't see that this emits TLS symbols.  Global TLS symbols are not
>>> in the symcode list.
>>
>> Isn't the "L" for TLS symbols?
>>
>> +symcode='[[BDLTVWZ]]'
> 
> Sorry, I was confused by the two cases for "aix" and the case for
> "GNU" within AIX.
> 
>>
>> But indeed I've failed to identify the symcode of "weak TLS" symbols,
>> except for "L*" with AIX nm in unspecified mode (nm -l, no -B or -P)
>> Neither AIX nm nor GNU nm docs explicitly tell about weak TLS symbols.
>> Is it possible for TLS symbols to be weak at all?

For GNU nm I've identified the "C" (common) symcode to be "weak" as well.

But still I'm unsure about TLS symbols: Always import them as "strong"?

>>> Global symbol pipe and exclude symbols somehow restricts the symbols
>>> to the non "dot" symbols?
>>
>> Yes - but this is what the existing code does as well:
>> '... && ([substr](\$ 1,1,1) != ".") ..'
> 
> Is that in your patch or existing code?  Your patch removes the
> current substr($3,1,1).

In current code there is substr($3,1,1) for GNU nm (BSD mode) and
substr($1,1,1) for AIX nm (POSIX mode), both identifying the "dot"
symbols as to be *removed* from the list of exported symbols.

This patch leaves removal of the "dot" symbols up to $global_symbol_pipe,
which does remove them due to not being a valid C symbol name.

>>> The export_symbols_cmds awk command does not have matching quotes, so
>>> I don't know what is going on.
>>>
>>> awk '\''{ kw = "" } /^[[VWZ]] / { kw = " weak" } { print $ 3 kw }'\''
>>>
>>> you're starting and ending with '\" which seems 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.
> 
> Ah, well, this is turning into a very complex statement.  GCC requires
> GNU Awk and most developers use Bash, but does this work correctly
> with AIX awk and AIX Ksh?

This awk program is quite simple and works with AIX awk too. The AWK
variable is not promoted into the final libtool script, and I don't
want to have projects using libtool to require GNU Awk in general.

Most shells do not take [\] within two ['] as escapement,
so I do the escaping of ['] outside any string. Usually,
 $ echo '\''
will leave you with a string open to be continued, while
 $ echo \'
gives a single ['].

And this one doesn't feel more readable either:
_LT_TAGVAR(...)='$NM ... | awk '"'"'{ ... }'"'"' | sort ...'

What about this one:
_LT_TAGVAR(...)='$NM ... | awk '[\']'{ ... }'[\']' | sort ...'

Thanks!
/haubi/

>>
>>>
>>> Thanks, David
>>>
>>> On Wed, Mar 2, 2016 at 11:19 AM, Michael Haubenwallner
>>> <michael.haubenwall...@ssi-schaefer.com> 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_SYMBOLS): Support POSIX-compatible nm.  Reorder to allow
>>>> for platform specific hooks during transformation of global_symbol_pipe
>>>> into C source code.  For AIX, set hook to transform even weak text
>>>> symbols as text symbols.
>>>> (_LT_LINKER_SHLIBS): Use global_symbol_pipe to simplify forming the
>>>> export_symbols_cmds for AIX.
>>>> ---
>>>>  m4/libtool.m4 | 101 
>>>> --
>>>>  1 file changed, 55 insertions(+), 46 deletions(-)
>>>>
>>>> di

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

2016-03-21 Thread Michael Haubenwallner

On 03/20/2016 01:04 AM, David Edelsohn wrote:
> I agree with this in principle, but I'm not convinced that the patch
> itself is correct.

Thanks!

> I also would have split the MS-compatible part of the patch as a
> separate step.  It is not listed in the ChangeLog and just confuses
> the patch.

This is just a reordering of existing code - these lines are removed
below, and the ChangeLog part is "Reorder to allow for platform specific
hooks during transformation of global_symbol_pipe into C source code."

> I don't see that this emits TLS symbols.  Global TLS symbols are not
> in the symcode list.

Isn't the "L" for TLS symbols?

+symcode='[[BDLTVWZ]]'

But indeed I've failed to identify the symcode of "weak TLS" symbols,
except for "L*" with AIX nm in unspecified mode (nm -l, no -B or -P)
Neither AIX nm nor GNU nm docs explicitly tell about weak TLS symbols.
Is it possible for TLS symbols to be weak at all?

> Global symbol pipe and exclude symbols somehow restricts the symbols
> to the non "dot" symbols?

Yes - but this is what the existing code does as well:
'... && ([substr](\$ 1,1,1) != ".") ..'

> The export_symbols_cmds awk command does not have matching quotes, so
> I don't know what is going on.
> 
> awk '\''{ kw = "" } /^[[VWZ]] / { kw = " weak" } { print $ 3 kw }'\''
> 
> you're starting and ending with '\" which seems 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/

> 
> Thanks, David
> 
> On Wed, Mar 2, 2016 at 11:19 AM, Michael Haubenwallner
> <michael.haubenwall...@ssi-schaefer.com> 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_SYMBOLS): Support POSIX-compatible nm.  Reorder to allow
>> for platform specific hooks during transformation of global_symbol_pipe
>> into C source code.  For AIX, set hook to transform even weak text
>> symbols as text symbols.
>> (_LT_LINKER_SHLIBS): Use global_symbol_pipe to simplify forming the
>> export_symbols_cmds for AIX.
>> ---
>>  m4/libtool.m4 | 101 
>> --
>>  1 file changed, 55 insertions(+), 46 deletions(-)
>>
>> diff --git a/m4/libtool.m4 b/m4/libtool.m4
>> index 2c0e657..6134522 100644
>> --- a/m4/libtool.m4
>> +++ b/m4/libtool.m4
>> @@ -3755,10 +3755,10 @@ _LT_DECL([], [want_nocaseglob], [1],
>>
>>  # LT_PATH_NM
>>  # --
>> -# find the pathname to a BSD- or MS-compatible name lister
>> +# find the pathname to a BSD-, POSIX- or MS-compatible name lister
>>  AC_DEFUN([LT_PATH_NM],
>>  [AC_REQUIRE([AC_PROG_CC])dnl
>> -AC_CACHE_CHECK([for BSD- or MS-compatible name lister (nm)], lt_cv_path_NM,
>> +AC_CACHE_CHECK([for BSD-, POSIX- or MS-compatible name lister (nm)], 
>> lt_cv_path_NM,
>>  [if test -n "$NM"; the
>># Let the user override the test.
>>lt_cv_path_NM=$NM
>> @@ -3808,6 +3808,26 @@ else
>>: ${lt_cv_path_NM=no}
>>  fi])
>>  if test no != "$lt_cv_path_NM"; then
>> +  case $host_os in
>> +  aix[[4-9]]*)
>> +# With AIX nm we need the '-l' flag to get the "weak" information
>> +# for the Import File, but '-l' is ignored with the '-B' flag.  So
>> +# we use the '-P' (POSIX) flag instead.  As users often provide the
>> +# '-B' flag, which conflicts with '-P', we drop any provided flag.
>> +# AIX nm needs the '-C' flag to disable demangling.  For both GNU
>> +# and AIX nm, the '-g' flag shows public (global) symbols only,
>> +# and the '-p' flag disables sorting to improve performance.
>> +set dummy $lt_cv_path_NM
>> +case `@S|@2 -V 2>&1` in
>> +*GNU* | *'with BFD'*)
>> +  lt_cv_path_NM="@S|@2 -Bgp"
>> +  ;;
>> +*)
>> +  lt_cv_path_NM="@S|@2 -PlCgp"
>> +  ;;
>> +esac
>> +;;
>> +  esac
>>NM=$lt_cv_path_NM
>>  else
>># Didn't find any BSD compatible name lister, look for dumpbin.
>> @@ -3832,7 +3852,7 @@ fi
>>  test -z "$NM" && NM=nm
>>  _LT_SET_TOOL_ABI_FLAG([NM])
>>  AC_SUBST([NM])
>> -_LT_DECL([], [NM], [1], [A BSD- or MS-compatible name lister])dnl
>> +_LT_DECL([], [NM], [1], [A BSD-, POSIX-

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

2016-03-19 Thread Michael Haubenwallner
Hi Pavel,

This one actually fixes a regression with AIX sed,
bumping the gl-mod/bootstrap module to include
https://github.com/gnulib-modules/bootstrap/commit/3395ec04c42ab16ccbee05941f5b6ccee5907fdc

See attached testsuite.log for testcase "54: standard command line options"
failing 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: Update.
> bootstrap: Recreate.


# -*- compilation -*-
54. help.at:26: testing standard command line options ...
/tools/haubi/src/libtool-2.4.6.34-08c5/tests/help.at:30: $LIBTOOLIZE --help
stdout:
Usage: 
/tools/haubi/src/test-libtool-2.4.6.34-08c5/gcc-g++-32bit-rtlaix-trad/build/libtoolize
 [OPTION]...

Prepare a package to use libtool.

Options:
   -c, --copy  copy files rather than symlinking them
   --debug enable verbose shell tracing
   -n, --dry-run   print commands rather than running them
   -f, --force replace existing files
   -i, --install   copy missing auxiliary files
   --ltdl[=DIR]install libltdl sources [default: libltdl]
   --no-warnings   equivalent to '-Wnone'
   --nonrecursive  prepare ltdl for non-recursive make
   -q, --quiet work silently
   --recursive prepare ltdl for recursive make
   --subprojectprepare ltdl to configure and build independently
   -v, --verbose   verbosely report processing
   --version   print version information and exit
   -W, --warnings=CATEGORY
   report the warnings falling in CATEGORY [all]
   -h, --help  print short or long help message


Warning categories include:
   'all'  show all warnings
   'none' turn off all the warnings
   'error'warnings are treated as fatal errors
   'environment'   show warnings about LIBTOOLIZE_OPTIONS content
   'file'  show warnings about file copying and linking

The following space or comma delimited options can be passed to libtoolize
via the environment variable LIBTOOLIZE_OPTIONS, unknown environment
options are ignored:

   --debug enable verbose shell tracing
   --no-warnings   don't display warning messages
   --quiet work silently
   --verbose   verbosely report processing

You must 'cd' to the top directory of your package before you run
'libtoolize'.

When reporting a bug, please describe a test case to reproduce it and
include the following information:

   host-triplet:   powerpc-ibm-aix7.1.1.0
   version:libtoolize (GNU libtool) 2.4.6.34-08c5
   automake:   
   autoconf:   

Report bugs to <bug-libt...@gnu.org>.
GNU libtool home page: <http://www.gnu.org/software/libtool/>.
General help using GNU software: <http://www.gnu.org/gethelp/>.
/tools/haubi/src/libtool-2.4.6.34-08c5/tests/help.at:31: $LIBTOOLIZE --version
0a1
> sed: The label :fwd2blank is greater than eight characters.
stdout:
libtoolize (GNU libtool) 2.4.6.34-08c5
/tools/haubi/src/libtool-2.4.6.34-08c5/tests/help.at:31: exit code was 2, 
expected 0
54. help.at:26: 54. standard command line options (help.at:26): FAILED 
(help.at:31)


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

2016-03-15 Thread Michael Haubenwallner

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
> set it while building gcc itself during its multi-lib build either.
> Also, CC may be some wrapper to operate in 64-bit mode. So we cannot
> rely on OBJECT_MODE being set to properly support 64-bit builds.
> 
> Instead, we better identify the object mode in use by looking at the
> file type of an object file generated by CC, to properly set the
> commandline flags for additional tools used within libtool. While there
> is similar code for LD in _LT_ENABLE_LOCK, this is too late for NM.
> 
> * m4/libtool.m4 (_LT_CACHE_CHECK_OBJECT_FILE_TYPE): New. Provides object
> file type identified using /usr/bin/file.
> (_LT_PREPARE_TOOLS_ABI_FLAGS): New. Defines func_set_tool_abi_flag.
> Define AIX specific ABI flags for LD, AR, NM, STRIP, RANLIB.
> Set AIX_OBJECT_MODE as well.
> (_LT_SET_TOOL_ABI_FLAG): New. Uses func_set_tool_abi_flag to set host
> specific ABI flags into tool commands.
> (_LT_PROG_AR): Use _LT_SET_TOOL_ABI_FLAG.
> (LT_PATH_LD): Ditto.
> (LT_PATH_NM): Ditto.
> (_LT_CMD_OLD_ARCHIVE): Use _LT_SET_TOOL_ABI_FLAG for STRIP, RANLIB.
> (_LT_LINKER_SHLIBS): Use AIX_OBJECT_MODE.
> (_LT_LANG_CXX_CONFIG): Ditto.
> * m4/ltoptions.m4 (_LT_WITH_AIX_SONAME): Ditto.

Unfortunately, this patch does not work as expected (as in not requiring
OBJECT_MODE=64 environment variable being set for 64 bits any more), as
gnulib does early run AM_PROG_AR. Unsure if I fooled my tests last year,
or something else has changed since.

Anyway: I'm proposing these two simpler patches now, one as gnulib patch,
which the libtool patch depends on.

Thoughts?

Thanks!
/haubi/
>From 382a70efd75241ea495737faeffc32b09f75de31 Mon Sep 17 00:00:00 2001
From: Michael Haubenwallner <michael.haubenwall...@ssi-schaefer.com>
Date: Tue, 15 Mar 2016 15:50:39 +0100
Subject: [PATCH] early detect AIX object mode for toolchain search

AIX tools do accept only 32 bit objects by default. They either need
the -X32_64 commandline flag to accept both, or the OBJECT_MODE=64
environment variable to switch to accepting 64 bit objects only, while
the GNU toolchain ignores both the -X32_64 flag and the environment
variable. As this affects the whole toolchain, we separately set the
gl_cv_aix_object_mode configure variable.
* m4/gnulib-common.m4 (gl_AIX_OBJECT_MODE): New.
(gl_PROG_AR_RANLIB): AC_REQUIRE gl_AIX_OBJECT_MODE. Search for AR and
RANLIB accepting the -X32_64 when gl_cv_aix_object_mode != no.
---
 m4/gnulib-common.m4 | 33 +
 1 file changed, 33 insertions(+)

diff --git a/m4/gnulib-common.m4 b/m4/gnulib-common.m4
index f8454c8..a3a691f 100644
--- a/m4/gnulib-common.m4
+++ b/m4/gnulib-common.m4
@@ -245,6 +245,33 @@ AC_DEFUN([gl_PROG_CC_C99],
 [AC_REQUIRE([AC_PROG_CC_STDC])])
 ])
 
+# gl_AIX_OBJECT_MODE
+# Determines the current object mode used by the compiler for AIX.
+AC_DEFUN([gl_AIX_OBJECT_MODE],
+[
+  AC_REQUIRE([AC_PROG_CC])
+  AC_CACHE_CHECK([for AIX object mode], [gl_cv_aix_object_mode],
+[
+  AC_EGREP_CPP([OBJECT_MODE=64],
+	[
+#if defined(_AIX) && defined(__64BIT__)
+OBJECT_MODE=64
+#endif
+	],
+	[gl_cv_aix_object_mode=64],
+	[
+	  AC_EGREP_CPP([OBJECT_MODE=32],
+	[
+#if defined(_AIX) && !defined(__64BIT__)
+OBJECT_MODE=32
+#endif
+	],
+	[gl_cv_aix_object_mode=32],
+	[gl_cv_aix_object_mode=no])
+	])
+])
+])
+
 # gl_PROG_AR_RANLIB
 # Determines the values for AR, ARFLAGS, RANLIB that fit with the compiler.
 # The user can set the variables AR, ARFLAGS, RANLIB if he wants to override
@@ -256,6 +283,7 @@ AC_DEFUN([gl_PROG_AR_RANLIB],
   dnl library formats. In particular, the GNU binutils programs ar and ranlib
   dnl produce libraries that work only with gcc, not with cc.
   AC_REQUIRE([AC_PROG_CC])
+  AC_REQUIRE([gl_AIX_OBJECT_MODE])
   AC_BEFORE([$0], [AM_PROG_AR])
   AC_CACHE_CHECK([for Minix Amsterdam compiler], [gl_cv_c_amsterdam_compiler],
 [
@@ -279,6 +307,11 @@ Amsterdam
   ARFLAGS='-o'
 fi
   else
+if test $gl_cv_aix_object_mode != no; then
+  dnl AIX toolchain does accept 32 bit objects by default only.
+  AC_CHECK_TOOL([AR], [ar -X32_64], [ar])
+  AC_CHECK_TOOL([RANLIB], [ranlib -X32_64], [ranlib])
+fi
 dnl AM_PROG_AR was added in automake v1.11.2.  AM_PROG_AR does not AC_SUBST
 dnl ARFLAGS variable (it is filed into Makefile.in directly by automake
 dnl script on-demand, if not specified by ./configure of course).
-- 
2.4.6

>From 40813812c4e721bf02e9d65e589238ed559991f6 Mon Sep 17 00:00:00 2001
From: Michael Haubenwallner <michael.haubenwall...@ssi-schaefer.com>
Date: Tue, 15 Mar 2016 16:10:41 +0100
Subject: [PATCH] AIX: use -X32_64 flag in searc

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

2016-03-15 Thread Michael Haubenwallner
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 ()
 /^# Written by /!b
 s|^# ||; p; n
 
-:fwd2blank
+:fwd2blnk
 /./ {
   n
-  b fwd2blank
+  b fwd2blnk
 }
 p; n
 
-:holdwarranty
+:holdwrnt
 s|^# ||
 s|^# *$||
-/^Copyright /! {
+/^Copyright /!{
   /./H
   n
-  b holdwarranty
+  b holdwrnt
 }
 
 s|\((C)\)[ 0-9,-]*[ ,-]\([1-9][0-9]* \)|\1 \2|
diff --git a/gl-mod/bootstrap b/gl-mod/bootstrap
index eabfd9c..3395ec0 16
--- a/gl-mod/bootstrap
+++ b/gl-mod/bootstrap
@@ -1 +1 @@
-Subproject commit eabfd9c429f02d36695529a96ee2247c9bd2ca4e
+Subproject commit 3395ec04c42ab16ccbee05941f5b6ccee5907fdc
-- 
2.4.6




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

2016-03-14 Thread Michael Haubenwallner


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 look since I wrote a patch for POSIX nm a couple of years ago
>>> that I never submitted (I didn't see any use case) which looked very
>>> similar, excepting the AIX-ism 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_SYMBOLS): Support POSIX-compatible nm.  Reorder to allow
>>>> for platform specific hooks during transformation of global_symbol_pipe
>>>> into C source code.  For AIX, set hook to transform even weak text
>>>> symbols as text symbols.
>>>> (_LT_LINKER_SHLIBS): Use global_symbol_pipe to simplify forming the
>>>> export_symbols_cmds for AIX.
>>>> ---
>>>>  m4/libtool.m4 | 101 
>>>> --
>>>>  1 file changed, 55 insertions(+), 46 deletions(-)
>>>>
>>>> diff --git a/m4/libtool.m4 b/m4/libtool.m4
>>>> index 2c0e657..6134522 100644
>>>> --- a/m4/libtool.m4
>>>> +++ b/m4/libtool.m4
>>>> @@ -3755,10 +3755,10 @@ _LT_DECL([], [want_nocaseglob], [1],
>>>>  
>>>>  # LT_PATH_NM
>>>>  # --
>>>> -# find the pathname to a BSD- or MS-compatible name lister
>>>> +# find the pathname to a BSD-, POSIX- or MS-compatible name lister
>>>>  AC_DEFUN([LT_PATH_NM],
>>>>  [AC_REQUIRE([AC_PROG_CC])dnl
>>>> -AC_CACHE_CHECK([for BSD- or MS-compatible name lister (nm)], 
>>>> lt_cv_path_NM,
>>>> +AC_CACHE_CHECK([for BSD-, POSIX- or MS-compatible name lister (nm)], 
>>>> lt_cv_path_NM,
>>>>  [if test -n "$NM"; then
>>>># Let the user override the test.
>>>>lt_cv_path_NM=$NM
>>>> @@ -3808,6 +3808,26 @@ else
>>>>: ${lt_cv_path_NM=no}
>>>>  fi])
>>>>  if test no != "$lt_cv_path_NM"; then
>>>> +  case $host_os in
>>>> +  aix[[4-9]]*)
>>>> +# With AIX nm we need the '-l' flag to get the "weak" information
>>>> +# for the Import File, but '-l' is ignored with the '-B' flag.  So
>>>> +# we use the '-P' (POSIX) flag instead.  As users often provide the
>>>> +# '-B' flag, which conflicts with '-P', we drop any provided flag.
>>>> +# AIX nm needs the '-C' flag to disable demangling.  For both GNU
>>>> +# and AIX nm, the '-g' flag shows public (global) symbols only,
>>>> +# and the '-p' flag disables sorting to improve performance.
>>>> +set dummy $lt_cv_path_NM
>>>> +case `@S|@2 -V 2>&1` in
>>>> +*GNU* | *'with BFD'*)
>>>> +  lt_cv_path_NM="@S|@2 -Bgp"
>>>> +  ;;
>>>> +*)
>>>> +  lt_cv_path_NM="@S|@2 -PlCgp"
>>>> +  ;;
>>>> +esac
>>>> +;;
>>>> +  esac
>>>
>>> You are overriding the user provided $NM. Not good. If a user says
>>> NM="nm --this-will-not-work", then you will have to trust that even if
>>> it is not likely to work. User error, so what? Adding -Bgp or -PlCgp
>>> can only be done when the user has not specified $NM.
>>
>> Agreed. I've added a check whether NM will mark weak symbols instead.
> 
> I was thinking that you needed to try various flags for each nm in the
> mentioned loop until you find a good nm/flags combo, and keep looking if you
> think you might find an even better combo later (i.e. what is there today,
> where a BSD nm is preferred over other name listers, but tweaked to suite
> AIX which seemingly prefers posix nm above all else).

It is the AIX nm only that fails in BSD mode (in ignoring the -l flag).
GNU nm does correctly report weak symbols even in BSD mode (it does not
support TLS symbols yet, and fails to ignore -X32 and -X64, but that's
another story).

Is the user really required to provide all the nm flags?
IMO, if the user provides a specific nm to use, we should know how to
use that one correctly: -B with GNU nm, -PlC with non-GNU (AIX) nm.
If the nm provided is an unknown one ought to support A

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

2016-03-11 Thread Michael Haubenwallner
Hi Peter,

thanks for looking at the patch!

On 03/10/2016 12:29 PM, Peter Rosin wrote:
> Hi Michael,
> 
> I had a look since I wrote a patch for POSIX nm a couple of years ago
> that I never submitted (I didn't see any use case) which looked very
> similar, excepting the AIX-ism 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_SYMBOLS): Support POSIX-compatible nm.  Reorder to allow
>> for platform specific hooks during transformation of global_symbol_pipe
>> into C source code.  For AIX, set hook to transform even weak text
>> symbols as text symbols.
>> (_LT_LINKER_SHLIBS): Use global_symbol_pipe to simplify forming the
>> export_symbols_cmds for AIX.
>> ---
>>  m4/libtool.m4 | 101 
>> --
>>  1 file changed, 55 insertions(+), 46 deletions(-)
>>
>> diff --git a/m4/libtool.m4 b/m4/libtool.m4
>> index 2c0e657..6134522 100644
>> --- a/m4/libtool.m4
>> +++ b/m4/libtool.m4
>> @@ -3755,10 +3755,10 @@ _LT_DECL([], [want_nocaseglob], [1],
>>  
>>  # LT_PATH_NM
>>  # --
>> -# find the pathname to a BSD- or MS-compatible name lister
>> +# find the pathname to a BSD-, POSIX- or MS-compatible name lister
>>  AC_DEFUN([LT_PATH_NM],
>>  [AC_REQUIRE([AC_PROG_CC])dnl
>> -AC_CACHE_CHECK([for BSD- or MS-compatible name lister (nm)], lt_cv_path_NM,
>> +AC_CACHE_CHECK([for BSD-, POSIX- or MS-compatible name lister (nm)], 
>> lt_cv_path_NM,
>>  [if test -n "$NM"; then
>># Let the user override the test.
>>lt_cv_path_NM=$NM
>> @@ -3808,6 +3808,26 @@ else
>>: ${lt_cv_path_NM=no}
>>  fi])
>>  if test no != "$lt_cv_path_NM"; then
>> +  case $host_os in
>> +  aix[[4-9]]*)
>> +# With AIX nm we need the '-l' flag to get the "weak" information
>> +# for the Import File, but '-l' is ignored with the '-B' flag.  So
>> +# we use the '-P' (POSIX) flag instead.  As users often provide the
>> +# '-B' flag, which conflicts with '-P', we drop any provided flag.
>> +# AIX nm needs the '-C' flag to disable demangling.  For both GNU
>> +# and AIX nm, the '-g' flag shows public (global) symbols only,
>> +# and the '-p' flag disables sorting to improve performance.
>> +set dummy $lt_cv_path_NM
>> +case `@S|@2 -V 2>&1` in
>> +*GNU* | *'with BFD'*)
>> +  lt_cv_path_NM="@S|@2 -Bgp"
>> +  ;;
>> +*)
>> +  lt_cv_path_NM="@S|@2 -PlCgp"
>> +  ;;
>> +esac
>> +;;
>> +  esac
> 
> You are overriding the user provided $NM. Not good. If a user says
> NM="nm --this-will-not-work", then you will have to trust that even if
> it is not likely to work. User error, so what? Adding -Bgp or -PlCgp
> can only be done when the user has not specified $NM.

Agreed. I've added a check whether NM will mark weak symbols instead.

> Yes, I see that
> AIX has previously added nm flags behind the back of the user, but there
> is no reason to continue with that now that you are changing things.
> 
> You need to modify innards of the lt_tmp_nm loop in the else branch
> a few lines up (just above the context).
> 
>>NM=$lt_cv_path_NM
>>  else
>># Didn't find any BSD compatible name lister, look for dumpbin.
>> @@ -3832,7 +3852,7 @@ fi
>>  test -z "$NM" && NM=nm
>>  _LT_SET_TOOL_ABI_FLAG([NM])
>>  AC_SUBST([NM])
>> -_LT_DECL([], [NM], [1], [A BSD- or MS-compatible name lister])dnl
>> +_LT_DECL([], [NM], [1], [A BSD-, POSIX- or MS-compatible name lister])dnl
>>  
>>  AC_CACHE_CHECK([the name lister ($NM) interface], [lt_cv_nm_interface],
>>[lt_cv_nm_interface="BSD nm"
>> @@ -3847,6 +3867,8 @@ AC_CACHE_CHECK([the name lister ($NM) interface], 
>> [lt_cv_nm_interface],
>>cat conftest.out >_MESSAGE_LOG_FD
>>if $GREP 'External.*some_variable' conftest.out > /dev/null; then
>>  lt_cv_nm_interface="MS dumpbin"
>> +  elif $GREP '^[[]]*_*some_variable' conftest.out > /dev/null; then
>> +lt_cv_nm_interface="POSIX nm"
> 
> Isn't this a pretty weak check, perhaps append ' B' and remove the possibility
> for leading whitespace? (see my last comment below for reasoning on spaces)

As long as the expected symbol name comes first, isn't it POSIX then?
Anyway, 've added "[\t ][\t 

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

2016-03-11 Thread Michael Haubenwallner

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

>>  func_echo_all ()
>>  {
>> -$ECHO "$*"
>> +$ECHO "@S|@*"
> 
> That works.  You might also want to try $[]*, for less typing, and
> comparable to what we have a few lines earlier:

While I don't really care, and failed to identify the preferred syntax
across libtool.m4 - wouldn't [$]* be even more obvious to read, as in
"quote the dollar-sign"?

/haubi/
>From 3099497610ea29f67dacf33ec0d11e3a1a87602e Mon Sep 17 00:00:00 2001
From: Michael Haubenwallner <michael.haubenwall...@ssi-schaefer.com>
Date: Thu, 21 May 2015 18:59:42 +0200
Subject: [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..7c7c82e 100644
--- a/m4/libtool.m4
+++ b/m4/libtool.m4
@@ -1218,7 +1218,7 @@ fi
 # Invoke $ECHO with all args, space-separated.
 func_echo_all ()
 {
-$ECHO "$*"
+$ECHO "[$]*"
 }
 
 case $ECHO in
-- 
2.4.6



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

2016-03-10 Thread Michael Haubenwallner
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 be some wrapper to operate in 64-bit mode. So we cannot
rely on OBJECT_MODE being set to properly support 64-bit builds.

Instead, we better identify the object mode in use by looking at the
file type of an object file generated by CC, to properly set the
commandline flags for additional tools used within libtool. While there
is similar code for LD in _LT_ENABLE_LOCK, this is too late for NM.

* m4/libtool.m4 (_LT_CACHE_CHECK_OBJECT_FILE_TYPE): New. Provides object
file type identified using /usr/bin/file.
(_LT_PREPARE_TOOLS_ABI_FLAGS): New. Defines func_set_tool_abi_flag.
Define AIX specific ABI flags for LD, AR, NM, STRIP, RANLIB.
Set AIX_OBJECT_MODE as well.
(_LT_SET_TOOL_ABI_FLAG): New. Uses func_set_tool_abi_flag to set host
specific ABI flags into tool commands.
(_LT_PROG_AR): Use _LT_SET_TOOL_ABI_FLAG.
(LT_PATH_LD): Ditto.
(LT_PATH_NM): Ditto.
(_LT_CMD_OLD_ARCHIVE): Use _LT_SET_TOOL_ABI_FLAG for STRIP, RANLIB.
(_LT_LINKER_SHLIBS): Use AIX_OBJECT_MODE.
(_LT_LANG_CXX_CONFIG): Ditto.
* m4/ltoptions.m4 (_LT_WITH_AIX_SONAME): Ditto.
---
 m4/libtool.m4   | 85 +++--
 m4/ltoptions.m4 |  3 +-
 2 files changed, 84 insertions(+), 4 deletions(-)

diff --git a/m4/libtool.m4 b/m4/libtool.m4
index 7b8b591..2c0e657 100644
--- a/m4/libtool.m4
+++ b/m4/libtool.m4
@@ -1177,6 +1177,80 @@ fi
 ])# _LT_SYS_MODULE_PATH_AIX
 
 
+# _LT_CACHE_CHECK_OBJECT_FILE_TYPE
+# 
+# Compiles a minimal program and identifies the file type of that object file.
+# All object files linked together in one build configuration have to be of
+# the same object file type.  As we always need the C compiler anyway, there
+# is no point in checking object file types per TAG.
+m4_defun([_LT_CACHE_CHECK_OBJECT_FILE_TYPE],
+[AC_REQUIRE([AC_PROG_CC])dnl
+m4_require([_LT_DECL_SED])dnl
+m4_require([_LT_PROG_ECHO_BACKSLASH])dnl
+AC_CACHE_CHECK([$CC object file type], [lt_cv_object_file_type],
+  [AC_COMPILE_IFELSE([AC_LANG_PROGRAM],
+[echo "$as_me:$LINENO: LC_ALL=C /usr/bin/file conftest.$ac_objext" 
>_MESSAGE_LOG_FD
+lt_cv_object_file_type=`LC_ALL=C /usr/bin/file conftest.$ac_objext 
2>_MESSAGE_LOG_FD`
+ac_status=$?
+func_echo_all "$lt_cv_object_file_type" >_MESSAGE_LOG_FD
+func_echo_all "$as_me:$LINENO: \$? = $ac_status" >_MESSAGE_LOG_FD
+lt_cv_object_file_type=`func_echo_all "$lt_cv_object_file_type" | $SED -e 
"s/^conftest\.$ac_objext:  *//"`
+])
+  ])
+]) # _LT_CACHE_CHECK_OBJECT_FILE_TYPE
+
+
+# _LT_PREPARE_TOOLS_ABI_FLAGS
+# ---
+m4_defun([_LT_PREPARE_TOOLS_ABI_FLAGS],
+[AC_REQUIRE([AC_CANONICAL_HOST])dnl
+AC_REQUIRE([AC_PROG_CC])dnl
+# func_set_tool_abi_flag TOOL [TOOLVAR]
+# Ensure that TOOL-specific command in $TOOL (or $TOOLVAR if specified) does
+# contain $lt_abi_flag_TOOL (if defined below) as standalone argument.
+# Does nothing if $TOOL (or $TOOLVAR) is empty.
+func_set_tool_abi_flag ()
+{
+  eval "AS_CASE([\" \@S|@@S|@{2-@S|@1}  \"],
+  ['   '],
+[# command is empty
+],
+  [*\" \@S|@lt_abi_flag_@S|@1 \"*],
+[# standalone flag found, or flag is empty
+],
+[@S|@{2-@S|@1}=\"\@S|@@S|@{2-@S|@1} \@S|@lt_abi_flag_@S|@1\"]
+  )"
+}
+
+# PORTME Define flags for various tools to accept the ABI selected by
+# '$CC $CFLAGS $CPPFLAGS'.
+case $host in
+power*-*-aix4.[[3-9]]* | power*-aix[[5-9]]*)
+  _LT_CACHE_CHECK_OBJECT_FILE_TYPE
+  case $ac_status:$lt_cv_object_file_type in
+  0:*64-bit*) AIX_OBJECT_MODE=64 ;;
+  0:*"RISC System/6000"*) AIX_OBJECT_MODE=32 ;;
+  *) AC_MSG_FAILURE([failed to check $CC generated ABI]) ;;
+  esac
+  lt_abi_flag_LD=-b$AIX_OBJECT_MODE
+  lt_abi_flag_AR=-X$AIX_OBJECT_MODE
+  lt_abi_flag_NM=-X$AIX_OBJECT_MODE
+  lt_abi_flag_STRIP=-X$AIX_OBJECT_MODE
+  lt_abi_flag_RANLIB=-X$AIX_OBJECT_MODE
+  ;;
+esac
+]) # _LT_PREPARE_TOOLS_ABI_FLAGS
+
+
+# _LT_SET_TOOL_ABI_FLAG(TOOL, [TOOLVAR])
+# 
+# Ensure to be defined, and call: func_set_tool_abi_flag TOOL TOOLVAR
+m4_defun([_LT_SET_TOOL_ABI_FLAG],
+[m4_require([_LT_PREPARE_TOOLS_ABI_FLAGS])dnl
+func_set_tool_abi_flag $1 $2
+]) # _LT_SET_TOOL_ABI_FLAG
+
+
 # _LT_SHELL_INIT(ARG)
 # ---
 m4_define([_LT_SHELL_INIT],
@@ -1285,7 +1359,7 @@ m4_defun([_LT_ENABLE_LOCK],
 test no = "$enable_libtool_lock" || enable_libtool_lock=yes
 
 # Some flags need to be propagated to the compiler or linker for good
-# libtool support.
+# libtool support. Should move to _LT_PREPARE_TOOLS_ABI_FLAGS.
 case $host in
 ia64-*-hpux*)
   # Find out what ABI is being produced by ac_compile, and set mode
@@ -1493,6 +1567,7 @@ need_locks=$enable_libtool_lock
 m4_defun([_LT_PROG_AR],
 [AC_CHECK_TOOLS(AR, 

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

2016-03-10 Thread Michael Haubenwallner
* 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 ++
 1 file changed, 2 insertions(+)

diff --git a/m4/libtool.m4 b/m4/libtool.m4
index 6134522..c8a878f 100644
--- a/m4/libtool.m4
+++ b/m4/libtool.m4
@@ -5042,6 +5042,7 @@ m4_if([$1], [CXX], [
   _LT_TAGVAR(exclude_expsyms, $1)=['_GLOBAL_OFFSET_TABLE_|_GLOBAL__F[ID]_.*']
   case $host_os in
   aix[[4-9]]*)
+_LT_TAGVAR(exclude_expsyms, $1)='_GLOBAL_OFFSET_TABLE_|_GLOBAL__.*'
 _LT_TAGVAR(export_symbols_cmds, $1)='$NM $libobjs $convenience | 
$global_symbol_pipe | $EGREP -v " ($exclude_expsyms)$" | awk '\''{ kw = "" } 
/^[[VWZ]] / { kw = " weak" } { print $ 3 kw }'\'' | sort -u > $export_symbols'
 ;;
   pw32*)
@@ -5485,6 +5486,7 @@ _LT_EOF
exp_sym_flag='-Bexport'
no_entry_flag=
   else
+   _LT_TAGVAR(exclude_expsyms, $1)='_GLOBAL_OFFSET_TABLE_|_GLOBAL__.*'
_LT_TAGVAR(export_symbols_cmds, $1)='$NM $libobjs $convenience | 
$global_symbol_pipe | $EGREP -v " ($exclude_expsyms)$" | awk '\''{ kw = "" } 
/^[[VWZ]] / { kw = " weak" } { print $ 3 kw }'\'' | sort -u > $export_symbols'
aix_use_runtimelinking=no
 
-- 
2.4.6




[PATCH PING] rebased AIX-driven libtool improvement patches

2016-03-10 Thread Michael Haubenwallner
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: http://lists.gnu.org/archive/html/libtool-patches/2016-03/msg0.html

The tests across various AIX configure options were run and compared with:
https://github.com/haubi/libtool-testing/tree/master/aix

Thanks a lot!
/haubi/




[PATCH 1/4] Fix func_echo_all inside configure.

2016-03-10 Thread Michael Haubenwallner
* 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 args, space-separated.
 func_echo_all ()
 {
-$ECHO "$*"
+$ECHO "@S|@*"
 }
 
 case $ECHO in
-- 
2.4.6




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

2016-03-10 Thread Michael Haubenwallner
* 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 global_symbol_pipe
into C source code.  For AIX, set hook to transform even weak text
symbols as text symbols.
(_LT_LINKER_SHLIBS): Use global_symbol_pipe to simplify forming the
export_symbols_cmds for AIX.
---
 m4/libtool.m4 | 101 --
 1 file changed, 55 insertions(+), 46 deletions(-)

diff --git a/m4/libtool.m4 b/m4/libtool.m4
index 2c0e657..6134522 100644
--- a/m4/libtool.m4
+++ b/m4/libtool.m4
@@ -3755,10 +3755,10 @@ _LT_DECL([], [want_nocaseglob], [1],
 
 # LT_PATH_NM
 # --
-# find the pathname to a BSD- or MS-compatible name lister
+# find the pathname to a BSD-, POSIX- or MS-compatible name lister
 AC_DEFUN([LT_PATH_NM],
 [AC_REQUIRE([AC_PROG_CC])dnl
-AC_CACHE_CHECK([for BSD- or MS-compatible name lister (nm)], lt_cv_path_NM,
+AC_CACHE_CHECK([for BSD-, POSIX- or MS-compatible name lister (nm)], 
lt_cv_path_NM,
 [if test -n "$NM"; then
   # Let the user override the test.
   lt_cv_path_NM=$NM
@@ -3808,6 +3808,26 @@ else
   : ${lt_cv_path_NM=no}
 fi])
 if test no != "$lt_cv_path_NM"; then
+  case $host_os in
+  aix[[4-9]]*)
+# With AIX nm we need the '-l' flag to get the "weak" information
+# for the Import File, but '-l' is ignored with the '-B' flag.  So
+# we use the '-P' (POSIX) flag instead.  As users often provide the
+# '-B' flag, which conflicts with '-P', we drop any provided flag.
+# AIX nm needs the '-C' flag to disable demangling.  For both GNU
+# and AIX nm, the '-g' flag shows public (global) symbols only,
+# and the '-p' flag disables sorting to improve performance.
+set dummy $lt_cv_path_NM
+case `@S|@2 -V 2>&1` in
+*GNU* | *'with BFD'*)
+  lt_cv_path_NM="@S|@2 -Bgp"
+  ;;
+*)
+  lt_cv_path_NM="@S|@2 -PlCgp"
+  ;;
+esac
+;;
+  esac
   NM=$lt_cv_path_NM
 else
   # Didn't find any BSD compatible name lister, look for dumpbin.
@@ -3832,7 +3852,7 @@ fi
 test -z "$NM" && NM=nm
 _LT_SET_TOOL_ABI_FLAG([NM])
 AC_SUBST([NM])
-_LT_DECL([], [NM], [1], [A BSD- or MS-compatible name lister])dnl
+_LT_DECL([], [NM], [1], [A BSD-, POSIX- or MS-compatible name lister])dnl
 
 AC_CACHE_CHECK([the name lister ($NM) interface], [lt_cv_nm_interface],
   [lt_cv_nm_interface="BSD nm"
@@ -3847,6 +3867,8 @@ AC_CACHE_CHECK([the name lister ($NM) interface], 
[lt_cv_nm_interface],
   cat conftest.out >_MESSAGE_LOG_FD
   if $GREP 'External.*some_variable' conftest.out > /dev/null; then
 lt_cv_nm_interface="MS dumpbin"
+  elif $GREP '^[[   ]]*_*some_variable' conftest.out > /dev/null; then
+lt_cv_nm_interface="POSIX nm"
   fi
   rm -f conftest*])
 ])# LT_PATH_NM
@@ -4012,8 +4034,33 @@ symcode='[[BCDEGRST]]'
 # Regexp to match symbols that can be accessed directly from C.
 sympat='\([[_A-Za-z]][[_A-Za-z0-9]]*\)'
 
+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'"
+  # 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_c_name_lib_hook="\
+  -e 's/^I .* \(lib.*\)$/  {\"\1\", (void *) 0},/p'\
+  -e 's/^I .* \(.*\)$/  {\"lib\1\", (void *) 0},/p'"
+else
+  # Disable hooks by default.
+  lt_cv_sys_global_symbol_to_import=
+  lt_cdecl_hook=
+  lt_c_name_hook=
+  lt_c_name_lib_hook=
+fi
+
 # Define system-specific variables.
 case $host_os in
+aix[[4-9]]*)
+  case `$NM -V 2>&1` in
+  *GNU* | *'with BFD'*) ;;
+  *)
+symcode='[[BDLTVWZ]]'
+lt_cdecl_hook=" -e 's/^W/T/p'" # weak text symbol
+  esac
+  ;;
 aix*)
   symcode='[[BCDT]]'
   ;;
@@ -4054,23 +4101,6 @@ case `$NM -V 2>&1` in
   symcode='[[ABCDGIRSTW]]' ;;
 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'"
-  # 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_c_name_lib_hook="\
-  -e 's/^I .* \(lib.*\)$/  {\"\1\", (void *) 0},/p'\
-  -e 's/^I .* \(.*\)$/  {\"lib\1\", (void *) 0},/p'"
-else
-  # Disable hooks by default.
-  lt_cv_sys_global_symbol_to_import=
-  lt_cdecl_hook=
-  lt_c_name_hook=
-  lt_c_name_lib_hook=
-fi
-
 # Transform an extracted symbol line into a proper C declaration.
 # Some systems (esp. on ia64) link data and code symbols differently,
 # so use this general approach.
@@ -4128,6 +4158,9 @@ for ac_symprfx in "" "_"; do
 " 

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

2016-03-02 Thread Michael Haubenwallner
* 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 global_symbol_pipe
into C source code.  For AIX, set hook to transform even weak text
symbols as text symbols.
(_LT_LINKER_SHLIBS): Use global_symbol_pipe to simplify forming the
export_symbols_cmds for AIX.
---
 m4/libtool.m4 | 101 --
 1 file changed, 55 insertions(+), 46 deletions(-)

diff --git a/m4/libtool.m4 b/m4/libtool.m4
index 2c0e657..6134522 100644
--- a/m4/libtool.m4
+++ b/m4/libtool.m4
@@ -3755,10 +3755,10 @@ _LT_DECL([], [want_nocaseglob], [1],
 
 # LT_PATH_NM
 # --
-# find the pathname to a BSD- or MS-compatible name lister
+# find the pathname to a BSD-, POSIX- or MS-compatible name lister
 AC_DEFUN([LT_PATH_NM],
 [AC_REQUIRE([AC_PROG_CC])dnl
-AC_CACHE_CHECK([for BSD- or MS-compatible name lister (nm)], lt_cv_path_NM,
+AC_CACHE_CHECK([for BSD-, POSIX- or MS-compatible name lister (nm)], 
lt_cv_path_NM,
 [if test -n "$NM"; then
   # Let the user override the test.
   lt_cv_path_NM=$NM
@@ -3808,6 +3808,26 @@ else
   : ${lt_cv_path_NM=no}
 fi])
 if test no != "$lt_cv_path_NM"; then
+  case $host_os in
+  aix[[4-9]]*)
+# With AIX nm we need the '-l' flag to get the "weak" information
+# for the Import File, but '-l' is ignored with the '-B' flag.  So
+# we use the '-P' (POSIX) flag instead.  As users often provide the
+# '-B' flag, which conflicts with '-P', we drop any provided flag.
+# AIX nm needs the '-C' flag to disable demangling.  For both GNU
+# and AIX nm, the '-g' flag shows public (global) symbols only,
+# and the '-p' flag disables sorting to improve performance.
+set dummy $lt_cv_path_NM
+case `@S|@2 -V 2>&1` in
+*GNU* | *'with BFD'*)
+  lt_cv_path_NM="@S|@2 -Bgp"
+  ;;
+*)
+  lt_cv_path_NM="@S|@2 -PlCgp"
+  ;;
+esac
+;;
+  esac
   NM=$lt_cv_path_NM
 else
   # Didn't find any BSD compatible name lister, look for dumpbin.
@@ -3832,7 +3852,7 @@ fi
 test -z "$NM" && NM=nm
 _LT_SET_TOOL_ABI_FLAG([NM])
 AC_SUBST([NM])
-_LT_DECL([], [NM], [1], [A BSD- or MS-compatible name lister])dnl
+_LT_DECL([], [NM], [1], [A BSD-, POSIX- or MS-compatible name lister])dnl
 
 AC_CACHE_CHECK([the name lister ($NM) interface], [lt_cv_nm_interface],
   [lt_cv_nm_interface="BSD nm"
@@ -3847,6 +3867,8 @@ AC_CACHE_CHECK([the name lister ($NM) interface], 
[lt_cv_nm_interface],
   cat conftest.out >_MESSAGE_LOG_FD
   if $GREP 'External.*some_variable' conftest.out > /dev/null; then
 lt_cv_nm_interface="MS dumpbin"
+  elif $GREP '^[[   ]]*_*some_variable' conftest.out > /dev/null; then
+lt_cv_nm_interface="POSIX nm"
   fi
   rm -f conftest*])
 ])# LT_PATH_NM
@@ -4012,8 +4034,33 @@ symcode='[[BCDEGRST]]'
 # Regexp to match symbols that can be accessed directly from C.
 sympat='\([[_A-Za-z]][[_A-Za-z0-9]]*\)'
 
+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'"
+  # 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_c_name_lib_hook="\
+  -e 's/^I .* \(lib.*\)$/  {\"\1\", (void *) 0},/p'\
+  -e 's/^I .* \(.*\)$/  {\"lib\1\", (void *) 0},/p'"
+else
+  # Disable hooks by default.
+  lt_cv_sys_global_symbol_to_import=
+  lt_cdecl_hook=
+  lt_c_name_hook=
+  lt_c_name_lib_hook=
+fi
+
 # Define system-specific variables.
 case $host_os in
+aix[[4-9]]*)
+  case `$NM -V 2>&1` in
+  *GNU* | *'with BFD'*) ;;
+  *)
+symcode='[[BDLTVWZ]]'
+lt_cdecl_hook=" -e 's/^W/T/p'" # weak text symbol
+  esac
+  ;;
 aix*)
   symcode='[[BCDT]]'
   ;;
@@ -4054,23 +4101,6 @@ case `$NM -V 2>&1` in
   symcode='[[ABCDGIRSTW]]' ;;
 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'"
-  # 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_c_name_lib_hook="\
-  -e 's/^I .* \(lib.*\)$/  {\"\1\", (void *) 0},/p'\
-  -e 's/^I .* \(.*\)$/  {\"lib\1\", (void *) 0},/p'"
-else
-  # Disable hooks by default.
-  lt_cv_sys_global_symbol_to_import=
-  lt_cdecl_hook=
-  lt_c_name_hook=
-  lt_c_name_lib_hook=
-fi
-
 # Transform an extracted symbol line into a proper C declaration.
 # Some systems (esp. on ia64) link data and code symbols differently,
 # so use this general approach.
@@ -4128,6 +4158,9 @@ for ac_symprfx in "" "_"; do
 " 

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

2016-03-02 Thread Michael Haubenwallner
* 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 ++
 1 file changed, 2 insertions(+)

diff --git a/m4/libtool.m4 b/m4/libtool.m4
index 6134522..c8a878f 100644
--- a/m4/libtool.m4
+++ b/m4/libtool.m4
@@ -5042,6 +5042,7 @@ m4_if([$1], [CXX], [
   _LT_TAGVAR(exclude_expsyms, $1)=['_GLOBAL_OFFSET_TABLE_|_GLOBAL__F[ID]_.*']
   case $host_os in
   aix[[4-9]]*)
+_LT_TAGVAR(exclude_expsyms, $1)='_GLOBAL_OFFSET_TABLE_|_GLOBAL__.*'
 _LT_TAGVAR(export_symbols_cmds, $1)='$NM $libobjs $convenience | 
$global_symbol_pipe | $EGREP -v " ($exclude_expsyms)$" | awk '\''{ kw = "" } 
/^[[VWZ]] / { kw = " weak" } { print $ 3 kw }'\'' | sort -u > $export_symbols'
 ;;
   pw32*)
@@ -5485,6 +5486,7 @@ _LT_EOF
exp_sym_flag='-Bexport'
no_entry_flag=
   else
+   _LT_TAGVAR(exclude_expsyms, $1)='_GLOBAL_OFFSET_TABLE_|_GLOBAL__.*'
_LT_TAGVAR(export_symbols_cmds, $1)='$NM $libobjs $convenience | 
$global_symbol_pipe | $EGREP -v " ($exclude_expsyms)$" | awk '\''{ kw = "" } 
/^[[VWZ]] / { kw = " weak" } { print $ 3 kw }'\'' | sort -u > $export_symbols'
aix_use_runtimelinking=no
 
-- 
2.4.6




Introducing support for POSIX-nm, required for AIX.

2016-03-02 Thread Michael Haubenwallner
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 because it
relies on the AIX-nm to be run in POSIX mode.

So the first patch does add generic support for POSIX-nm to libtool,
and simplifies the export_symbols_cmds for AIX a lot.

Finally, the second patch does actually stop exporting above symbols.

Although this topic is independent of the patch series titled
"AIX: Do not rely on OBJECT_MODE env var being set." [1]
(no response yet;), this patch series is based on that one, as both
deal with NM flags.

[1] http://thread.gmane.org/gmane.comp.gnu.libtool.patches/11819

Thanks!
/haubi/




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

2016-02-29 Thread Michael Haubenwallner
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. However, gcc ignores OBJECT_MODE, and does not
> set it while building gcc itself during its multi-lib build either.
> Also, CC may be some wrapper to operate in 64-bit mode. So we cannot
> rely on OBJECT_MODE being set to properly support 64-bit builds.
> 
> Instead, we better identify the object mode in use by looking at the
> file type of an object file generated by CC, to properly set the
> commandline flags for additional tools used within libtool. While there
> is similar code for LD in _LT_ENABLE_LOCK, this is too late for NM.
> 
> * m4/libtool.m4 (_LT_CACHE_CHECK_OBJECT_FILE_TYPE): New. Provides object
> file type identified using /usr/bin/file.
> (_LT_PREPARE_TOOLS_ABI_FLAGS): New. Defines func_set_tool_abi_flag.
> Define AIX specific ABI flags for LD, AR, NM, STRIP, RANLIB.
> Set AIX_OBJECT_MODE as well.
> (_LT_SET_TOOL_ABI_FLAG): New. Uses func_set_tool_abi_flag to set host
> specific ABI flags into tool commands.
> (_LT_PROG_AR): Use _LT_SET_TOOL_ABI_FLAG.
> (LT_PATH_LD): Ditto.
> (LT_PATH_NM): Ditto.
> (_LT_CMD_OLD_ARCHIVE): Use _LT_SET_TOOL_ABI_FLAG for STRIP, RANLIB.
> (_LT_LINKER_SHLIBS): Use AIX_OBJECT_MODE.
> (_LT_LANG_CXX_CONFIG): Ditto.
> * m4/ltoptions.m4 (_LT_WITH_AIX_SONAME): Ditto.

>From 84c75ad869c3a8c8e2642ae2272a71b6b18f85d2 Mon Sep 17 00:00:00 2001
From: Michael Haubenwallner <michael.haubenwall...@ssi-schaefer.com>
Date: Wed, 20 May 2015 15:42:09 +0200
Subject: [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 be some wrapper to operate in 64-bit mode. So we cannot
rely on OBJECT_MODE being set to properly support 64-bit builds.

Instead, we better identify the object mode in use by looking at the
file type of an object file generated by CC, to properly set the
commandline flags for additional tools used within libtool. While there
is similar code for LD in _LT_ENABLE_LOCK, this is too late for NM.

* m4/libtool.m4 (_LT_CACHE_CHECK_OBJECT_FILE_TYPE): New. Provides object
file type identified using /usr/bin/file.
(_LT_PREPARE_TOOLS_ABI_FLAGS): New. Defines func_set_tool_abi_flag.
Define AIX specific ABI flags for LD, AR, NM, STRIP, RANLIB.
Set AIX_OBJECT_MODE as well.
(_LT_SET_TOOL_ABI_FLAG): New. Uses func_set_tool_abi_flag to set host
specific ABI flags into tool commands.
(_LT_PROG_AR): Use _LT_SET_TOOL_ABI_FLAG.
(LT_PATH_LD): Ditto.
(LT_PATH_NM): Ditto.
(_LT_CMD_OLD_ARCHIVE): Use _LT_SET_TOOL_ABI_FLAG for STRIP, RANLIB.
(_LT_LINKER_SHLIBS): Use AIX_OBJECT_MODE.
(_LT_LANG_CXX_CONFIG): Ditto.
* m4/ltoptions.m4 (_LT_WITH_AIX_SONAME): Ditto.
---
 m4/libtool.m4   | 85 +++--
 m4/ltoptions.m4 |  3 +-
 2 files changed, 84 insertions(+), 4 deletions(-)

diff --git a/m4/libtool.m4 b/m4/libtool.m4
index 7b8b591..2c0e657 100644
--- a/m4/libtool.m4
+++ b/m4/libtool.m4
@@ -1177,6 +1177,80 @@ fi
 ])# _LT_SYS_MODULE_PATH_AIX
 
 
+# _LT_CACHE_CHECK_OBJECT_FILE_TYPE
+# 
+# Compiles a minimal program and identifies the file type of that object file.
+# All object files linked together in one build configuration have to be of
+# the same object file type.  As we always need the C compiler anyway, there
+# is no point in checking object file types per TAG.
+m4_defun([_LT_CACHE_CHECK_OBJECT_FILE_TYPE],
+[AC_REQUIRE([AC_PROG_CC])dnl
+m4_require([_LT_DECL_SED])dnl
+m4_require([_LT_PROG_ECHO_BACKSLASH])dnl
+AC_CACHE_CHECK([$CC object file type], [lt_cv_object_file_type],
+  [AC_COMPILE_IFELSE([AC_LANG_PROGRAM],
+[echo "$as_me:$LINENO: LC_ALL=C /usr/bin/file conftest.$ac_objext" >_MESSAGE_LOG_FD
+lt_cv_object_file_type=`LC_ALL=C /usr/bin/file conftest.$ac_objext 2>_MESSAGE_LOG_FD`
+ac_status=$?
+func_echo_all "$lt_cv_object_file_type" >_MESSAGE_LOG_FD
+func_echo_all "$as_me:$LINENO: \$? = $ac_status" >_MESSAGE_LOG_FD
+lt_cv_object_file_type=`func_echo_all "$lt_cv_object_file_type" | $SED -e "s/^conftest\.$ac_objext:  *//"`
+])
+  ])
+]) # _LT_CACHE_CHECK_OBJECT_FILE_TYPE
+
+
+# _LT_PREPARE_TOOLS_ABI_FLAGS
+# ---
+m4_defun([_LT_PREPARE_TOOLS_ABI_FLAGS],
+[AC_REQUIRE([AC_CANONICAL_HOST])dnl
+AC_REQUIRE([AC_PROG_CC])dnl
+# func_set_tool_abi_flag TOOL [TOOLVAR]
+# Ensure that TOOL-specific command in $TOOL (o

Re: [PATCH] AIX SONAME emulation, simplified implementation

2015-07-07 Thread Michael Haubenwallner
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 
 emulation.
 I've tried this variant of soname-emulation too, but discovered the one 
 using
 the lib.so.v(shr.o,shr.imp) archive (=svr4) as the more reasonable 
 compromise.
 Is there a specific reason you need/want this simplified implementation?
 
 
 The main reason is actually non-libtool build systems, where I have to 
 implement this
 by hand. The .so as text file is a much simpler implementation for situations 
 where I have
 to torture a hand-rolled build-system into producing a versionable shared 
 object.

For non-libtool build systems: Have you considered to add (optional) libtool 
support
instead of implementing sharedlib details? This does not mean to completely 
libtoolize,
but to use the (separate) libtool script[1] as the compiler/linker - something 
like:

  LIBRARY = libNAME.la
  OBJS = *.lo
  CC = libtool --mode=compile --tag=CC gcc
  CXX = libtool --mode=compile --tag=CXX g++
  LD = libtool --mode=link --tag=CXX g++

[1] https://github.com/haubi/host-libtool/

  This is different in the sense that it doesn't add archives disguised 
 as .so files,
 Yeah, instead it does provide plain text files disguised as .so files.
 
 Besides that, there's potential for more different confusion:
 
 *) Linking with /path/to/lib.so produces different result than
 linking with /path/to/lib.so.v (difference is in the runpath).
 *) dlopen(lib.so) fails, while dlopen(lib.so.v) does work.
 *) Provides two distinct files, instead of one single file with symlinks.
 
 
 Those are fair points, I haven't considered them since all my AIX builds 
 happen in very
 controlled setups.

Even controlled setups can be portable...

 I could maybe argue that the dlopen case is a degenerate case, because the
 runtime interface of a versioned shared library is its SONAME, not the 
 unversioned .so,

Agreed.

 and for shared objects that are intended to be dlopen'ed (which libtool calls 
 modules),
 my patch won't affect them.
 
 
  and instead relies on the fact that the AIX linker will take an import 
 file when
 
  looking for -lfoo, and will record what the import file says.
 This very detail isn't anything different compared to aix-soname=svr4.
 
 
 Fair point again...
 
 I think the main problem is that we implemented this patches in parallel, but 
 I forgot to
 release mine for a long time, and you did a much better job at it :).

Thank you! ;)

 I'll investigate how hard would it be to use your version of it for libtool 
 projects
 (even if I still do the simplified version for hand-rolled build systems).

I've experienced that there isn't so much difference adding svr4-mode to 
whatever
build system compared to adding simple-mode, given that you have to 
non-trivially
touch that build system anyway.

OTOH, once I've wrapped[2] the ld command to accept the '-soname' flag.
Combined with an mkexpfile[3] command to get the exported symbols right,
the diff for any build system can become quite small[4].

[2] 
https://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/sys-devel/native-cctools/files/aix-2/ld?revision=1.1view=markup
[3] 
https://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/sys-devel/native-cctools/files/aix-2/mkexpfile?revision=1.1view=markup
[4] 
http://sourceforge.net/p/gentooprefixtree/code/ci/23181bf2b106f56e25446acb519563e19fb5747c/tree/sys-libs/readline/files/readline-6.2-aixso.patch

/haubi/



Re: [PATCH] AIX SONAME emulation, simplified implementation

2015-07-06 Thread Michael Haubenwallner
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 discovered the one using
the lib.so.v(shr.o,shr.imp) archive (=svr4) as the more reasonable compromise.

Is there a specific reason you need/want this simplified implementation?

 This is different in the sense that it doesn't add archives disguised as .so 
 files,

Yeah, instead it does provide plain text files disguised as .so files.

Besides that, there's potential for more different confusion:
*) Linking with /path/to/lib.so produces different result than 
   linking with /path/to/lib.so.v (difference is in the runpath).
*) dlopen(lib.so) fails, while dlopen(lib.so.v) does work.
*) Provides two distinct files, instead of one single file with symlinks.

 and instead relies on the fact that the AIX linker will take an import file 
 when
 looking for -lfoo, and will record what the import file says.

This very detail isn't anything different compared to aix-soname=svr4.

Leaving alone different confusion, this version of the patch has some real 
problems:

*) Please post patches as plain-text.
*) Breaks test cases in build setups that should be unaffected by this patch
   (I'm using https://github.com/haubi/libtool-testing/ for the different build
   setups to run the testsuite in and compare the results).
*) Why do you change archive_expsym_cmds for $host_cpu = ia64 ?
*) Seems you haven't used 'make distcheck': Tells to not use '==' with 'test'.
*) Prohibits the AIX-style of multilib (multiple shared objects in one archive).
*) Existing site setups using LDFLAGS=-Wl,-brtl will break, as their existing
   binaries depend on the unversioned .so files, which will be replaced by
   plain text files.
   At least something like --with-aix-soname=simple would be necessary.

Thanks for your interest on this topic!
/haubi/



Re: [PATCH] AIX SONAME emulation, simplified implementation

2015-07-06 Thread Michael Haubenwallner
(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 tried this variant of soname-emulation too, but discovered the one using
the lib.so.v(shr.o,shr.imp) archive (=svr4) as the more reasonable compromise.

Is there a specific reason you need/want this simplified implementation?

 This is different in the sense that it doesn't add archives disguised as .so 
 files,

Yeah, instead it does provide plain text files disguised as .so files.

Besides that, there's potential for more different confusion:
*) Linking with /path/to/lib.so produces different result than 
   linking with /path/to/lib.so.v (difference is in the runpath).
*) dlopen(lib.so) fails, while dlopen(lib.so.v) does work.
*) Provides two distinct files, instead of one single file with symlinks.

 and instead relies on the fact that the AIX linker will take an import file 
 when
 looking for -lfoo, and will record what the import file says.

This very detail isn't anything different compared to aix-soname=svr4.

Leaving alone different confusion, this version of the patch has some real 
problems:

*) Please post patches as plain-text.
*) Breaks test cases in build setups that should be unaffected by this patch
   (I'm using https://github.com/haubi/libtool-testing/ for the different build
   setups to run the testsuite in and compare the results).
*) Why do you change archive_expsym_cmds for $host_cpu = ia64 ?
*) Seems you haven't used 'make distcheck': Tells to not use '==' with 'test'.
*) Prohibits the AIX-style of multilib (multiple shared objects in one archive).
*) Existing site setups using LDFLAGS=-Wl,-brtl will break, as their existing
   binaries depend on the unversioned .so files, which will be replaced by
   plain text files.
   At least something like --with-aix-soname=simple would be necessary.

Thanks for your interest on this topic!
/haubi/



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

2015-05-22 Thread Michael Haubenwallner
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
anyway and would be necessary for LD, STRIP and RANLIB too.

However, I've found some ABI-specific LD-flags settings in _LT_ENABLE_LOCK,
but that would be too late for checking the name lister ($NM) interface.
Besides that, _LT_ENABLE_LOCK feels suboptimal anyway as the place to set
the ABI-specific tool flags based on created object's file type.

So I would like to introduce _LT_SET_TOOL_ABI_FLAG(TOOL, [TOOLVAR]) macro
(patch 2/2), doing something useful for power*-*-aix* for now, but designed
to adopt similar settings from _LT_ENABLE_LOCK by subsequent refactorings.

Thanks!
/haubi/



[PATCH 1/2] Fix func_echo_all inside configure.

2015-05-22 Thread Michael Haubenwallner
* 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 args, space-separated.
 func_echo_all ()
 {
-$ECHO $*
+$ECHO @S|@*
 }
 
 case $ECHO in
-- 
2.0.5




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

2015-05-22 Thread Michael Haubenwallner
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 be some wrapper to operate in 64-bit mode. So we cannot
rely on OBJECT_MODE being set to properly support 64-bit builds.

Instead, we better identify the object mode in use by looking at the
file type of an object file generated by CC, to properly set the
commandline flags for additional tools used within libtool. While there
is similar code for LD in _LT_ENABLE_LOCK, this is too late for NM.

* m4/libtool.m4 (_LT_CACHE_CHECK_OBJECT_FILE_TYPE): New. Provides object
file type identified using /usr/bin/file.
(_LT_PREPARE_TOOLS_ABI_FLAGS): New. Defines func_set_tool_abi_flag.
Define AIX specific ABI flags for LD, AR, NM, STRIP, RANLIB.
Set AIX_OBJECT_MODE as well.
(_LT_SET_TOOL_ABI_FLAG): New. Uses func_set_tool_abi_flag to set host
specific ABI flags into tool commands.
(_LT_PROG_AR): Use _LT_SET_TOOL_ABI_FLAG.
(LT_PATH_LD): Ditto.
(LT_PATH_NM): Ditto.
(_LT_CMD_OLD_ARCHIVE): Use _LT_SET_TOOL_ABI_FLAG for STRIP, RANLIB.
(_LT_LINKER_SHLIBS): Use AIX_OBJECT_MODE.
(_LT_LANG_CXX_CONFIG): Ditto.
* m4/ltoptions.m4 (_LT_WITH_AIX_SONAME): Ditto.
---
 m4/libtool.m4   | 84 ++---
 m4/ltoptions.m4 |  3 ++-
 2 files changed, 83 insertions(+), 4 deletions(-)

diff --git a/m4/libtool.m4 b/m4/libtool.m4
index c42a418..7421075 100644
--- a/m4/libtool.m4
+++ b/m4/libtool.m4
@@ -1177,6 +1177,79 @@ fi
 ])# _LT_SYS_MODULE_PATH_AIX
 
 
+# _LT_CACHE_CHECK_OBJECT_FILE_TYPE
+# 
+# Compiles a minimal program and identifies the file type of that object file.
+# All object files linked together in one build configuration have to be of
+# the same object file type.  As we always need the C compiler anyway, there
+# is no point in checking object file types per TAG.
+m4_defun([_LT_CACHE_CHECK_OBJECT_FILE_TYPE],
+[AC_REQUIRE([AC_PROG_CC])dnl
+m4_require([_LT_DECL_SED])dnl
+m4_require([_LT_PROG_ECHO_BACKSLASH])dnl
+AC_CACHE_CHECK([$CC object file type], [lt_cv_object_file_type],
+  [AC_COMPILE_IFELSE([AC_LANG_PROGRAM],
+[echo $as_me:$LINENO: LC_ALL=C /usr/bin/file conftest.$ac_objext 
AS_MESSAGE_LOG_FD
+lt_cv_object_file_type=`LC_ALL=C /usr/bin/file conftest.$ac_objext 
2AS_MESSAGE_LOG_FD`
+ac_status=$?
+func_echo_all $lt_cv_object_file_type AS_MESSAGE_LOG_FD
+func_echo_all $as_me:$LINENO: \$? = $ac_status AS_MESSAGE_LOG_FD
+lt_cv_object_file_type=`func_echo_all $lt_cv_object_file_type | $SED -e 
s/^conftest\.$ac_objext:  *//`
+])
+  ])
+]) # _LT_CACHE_CHECK_OBJECT_FILE_TYPE
+
+
+# _LT_PREPARE_TOOLS_ABI_FLAGS
+# ---
+m4_defun([_LT_PREPARE_TOOLS_ABI_FLAGS],
+[AC_REQUIRE([AC_CANONICAL_HOST])dnl
+AC_REQUIRE([AC_PROG_CC])dnl
+# func_set_tool_abi_flag TOOL [TOOLVAR]
+# Ensure that TOOL-specific command in $TOOL (or $TOOLVAR if specified) does
+# contain $lt_abi_flag_TOOL (if defined below) as standalone argument.
+# Does nothing if $TOOL (or $TOOLVAR) is empty.
+func_set_tool_abi_flag () {
+  eval AS_CASE([\ \@S|@@S|@{2-@S|@1}  \],
+  ['   '],
+[# command is empty
+],
+  [*\ \@S|@lt_abi_flag_@S|@1 \*],
+[# standalone flag found, or flag is empty
+],
+[@S|@{2-@S|@1}=\\@S|@@S|@{2-@S|@1} \@S|@lt_abi_flag_@S|@1\]
+  )
+}
+
+# PORTME Define flags for various tools to accept the ABI selected by
+# '$CC $CFLAGS $CPPFLAGS'.
+case $host in
+power*-*-aix4.[[3-9]]* | power*-aix[[5-9]]*)
+  _LT_CACHE_CHECK_OBJECT_FILE_TYPE
+  case $ac_status:$lt_cv_object_file_type in
+  0:*64-bit*) AIX_OBJECT_MODE=64 ;;
+  0:*RISC System/6000*) AIX_OBJECT_MODE=32 ;;
+  *) AC_MSG_FAILURE([failed to check $CC generated ABI]) ;;
+  esac
+  lt_abi_flag_LD=-b$AIX_OBJECT_MODE
+  lt_abi_flag_AR=-X$AIX_OBJECT_MODE
+  lt_abi_flag_NM=-X$AIX_OBJECT_MODE
+  lt_abi_flag_STRIP=-X$AIX_OBJECT_MODE
+  lt_abi_flag_RANLIB=-X$AIX_OBJECT_MODE
+  ;;
+esac
+]) # _LT_PREPARE_TOOLS_ABI_FLAGS
+
+
+# _LT_SET_TOOL_ABI_FLAG(TOOL, [TOOLVAR])
+# 
+# Ensure to be defined, and call: func_set_tool_abi_flag TOOL TOOLVAR
+m4_defun([_LT_SET_TOOL_ABI_FLAG],
+[m4_require([_LT_PREPARE_TOOLS_ABI_FLAGS])dnl
+func_set_tool_abi_flag $1 $2
+]) # _LT_SET_TOOL_ABI_FLAG
+
+
 # _LT_SHELL_INIT(ARG)
 # ---
 m4_define([_LT_SHELL_INIT],
@@ -1285,7 +1358,7 @@ m4_defun([_LT_ENABLE_LOCK],
 test no = $enable_libtool_lock || enable_libtool_lock=yes
 
 # Some flags need to be propagated to the compiler or linker for good
-# libtool support.
+# libtool support. Should move to _LT_PREPARE_TOOLS_ABI_FLAGS.
 case $host in
 ia64-*-hpux*)
   # Find out what ABI is being produced by ac_compile, and set mode
@@ -1494,6 +1567,7 @@ m4_defun([_LT_PROG_AR],
 [AC_CHECK_TOOLS(AR, [ar], false)
 : ${AR=ar}
 : ${AR_FLAGS=cru}

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

2014-12-05 Thread Michael Haubenwallner

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 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 DT_SONAME, hence the name aix-soname=svr4.
 
 Much appreciated!  I did make some slight edits after applying, so
 please check that it still works for you.

Yes, testsuite results still works as expected.

One note for the case-separator in tests/versioning.at to remember:
LDFLAGS may contain both ':' and ',' eventually. OTOH, to break here
LDFLAGS value would need to be invalid anyway (sth. like -Wl,,).

Thank you so much!
/haubi/



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

2014-11-25 Thread Michael Haubenwallner
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, the current situation.

 (--with-aix-soname=svr4): Filename-based shared library versioning.

 (--with-aix-soname=both): One shared library is created with the
 filename-based, another one with the in-archive versioning scheme for
 backwards compatibility. The library_names value in the .la file
 specifies either the one or the other, depending on whether the -brtl
 linker flag is specified in LDFLAGS.

Cloned git://git.sv.gnu.org/libtool.git, applied the two patches meanwhile 
pushed here:
http://git.savannah.gnu.org/cgit/libtool.git/log/?id=845ff0b76837a630eb54d23eb66912339b589a65showmsg=1
Doing
  $ ./bootstrap  ./configure  make dist
created libtool-2.4.3.37-ef71.tar.gz as the reference.

Then, applied this one patch to be tested, doing
  $ ./bootstrap  ./configure  make dist
created libtool-2.4.3.38-b0be1.tar.gz as the testee.

For testing all the different setups with different compilers I've pushed
https://github.com/haubi/libtool-testing
The scripts found in aix/ there does testsuite runs with all possible
combinations of these settings:
* gcc/g++, xlc/g++, xlc/xlC as available on the host machine
* 32 and 64 bit
* --with-aix-soname=aix|both|svr4 each, when supported by the testee
* with and without LDFLAGS=-Wl,-brtl

Starting the different test setups
  $ gzip -dc libtool-2.4.3.37-ef71.tar.gz | tar xf -
  $ ./libtool-testing/aix/runtests.sh -j6 libtool-2.4.3.37-ef71 
does the reference's testsuite runs in ./test-libtool-2.4.3.37-ef71/

Similar,
  $ gzip -dc libtool-2.4.3.38-b0be1.tar.gz | tar xf -
  $ ./libtool-testing/aix/runtests.sh -j6 libtool-2.4.3.38-b0be1 
does the testee's testsuite runs in ./test-libtool-2.4.3.38-b0be1/

To compare reference's with testee's test results from all different runs:
  $ ./libtool-testing/aix/analysetests.sh libtool-2.4.3.37-ef71 
test-libtool-2.4.3.3*

Thanks!
/haubi/



[PATCH] AIX: Optional filename-based shlib versioning

2014-11-24 Thread Michael Haubenwallner
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 DT_SONAME, hence the name aix-soname=svr4.

(--with-aix-soname=aix): Default, the current situation.
  (lib.a): When the -brtl linker flag is found in LDFLAGS, create from
static objects only. Otherways, create as traditional shared library
archive from the Shared Object built without runtime linking, with
in-archive versioning.
  (lib.so): When the -brtl linker flag is found in LDFLAGS, create as
the standalone Shared Object built with the -G linker flag, without
any versioning support. Otherways, do not create it at all.
  (executables): When the -brtl linker flag is found in LDFLAGS, prefer
to link against libraries with the .so filename extension.
Otherways, link against libraries with the .a filename extension.
  (module): When the -brtl linker flag is found in LDFLAGS, same as for
lib.so.  Otherways, same as for lib.a.

(--with-aix-soname=svr4): Filename-based shared library versioning.
  (lib.a): Create from static objects.
  (lib.so): Create as shared library archive from the Shared Object
named shr.o or shr_64.o, built with the -G linker flag, and the
F_LOADONLY flag set, plus an Import File named shr.imp or
shr_64.imp, respectively, necessary to allow for filename-based
versioning.
  (executables): Add the -brtl linker flag to LDFLAGS, to prefer linking
against shared libraries with the .so filename extension.
  (module): Same as for lib.so.

(--with-aix-soname=both): One shared library is created with the
filename-based, another one with the in-archive versioning scheme for
backwards compatibility. The library_names value in the .la file
specifies either the one or the other, depending on whether the -brtl
linker flag is specified in LDFLAGS.
  (lib.a): Create as traditional shared library archive from the Shared
Object built without runtime linking, with in-archive versioning.
  (lib.so): Create as shared library archive from the Shared Object
named shr.o or shr_64.o, built with the -G linker flag, and the
F_LOADONLY flag set, plus an Import File named shr.imp or
shr_64.imp, respectively, necessary to allow for filename-based
versioning.
  (executables): When the -brtl linker flag is found in LDFLAGS, prefer
to link against libraries with the .so filename extension.
Otherways, link against libraries with the .a filename extension.
  (module): Same as for both lib.a and lib.so.

* Makefile.am: (TESTS_ENVIRONMENT) Pass with_aix_soname value via
lt_cv_with_aix_soname into testsuite.

* configure.ac: AC_SUBST with_aix_soname.

* libltdl/loaders/dlopen.c: (vm_open) Use RTLD_MEMBER flag for dlopen
when the filename does specify an archive member between ().
Otherways, retry with appending LT_SHARED_LIB_MEMBER when loading fails
without but archive file seems to exist.

* m4/libtool.m4: (dynamic_linker) Describe configured shared library
versioning variant according to with_aix_soname and runtime linking.
(soname_spec, library_names_spec, shlibpath_overrides_runpath,
postinstall_cmds, postuninstall_cmds, hardcode_direct,
hardcode_direct_absolute, no_undefined_flag, allow_undefined_flag) Set
according to with_aix_soname and runtime linking configuration.
(export_symbols_cmds) Decorate symbols with the weak keyword.
(archive_expsym_cmds) Create both shared libraries according to
with_aix_soname and runtime linking configuration. Filter -brtl linker
flag from compiler_flags for shared libraries due to its side effects.
(enable_static) Respect with_aix_soname for disabling as well.

* m4/ltdl.m4: (LT_SHARED_LIB_MEMBER) Define, set based on the value of
the shared_archive_member_spec libtool variable.

* m4/ltoptions.m4: (_LT_WITH_AIX_SONAME) New. Provides commandline
option --with-aix-soname=aix|svr4|both. Declares
(shared_archive_member_spec) as libtool variable.
(_LT_SET_OPTIONS) Define LT_INIT options aix-soname=aix,
aix-soname=svr4, aix-soname=both. Default is aix-soname=aix.

* 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, bitrig, hppa-hpux, interix or openbsd.

* tests/versioning.at: When shared_archive_member_spec is defined and
LDFLAGS contain -brtl, we can run the versioning check.
---
 Makefile.am  |   1 +
 configure.ac |   1 +
 libltdl/loaders/dlopen.c |  40 +
 m4/libtool.m4| 221 ---
 m4/ltdl.m4   |   5 ++
 m4/ltoptions.m4  |  50 +++
 tests/deplibs-ident.at   |  11 ++-
 tests/versioning.at  |  14 ++-
 8 files changed, 306 insertions(+), 37 deletions(-)

diff --git a/Makefile.am 

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

2014-11-21 Thread Michael Haubenwallner
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 --git a/tests/libtool.at b/tests/libtool.at
index a466790..04655dd 100755
--- a/tests/libtool.at
+++ b/tests/libtool.at
@@ -116,14 +116,15 @@ for mode in compile link install; do
   [0], [stdout])
   # NOTE: we use ...''... to insert a literal quote into the expression
   #   because ...\... is not expanded consistently by all shells.
-  AT_CHECK([$GREP 
$mode:.*$match_preflag'\?'$flag:test'\? ' stdout],
+  AT_CHECK([$EGREP $mode:.*$match_preflag'?'$flag:test'? 
' stdout],
  [0], [ignore])
 
   # Shell metacharacters that should be backslashified by libtool.
   for mchar in \ \` \$; do
 AT_CHECK([$LIBTOOL -n --mode=$mode $preargs 
$preflag$flag$mchar:test$mchar $postargs],
 [0], [stdout])
-AT_CHECK([$GREP 
$mode:.*$match_preflag''\?$flag$mchar:test$mchar''\?  stdout], 
[0], [ignore])
+test \$ = $mchar  mchar=\\$mchar # for $EGREP
+AT_CHECK([$EGREP 
$mode:.*$match_preflag''?$flag$mchar:test$mchar''?  stdout], 
[0], [ignore])
   done
 
   # Shell metacharacters that should be double quoted by libtool, and need
-- 
1.8.5.5




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

2014-11-21 Thread Michael Haubenwallner
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 | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/tests/template.at b/tests/template.at
index a5bfcef..da9ed0f 100644
--- a/tests/template.at
+++ b/tests/template.at
@@ -129,10 +129,12 @@ LT_AT_TAG([CXX])
 AT_KEYWORDS([libtool])
 
 noskip=:
+withundef=:
 # Mac OS X.
 # The linker has issues with this test.
 case $host in
 *-darwin*) noskip=false ;;
+*-aix*) withundef=false ;;
 esac
 
 
@@ -243,7 +245,7 @@ AT_CHECK([$LIBTOOL --tag=CXX --mode=link $CXX $CXXFLAGS 
$LDFLAGS -o sub/main$EXE
 [0], [ignore], [ignore])
 LT_AT_EXEC_CHECK([./sub/main], [ignore])
 # lib convenience
-if $noskip; then
+if $noskip  $withundef; then
   AT_CHECK([$LIBTOOL --tag=CXX --mode=link $CXX $CXXFLAGS $LDFLAGS -o 
lib2/libb.la lib2/b.lo -rpath /foo],
   [0], [ignore], [ignore])
   AT_CHECK([$LIBTOOL --tag=CXX --mode=link $CXX $CXXFLAGS $LDFLAGS -o 
sub/main$EXEEXT $main_o lib2/libb.la lib/liba.la],
@@ -254,11 +256,13 @@ fi
 # both installed
 AT_CHECK([$LIBTOOL --tag=CXX --mode=link $CXX $CXXFLAGS $LDFLAGS -o 
lib/liba.la lib/a.lo -rpath /foo],
 [0], [ignore], [ignore])
+if $withundef; then
 AT_CHECK([$LIBTOOL --tag=CXX --mode=link $CXX $CXXFLAGS $LDFLAGS -o 
lib2/libb.la lib2/b.lo -rpath /bar],
 [0], [ignore], [ignore])
 AT_CHECK([$LIBTOOL --tag=CXX --mode=link $CXX $CXXFLAGS $LDFLAGS -o 
sub/main$EXEEXT $main_o lib2/libb.la lib/liba.la],
 [0], [ignore], [ignore])
 LT_AT_EXEC_CHECK([./sub/main])
+fi
 # both convenience, libb depending on liba
 AT_CHECK([$LIBTOOL --tag=CXX --mode=link $CXX $CXXFLAGS $LDFLAGS -o 
lib/liba.la lib/a.lo],
 [0], [ignore], [ignore])
-- 
1.8.5.5




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

2014-11-21 Thread Michael Haubenwallner

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 more \ for $.
 
 Or, stick with GREP but use \{0,1\} instead of \?.

Possible as well, thanks!
/haubi/
From d11a1079e84949cb9067f0109e33a82259817fe6 Mon Sep 17 00:00:00 2001
From: Michael Haubenwallner michael.haubenwall...@ssi-schaefer.com
Date: Fri, 21 Nov 2014 15:49:19 +0100
Subject: [PATCH 1/2] 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: Use \{0,1\} instead of ? with GREP.
---
 tests/libtool.at | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/tests/libtool.at b/tests/libtool.at
index a466790..7431820 100755
--- a/tests/libtool.at
+++ b/tests/libtool.at
@@ -116,14 +116,14 @@ for mode in compile link install; do
 	   [0], [stdout])
   # NOTE: we use ...''... to insert a literal quote into the expression
   #   because ...\... is not expanded consistently by all shells.
-  AT_CHECK([$GREP $mode:.*$match_preflag'\?'$flag:test'\? ' stdout],
+  AT_CHECK([$GREP $mode:.*$match_preflag'\{0,1\}'$flag:test'\{0,1\} ' stdout],
 	  [0], [ignore])
 
   # Shell metacharacters that should be backslashified by libtool.
   for mchar in \ \` \$; do
 AT_CHECK([$LIBTOOL -n --mode=$mode $preargs $preflag$flag$mchar:test$mchar $postargs],
 	 [0], [stdout])
-AT_CHECK([$GREP $mode:.*$match_preflag''\?$flag$mchar:test$mchar''\?  stdout], [0], [ignore])
+AT_CHECK([$GREP $mode:.*$match_preflag''\{0,1\}$flag$mchar:test$mchar''\{0,1\}  stdout], [0], [ignore])
   done
 
   # Shell metacharacters that should be double quoted by libtool, and need
-- 
1.8.5.5



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

2012-10-17 Thread Michael Haubenwallner

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 versioning support, but
still far from being ideal for package managers, as they have to deal with
flags (F_LOADONLY) of Shared Objects, and merge them inside archive files,
maybe conflicting with existing archives with the same name in /usr/lib/.
But /with/ runtime linking, there is no versioning support in libtool at
all, while - even worse - the symlinks do suggest the opposite.

Anyone about (to consider) to look at these patches?

Thank you!
/haubi/



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

2012-10-02 Thread Michael Haubenwallner
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 package managers, as they have to deal with
   flags (F_LOADONLY) of Shared Objects, and merge them inside archive files,
   maybe conflicting with existing archives with the same name in /usr/lib/.
   But /with/ runtime linking, there is no versioning support in libtool at
   all, while - even worse - the symlinks do suggest the opposite.

With Import Files, it is possible to have filename-based versioning support on
AIX, using those symlinks known from Linux. However, Import Files prevent
static linking, so these should be used with the .so filename extension only.
But this requires to enable runtime linking via the -brtl (or -G) linker flag.

While there is a bunch of variants available to use Import Files, it turns
out to be easiest to put both a Shared Object named shr.o and an Import
File named shr.imp into an archive file named libN.so.X, having the
F_LOADONLY flag set for shr.o. This allows to have the symlink libN.so
referring to libN.so.X work as expected (as known from Linux).

I do call this the aix-soname right now, but more obvious names are welcome.

Unfortunately, this is incompatible with the current implementation /with/
runtime linking, as current lib.so is a standalone Shared Object rather
than an archive file. Replacing that lib.so by (a symlink to) an archive
file will break existing binaries built against (or inside) an existing site
which has enabled the current implementation of runtime linking.

So I'd like to introduce the configure switch --enable-aix-soname, to
explicitly allow package /managers/ to enable the aix-soname for their site.
Additionally, package /maintainers/ can enable aix-soname with LT_INIT,
usually along some version bump, while still allowing package /managers/ to
--disable-aix-soname.

The patches can be split into a few chunks with different goals. For each
chunk there is a bootstrapped snapshot available. Also, there is a script to
run the tests with different setups, to be used as:
$ ./runtests libtool-2.4.2.1*.tar.gz
http://dev.gentoo.org/~haubi/libtool/aix-soname-r1/runtests

[00]: Current master.
http://dev.gentoo.org/~haubi/libtool/aix-soname-r1/libtool-2.4.2.177-d674ea.tar.gz

[01..04]: Support lt_dlopen(libN.la) with shared archive members, to fix
the current situation /without/ runtime linking.
Fixes these tests /without/ LDFLAGS=-brtl:
85: libdir of installed modules ok, was: FAILED (ltdl-libdir.at)
   110: C++ exception handling  ok, was: FAILED (exceptions.at)
No changes in test results /with/ LDFLAGS=-brtl.
http://dev.gentoo.org/~haubi/libtool/aix-soname-r1/libtool-2.4.2.181-caaf.tar.gz

[05..06]: Fix -no-undefined flag for current LDFLAGS=-brtl implementation.
There aren't any tests that expose a problem, but the -no-undefined flag
doesn't work as expected. And the symlinks really are useless - the versioning
test is skipped for a reason.
These patches aren't a real prerequisite, but the linkline fixed here serves
as template for the linkline used in aix-soname later.
http://dev.gentoo.org/~haubi/libtool/aix-soname-r1/libtool-2.4.2.183-62c0.tar.gz

[07..10]: Introduce optional filename-based shared library versioning, also
called the aix-soname. Tweak tests to respect aix-soname for expected
results. Using --enable-aix-soname also does set LDFLAGS=-brtl, so the test
results need to be compared against those /with/ runtime linking:
   72: versioning   ok,   was: skipped (versioning.at)
  115: build tree relpaths  expected failure, was: ok  (deplibs-ident.at)
This one is broken /without/ runtime linking already, but (kind of) works
/with/. However, it also breaks with aix-soname enabled - see patch [11]:
  108: template test with subdirs FAILED, was: ok (template.at)
http://dev.gentoo.org/~haubi/libtool/aix-soname-r1/libtool-2.4.2.187-5fb50.tar.gz

[11]: The template test expects undefined symbols in libB to trigger libA
being kept when the executable not needing libA itself is linked against both.
This test does succeed /with/ LDFLAGS=-brtl currently: Not because of the
symbols, but standalone Shared Objects being referenced /unconditionally/.
http://dev.gentoo.org/~haubi/libtool/aix-soname-r1/libtool-2.4.2.188-1d353.tar.gz

[12]: Not meant to be pushed (right now), but to have the traditional TESTS
also run with aix-soname enabled. I've been unable to find out how to pass
--enable-aix-soname to subsequent configure runs in make check-TESTS.
http://dev.gentoo.org/~haubi/libtool/aix-soname-r1/libtool-2.4.2.189-06d1.tar.gz

While there's lots of inline commenting that should explain the ideas behind,
please tell if/where/how more documentation is needed.

Thank you for consideration!
/haubi/



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

2012-10-02 Thread Michael Haubenwallner
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
specifying an archive member as the to-be-loaded shared object.
* libltdl/loaders/dlopen.c: (vm_open) Use RTLD_MEMBER flag for dlopen
when the filename does specify an archive member between ().
---
 libltdl/loaders/dlopen.c |   18 
 libltdl/ltdl.c   |  202 --
 2 files changed, 178 insertions(+), 42 deletions(-)

diff --git a/libltdl/loaders/dlopen.c b/libltdl/loaders/dlopen.c
index e8180e1..a71f5e0 100644
--- a/libltdl/loaders/dlopen.c
+++ b/libltdl/loaders/dlopen.c
@@ -168,6 +168,9 @@ vm_open (lt_user_data LT__UNUSED loader_data, const char 
*filename,
 {
   int  module_flags = LT_LAZY_OR_NOW;
   lt_modulemodule;
+#ifdef RTLD_MEMBER
+  int  len = LT_STRLEN (filename);
+#endif
 
   if (advise)
 {
@@ -191,6 +194,21 @@ vm_open (lt_user_data LT__UNUSED loader_data, const char 
*filename,
 #endif
 }
 
+#ifdef RTLD_MEMBER /* AIX */
+  if (len)
+{
+  /* Advise loading an archive member only if the filename
+really contains both the opening and closing parent. */
+  const char *closing = strrchr(filename ? filename : , ')');
+  if (closing  STREQ(closing, )))
+   {
+ const char *opening = strrchr(filename, '(');
+ if (opening  strchr(opening, '/') == NULL)
+   module_flags |= RTLD_MEMBER;
+   }
+}
+#endif
+
   module = dlopen (filename, module_flags);
 
   if (!module)
diff --git a/libltdl/ltdl.c b/libltdl/ltdl.c
index 0dea0c8..c958d79 100644
--- a/libltdl/ltdl.c
+++ b/libltdl/ltdl.c
@@ -58,6 +58,12 @@ or obtained by writing to the Free Software Foundation, Inc.,
 #  define LT_LIBPREFIX lib
 #endif
 
+/* how shared archive members are specified, seen on AIX only */
+#undef LT_SHARED_LIB_MEMBER
+#if defined _AIX
+#  define LT_SHARED_LIB_MEMBER () /* need the parentheses only */
+#endif
+
 /* This is the maximum symbol size that won't require malloc/free */
 #undef LT_SYMBOL_LENGTH
 #define LT_SYMBOL_LENGTH   128
@@ -77,6 +83,9 @@ staticconst char  objdir[]= 
LT_OBJDIR;
 static const char  archive_ext[]   = LT_ARCHIVE_EXT;
 static  const char libext[]= LT_LIBEXT;
 static  const char libprefix[] = LT_LIBPREFIX;
+#if defined LT_SHARED_LIB_MEMBER
+static const char  shared_lib_member[] = LT_SHARED_LIB_MEMBER;
+#endif
 #if defined LT_MODULE_EXT
 static const char  shlib_ext[] = LT_MODULE_EXT;
 #endif
@@ -127,7 +136,6 @@ static  int find_module   (lt_dlhandle 
*handle, const char *dir,
   const char *libdir, const char *dlname,
   const char *old_name, int installed,
   lt_dladvise advise);
-static  int has_library_ext   (const char *filename);
 static int load_deplibs  (lt_dlhandle handle,  char *deplibs);
 static int trim  (char **dest, const char *str);
 static int try_dlopen(lt_dlhandle *handle,
@@ -582,6 +590,97 @@ find_module (lt_dlhandle *handle, const char *dir, const 
char *libdir,
   return 1;
 }
 
+/* Identify extension and optional shared archive member of a library FILENAME.
+   Sets *PMEMBER to the member specification found, or end of FILENAME.
+   Sets *PEXT to the extension found, or to *PMEMBER - may be end of FILENAME.
+   When FILENAME is NULL, *PEXT and *PMEMBER are set to NULL.
+   With ANY_EXT, FILENAME must not containy any path, and '.' is used to
+   search for the extension. */
+static void
+identify_library_ext_member(const char *filename,
+   const char **pext, const char **pmember, int any_ext)
+{
+  size_t len;
+  size_t extlen;
+
+  assert (pext);
+  assert (pmember);
+
+  len = LT_STRLEN (filename); /* enough to work with filename == NULL */
+
+  *pmember = filename + len; /* member specification is identified later */
+
+  extlen = LT_STRLEN(archive_ext);
+  if (len  extlen  STREQ (filename + len - extlen, archive_ext))
+{
+  /* with libtool archive, member specification is unsupported */
+  *pext = filename + len - extlen;
+  return;
+}
+
+#if defined LT_SHARED_LIB_MEMBER
+  /* Take first and last char of shared_lib_member as the parentheses,
+ and ensure there is something in between the parentheses. */
+  extlen = LT_STRLEN(shared_lib_member);
+  if (len  3  extlen = 2
+filename[len-1] == shared_lib_member[extlen-1]) /* closing */
+{
+  const char *member;
+  member = strrchr(filename, shared_lib_member[0]); /* opening */
+  if (member  member = filename + len - 3) /* something in between */
+   {
+ *pmember = 

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

2012-10-02 Thread Michael Haubenwallner
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 insertions(+), 1 deletions(-)

diff --git a/tests/template.at b/tests/template.at
index 621137d..29aa3cb 100644
--- a/tests/template.at
+++ b/tests/template.at
@@ -129,10 +129,12 @@ LT_AT_TAG([CXX])
 AT_KEYWORDS([libtool])
 
 noskip=:
+withundef=:
 # Mac OS X.
 # The linker has issues with this test.
 case $host in
 *-darwin*) noskip=false ;;
+*-aix*) withundef=false ;;
 esac
 
 
@@ -243,7 +245,7 @@ AT_CHECK([$LIBTOOL --tag=CXX --mode=link $CXX $CXXFLAGS 
$LDFLAGS -o sub/main$EXE
 [0], [ignore], [ignore])
 LT_AT_EXEC_CHECK([./sub/main], [ignore])
 # lib convenience
-if $noskip; then
+if $noskip  $withundef; then
   AT_CHECK([$LIBTOOL --tag=CXX --mode=link $CXX $CXXFLAGS $LDFLAGS -o 
lib2/libb.la lib2/b.lo -rpath /foo],
   [0], [ignore], [ignore])
   AT_CHECK([$LIBTOOL --tag=CXX --mode=link $CXX $CXXFLAGS $LDFLAGS -o 
sub/main$EXEEXT $main_o lib2/libb.la lib/liba.la],
@@ -254,11 +256,13 @@ fi
 # both installed
 AT_CHECK([$LIBTOOL --tag=CXX --mode=link $CXX $CXXFLAGS $LDFLAGS -o 
lib/liba.la lib/a.lo -rpath /foo],
 [0], [ignore], [ignore])
+if $withundef; then
 AT_CHECK([$LIBTOOL --tag=CXX --mode=link $CXX $CXXFLAGS $LDFLAGS -o 
lib2/libb.la lib2/b.lo -rpath /bar],
 [0], [ignore], [ignore])
 AT_CHECK([$LIBTOOL --tag=CXX --mode=link $CXX $CXXFLAGS $LDFLAGS -o 
sub/main$EXEEXT $main_o lib2/libb.la lib/liba.la],
 [0], [ignore], [ignore])
 LT_AT_EXEC_CHECK([./sub/main])
+fi
 # both convenience, libb depending on liba
 AT_CHECK([$LIBTOOL --tag=CXX --mode=link $CXX $CXXFLAGS $LDFLAGS -o 
lib/liba.la lib/a.lo],
 [0], [ignore], [ignore])
-- 
1.7.3.4




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

2012-10-02 Thread Michael Haubenwallner
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 insertions(+), 2 deletions(-)

diff --git a/m4/libtool.m4 b/m4/libtool.m4
index 503bbc3..0c429d3 100644
--- a/m4/libtool.m4
+++ b/m4/libtool.m4
@@ -2290,8 +2290,8 @@ aix[[4-9]]*)
 if test yes = $aix_use_runtimelinking; then
   # If using run time linking (on AIX 4.2 or later) use libname.so
   # instead of libname.a to let people know that these are not
-  # typical AIX shared libraries.
-  library_names_spec='$libname$release$shared_ext$versuffix 
$libname$release$shared_ext$major $libname$shared_ext'
+  # typical AIX shared libraries. But there is no versioning support.
+  library_names_spec='$libname$release$shared_ext $libname$shared_ext'
 else
   # We preserve .a as extension for shared libraries through AIX4.2
   # and later when we are not doing run time linking.
-- 
1.7.3.4




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

2012-10-02 Thread Michael Haubenwallner
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 --disable-aix-soname.
  This is the current situation.
  (lib.a): When the -brtl linker flag is found in LDFLAGS, create from
static objects only. Otherways, create as traditional shared library
archive from the Shared Object built without runtime linking, with
in-archive versioning.
  (lib.so): When the -brtl linker flag is found in LDFLAGS, create as
the standalone Shared Object built with the -G linker flag, without
any versioning support. Otherways, do not create it at all.
  (executables): When the -brtl linker flag is found in LDFLAGS, prefer
to link against libraries with the .so filename extension.
Otherways, link against libraries with the .a filename extension.
  (module): When the -brtl linker flag is found in LDFLAGS, same as
lib.so.  Otherways, same as lib.a.
(aix-soname=yes): This is the new situation.
  (lib.a): Create from static objects.
  (lib.so): Create as shared library archive from the Shared Object
named shr.o or shr_64.o, built with the -G linker flag, and the
F_LOADONLY flag set, plus an Import File named shr.imp or
shr_64.imp, respectively, necessary to allow for filename-based
versioning.
  (executables): Add the -brtl linker flag to LDFLAGS, to prefer linking
against shared libraries with the .so filename extension.
  (module): Same as lib.so.
* m4/libtool.m4: Support the aix-soname.
* libltdl/ltdl.c: (LT_SHARED_LIB_MEMBER) When not defined by configure
because of --disable-aix-soname, still define for AIX again to allow for
loading foreign libtool archives specifying an archive member.
* libltdl/loaders/dlopen.c: (vm_open) When LT_SHARED_LIB_MEMBER is
defined, and we are advised to try known extensions (from lt_dlopenext),
and no shared archive member was specified, and dlopen fails with Exec
format error, indicating the requested file was found but cannot be
loaded as standalone Shared Object, try again with specifying the
default shared archive member.
---
 libltdl/loaders/dlopen.c |   25 +
 libltdl/ltdl.c   |   10 ++-
 m4/libtool.m4|  226 --
 3 files changed, 189 insertions(+), 72 deletions(-)

diff --git a/libltdl/loaders/dlopen.c b/libltdl/loaders/dlopen.c
index a71f5e0..434083f 100644
--- a/libltdl/loaders/dlopen.c
+++ b/libltdl/loaders/dlopen.c
@@ -211,6 +211,31 @@ vm_open (lt_user_data LT__UNUSED loader_data, const char 
*filename,
 
   module = dlopen (filename, module_flags);
 
+#if defined RTLD_MEMBER  defined LT_SHARED_LIB_MEMBER
+  if (!module  len  !(module_flags  RTLD_MEMBER) 
+  advise  advise-try_ext  errno == ENOEXEC)
+{
+  /* Loading without a member specified failed with Exec format error.
+So the file is there, but either has wrong bitwidth, or is an
+archive eventually containing the default shared archive member.
+We're advised to try known extensions, so we try with that member:
+The worst case is to get the same error again. */
+  const char *member = LT_SHARED_LIB_MEMBER;
+
+  char *attempt = MALLOC (char, len + strlen (member) + 1);
+  if (!attempt)
+   {
+ LT__SETERROR (NO_MEMORY);
+ return module;
+   }
+
+  sprintf (attempt, %s%s, filename, member);
+  module = vm_open (loader_data, attempt, advise);
+  FREE (attempt);
+  return module;
+}
+#endif
+
   if (!module)
 {
   DL__SETERROR (CANNOT_OPEN);
diff --git a/libltdl/ltdl.c b/libltdl/ltdl.c
index c958d79..9db8b41 100644
--- a/libltdl/ltdl.c
+++ b/libltdl/ltdl.c
@@ -58,10 +58,12 @@ or obtained by writing to the Free Software Foundation, 
Inc.,
 #  define LT_LIBPREFIX lib
 #endif
 
-/* how shared archive members are specified, seen on AIX only */
-#undef LT_SHARED_LIB_MEMBER
-#if defined _AIX
-#  define LT_SHARED_LIB_MEMBER () /* need the parentheses only */
+#if !defined LT_SHARED_LIB_MEMBER  defined _AIX
+/* Even if dlopen.c does not try to append the shared archive member,
+   still allow to load shared archive members used in foreign .la
+   files built with --enable-aix-soname.
+   Here, only the parentheses are needed actually. */
+#  define LT_SHARED_LIB_MEMBER ()
 #endif
 
 /* This is the maximum symbol size that won't require malloc/free */
diff --git a/m4/libtool.m4 b/m4/libtool.m4
index 0c429d3..d9976d7 100644
--- a/m4/libtool.m4
+++ b/m4/libtool.m4
@@ -2284,19 +2284,58 @@ aix[[4-9]]*)
   fi
   ;;
 esac
-# AIX (on Power*) has no versioning support, so currently we cannot 
hardcode correct
-# soname into executable. Probably we can add versioning support to
-# collect2, so additional links can be useful in future.
-if test yes = 

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

2012-10-02 Thread Michael Haubenwallner
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 runtime linking.
(allow_undefined_flag) Undefine for AIX runtime linking.
(archive_expsym_cmds) Reorder to have -G before $no_undefined_flag.
---
 m4/libtool.m4 |   12 
 1 files changed, 4 insertions(+), 8 deletions(-)

diff --git a/m4/libtool.m4 b/m4/libtool.m4
index 88d8799..503bbc3 100644
--- a/m4/libtool.m4
+++ b/m4/libtool.m4
@@ -5053,14 +5053,12 @@ _LT_EOF
   # underscore (_), so it is better to generate a list of symbols to 
export.
   _LT_TAGVAR(always_export_symbols, $1)=yes
   if test yes = $aix_use_runtimelinking; then
-   # Warning - without using the other runtime loading flags (-brtl),
-   # -berok will link without error, but may produce a broken library.
-   _LT_TAGVAR(allow_undefined_flag, $1)='-berok'
+   _LT_TAGVAR(no_undefined_flag, $1)=' $wl-bernotok'
 # Determine the default libpath from the value encoded in an
 # empty executable.
 _LT_SYS_MODULE_PATH_AIX([$1])
 _LT_TAGVAR(hardcode_libdir_flag_spec, 
$1)='$wl-blibpath:$libdir:'$aix_libpath
-_LT_TAGVAR(archive_expsym_cmds, $1)='$CC -o $output_objdir/$soname 
$libobjs $deplibs $wl'$no_entry_flag' $compiler_flags `if test -n 
$allow_undefined_flag; then func_echo_all $wl$allow_undefined_flag; else :; 
fi` $wl'$exp_sym_flag:\$export_symbols' '$shared_flag
+_LT_TAGVAR(archive_expsym_cmds, $1)='$CC -o $output_objdir/$soname 
$libobjs $deplibs $wl'$no_entry_flag' $compiler_flags 
'$shared_flag'$allow_undefined_flag $wl'$exp_sym_flag:\$export_symbols
   else
if test ia64 = $host_cpu; then
  _LT_TAGVAR(hardcode_libdir_flag_spec, $1)='$wl-R 
$libdir:/usr/lib:/lib'
@@ -6043,15 +6041,13 @@ if test yes != $_lt_caught_CXX_error; then
# export.
 _LT_TAGVAR(always_export_symbols, $1)=yes
 if test yes = $aix_use_runtimelinking; then
-  # Warning - without using the other runtime loading flags (-brtl),
-  # -berok will link without error, but may produce a broken library.
-  _LT_TAGVAR(allow_undefined_flag, $1)='-berok'
+  _LT_TAGVAR(no_undefined_flag, $1)=' $wl-bernotok'
   # Determine the default libpath from the value encoded in an empty
   # executable.
   _LT_SYS_MODULE_PATH_AIX([$1])
   _LT_TAGVAR(hardcode_libdir_flag_spec, 
$1)='$wl-blibpath:$libdir:'$aix_libpath
 
-  _LT_TAGVAR(archive_expsym_cmds, $1)='$CC -o $output_objdir/$soname 
$libobjs $deplibs $wl'$no_entry_flag' $compiler_flags `if test -n 
$allow_undefined_flag; then func_echo_all $wl$allow_undefined_flag; else :; 
fi` $wl'$exp_sym_flag:\$export_symbols' '$shared_flag
+  _LT_TAGVAR(archive_expsym_cmds, $1)='$CC -o $output_objdir/$soname 
$libobjs $deplibs $wl'$no_entry_flag' $compiler_flags 
'$shared_flag'$allow_undefined_flag $wl'$exp_sym_flag:\$export_symbols
 else
   if test ia64 = $host_cpu; then
_LT_TAGVAR(hardcode_libdir_flag_spec, $1)='$wl-R 
$libdir:/usr/lib:/lib'
-- 
1.7.3.4




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

2012-10-02 Thread Michael Haubenwallner
---
 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 disable-fast-install],
   [_LT_ENABLE_FAST_INSTALL])
   _LT_UNLESS_OPTIONS([LT_INIT], [aix-soname disable-aix-soname],
-  [_LT_ENABLE_AIX_SONAME(no)])
+  [_LT_ENABLE_AIX_SONAME(yes)])
   ])
 ])# _LT_SET_OPTIONS
 
-- 
1.7.3.4




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

2012-10-02 Thread Michael Haubenwallner
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 disabled.
* m4/ltdl.m4: (LT_SHARED_LIB_MEMBER) Define, based on the value of
the shared_archive_member_spec libtool variable.
---
 m4/ltdl.m4  |5 +
 m4/ltoptions.m4 |   32 
 2 files changed, 37 insertions(+), 0 deletions(-)

diff --git a/m4/ltdl.m4 b/m4/ltdl.m4
index 28c39a9..c4a3171 100644
--- a/m4/ltdl.m4
+++ b/m4/ltdl.m4
@@ -566,6 +566,11 @@ if test $libltdl_cv_shrext != $libltdl_cv_shlibext; 
then
   AC_DEFINE_UNQUOTED([LT_SHARED_EXT], [$libltdl_cv_shrext],
 [Define to the shared library suffix, say, .dylib.])
 fi
+if test -n $shared_archive_member_spec; then
+  m4_pattern_allow([LT_SHARED_LIB_MEMBER])dnl
+  AC_DEFINE_UNQUOTED([LT_SHARED_LIB_MEMBER], 
[($shared_archive_member_spec.o)],
+[Define to the shared archive member specification, say (shr.o).])
+fi
 ])# LT_SYS_MODULE_EXT
 
 # Old name:
diff --git a/m4/ltoptions.m4 b/m4/ltoptions.m4
index 13da361..6f53562 100644
--- a/m4/ltoptions.m4
+++ b/m4/ltoptions.m4
@@ -82,6 +82,8 @@ m4_if([$1],[LT_INIT],[
   _LT_UNLESS_OPTIONS([LT_INIT], [pic-only no-pic], [_LT_WITH_PIC])
   _LT_UNLESS_OPTIONS([LT_INIT], [fast-install disable-fast-install],
   [_LT_ENABLE_FAST_INSTALL])
+  _LT_UNLESS_OPTIONS([LT_INIT], [aix-soname disable-aix-soname],
+  [_LT_ENABLE_AIX_SONAME(no)])
   ])
 ])# _LT_SET_OPTIONS
 
@@ -319,6 +321,36 @@ dnl AC_DEFUN([AC_ENABLE_FAST_INSTALL], [])
 dnl AC_DEFUN([AM_DISABLE_FAST_INSTALL], [])
 
 
+# _LT_ENABLE_AIX_SONAME([DEFAULT])
+# --
+# implement the --enable-aix-soname flag, and support the `aix-soname'
+# and `disable-aix-soname' LT_INIT options.
+# DEFAULT is either `yes' or `no'.  If omitted, it defaults to `no'.
+m4_define([_LT_ENABLE_AIX_SONAME],
+[m4_define([_LT_ENABLE_AIX_SONAME_DEFAULT], [m4_if($1, yes, yes, no)])dnl
+AC_ARG_ENABLE([aix-soname],
+[AS_HELP_STRING([--enable-aix-soname],
+[On AIX, do filename based shared library versioning (using Import Files),
+  for use with runtime linking only. 
@:@default=]_LT_ENABLE_AIX_SONAME_DEFAULT[@:@.])],
+[case $enableval in
+  yes) enable_aix_soname=yes ;;
+  no) enable_aix_soname=no ;;
+  *) AC_MSG_ERROR([invalid value for 'aix-soname']) ;;
+esac],
+[enable_aix_soname=]_LT_ENABLE_AIX_SONAME_DEFAULT)
+case $host_cpu-$host_os in
+  powerpc*-aix*) ;;
+  *) enable_aix_soname=no ;;
+esac
+
+_LT_DECL([], [shared_archive_member_spec], [0],
+[Shared archive member basename, for filename based shared library 
versioning on AIX])dnl
+])# _LT_ENABLE_AIX_SONAME
+
+LT_OPTION_DEFINE([LT_INIT], [aix-soname], [_LT_ENABLE_AIX_SONAME([yes])])
+LT_OPTION_DEFINE([LT_INIT], [disable-aix-soname], 
[_LT_ENABLE_AIX_SONAME([no])])
+
+
 # _LT_WITH_PIC([MODE])
 # 
 # implement the --with-pic flag, and support the `pic-only' and `no-pic'
-- 
1.7.3.4




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

2012-10-02 Thread Michael Haubenwallner
* 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 --git a/build-aux/ltmain.m4sh b/build-aux/ltmain.m4sh
index 14f3c37..22b56a1 100644
--- a/build-aux/ltmain.m4sh
+++ b/build-aux/ltmain.m4sh
@@ -1777,10 +1777,20 @@ func_mode_execute ()
func_dirname $file  .
dir=$func_dirname_result
 
-   if test -f $dir/$objdir/$dlname; then
+   # dlname may be archive(member) on AIX
+   case $dlname in
+   *'('*')')
+ # func_stripname does not work with '(*)',
+ # need to pass '(member)' instead.
+ func_stripname '' `IFS='()'; set -- $dlname; echo \($2)\` 
$dlname
+ ;;
+   *) func_stripname_result=$dlname ;;
+   esac
+
+   if test -f $dir/$objdir/$func_stripname_result; then
  func_append dir /$objdir
else
- if test ! -f $dir/$dlname; then
+ if test ! -f $dir/$func_stripname_result; then
func_fatal_error cannot find \`$dlname' in \`$dir' or 
\`$dir/$objdir'
  fi
fi
-- 
1.7.3.4




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

2012-10-02 Thread Michael Haubenwallner
* 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 deletions(-)

diff --git a/tests/deplibs-ident.at b/tests/deplibs-ident.at
index 92372ec..5e981a9 100644
--- a/tests/deplibs-ident.at
+++ b/tests/deplibs-ident.at
@@ -67,10 +67,13 @@ int main() { return a1() + a2() + a3() + c(); }
   AT_CHECK([$LIBTOOL --mode=link $CC $CFLAGS $LDFLAGS -o b$EXEEXT b.$OBJEXT 
../liba1.la ../liba2.la ../liba3.la ../../c/libcee.la -rpath /nowhere],
   [0],[stdout],[ignore])
   AT_CHECK([$EGREP 'cee.*cee' stdout], 1, [ignore], [ignore])
-  AT_XFAIL_IF([case $host in
- *-*-aix*|hppa*-*-hpux*|*-*-interix*|*-*-openbsd*) false;;
- *):;;
-   esac])
+  AT_XFAIL_IF([dnl
+eval `$LIBTOOL --config | $EGREP 
'^hardcode_(direct|direct_absolute|action)='`
+case $hardcode_action:$hardcode_direct:$hardcode_direct_absolute in
+  relink:yes:no) :;;
+  *:no:*) :;;
+  *:*:*) false;;
+esac])
   dnl This is currently broken in libtool
 )
 
-- 
1.7.3.4




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

2012-10-02 Thread Michael Haubenwallner
* 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
--- a/tests/versioning.at
+++ b/tests/versioning.at
@@ -24,7 +24,7 @@
 AT_SETUP([versioning])
 AT_KEYWORDS([libtool])
 
-eval `$LIBTOOL --config | $EGREP '^(objdir|host_os)='`
+eval `$LIBTOOL --config | $EGREP 
'^(objdir|host_os|shared_archive_member_spec)='`
 
 # Setup some library and program sources:
 # a library (a1), a new revision (a2), a compatible update (a3),
@@ -228,9 +228,10 @@ AT_CHECK([$LIBTOOL --mode=link $CC $CFLAGS $LDFLAGS -o 
liba.la liba4.lo ]dnl
 AT_CHECK([$LIBTOOL --mode=install cp liba.la $libdir], [], [ignore], [ignore])
 AT_CHECK([$LIBTOOL --mode=clean rm -f liba.la], [], [ignore], [ignore])
 
-# This test does not work on AIX, not even with runtimelinking, because
-# the linker always records the unversioned name as dependency.
-AT_CHECK([:; case $host_os in aix*) exit 77;; esac])
+# This test does work on AIX when the 'aix-soname' feature is enabled only,
+# which is reflected in shared_archive_member_spec set. Otherways, even with
+# runtimelinking, the linker always records the unversioned name as dependency.
+AT_CHECK([:; case $shared_archive_member_spec:$host_os in :aix*) exit 77;; 
esac])
 
 test_installed
 
-- 
1.7.3.4




[PATCH] Respect CONFIG_SHELL in make dist.

2012-09-06 Thread Michael Haubenwallner
* 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):
$(AM_V_at)dir=`echo '$@' |'$(SED)' 's|^[^/]*$$|.|;s|/[^/]*$$||'`; \
test -d $$dir || mkdir $$dir || exit 1; \
abs_srcdir=`$(lt__cd) '$(srcdir)'  pwd`; \
-   (cd $$dir  $$abs_srcdir/$$dir/configure --with-dist) || exit 1
+   (cd $$dir  CONFIG_SHELL='$(SHELL)' '$(SHELL)' 
$$abs_srcdir/$$dir/configure --with-dist) || exit 1
 
 
 ##  ##
-- 
1.7.3.4




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

2011-07-25 Thread Michael Haubenwallner
Hello Ralf!

On AIX, when runtime linking is in effect, '-G' linker flag is used
to create the shared objects - which allows undefined symbols.

But libtool.m4 defines the allow_undefined_flag (=-berok) instead
of the no_undefined_flag (=-bernotok), which actually renders the
-no-undefined libtool 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.
+   * libltdl/m4/libtool.m4: Define the 'no_undefined_flag' instead of
+   'allow_undefined_flag' when AIX runtime linking is active, to
+   actually let the -no-undefined switch have any effect in this case.
+
 2011-04-10  Kurt Roeckx  k...@roeckx.be
 
tagdemo: do not rely on picking up symbols from indirect deps.
diff --git a/libltdl/m4/libtool.m4 b/libltdl/m4/libtool.m4
--- a/libltdl/m4/libtool.m4
+++ b/libltdl/m4/libtool.m4
@@ -5060,7 +5060,7 @@ _LT_EOF
   if test $aix_use_runtimelinking = yes; then
# Warning - without using the other runtime loading flags (-brtl),
# -berok will link without error, but may produce a broken library.
-   _LT_TAGVAR(allow_undefined_flag, $1)='-berok'
+   _LT_TAGVAR(no_undefined_flag, $1)='-bernotok'
 # Determine the default libpath from the value encoded in an
 # empty executable.
 _LT_SYS_MODULE_PATH_AIX([$1])
@@ -6058,7 +6058,7 @@ if test $_lt_caught_CXX_error != yes; then
 if test $aix_use_runtimelinking = yes; then
   # Warning - without using the other runtime loading flags (-brtl),
   # -berok will link without error, but may produce a broken library.
-  _LT_TAGVAR(allow_undefined_flag, $1)='-berok'
+  _LT_TAGVAR(no_undefined_flag, $1)='-bernotok'
   # Determine the default libpath from the value encoded in an empty
   # executable.
   _LT_SYS_MODULE_PATH_AIX([$1])


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

2011-06-28 Thread Michael Haubenwallner


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 with \$concat_cmds to $concat_cmdsdump for within the eval.

 How can that be?
 
 +Correctly concat commands when export_symbols_cmds starts with 'word'.
 +* libltdl/config/ltmain.m4sh: When export_symbols_cmd starts with some
 +'word', 'word' is joined with 'concat_cmds' to 'concat_cmdsword' due to
 +different expansion time: Need to embrace concat_cmds variable for
 +export_symbols_cmds too as for reload_cmds and old_archive_cmds.
 
 When $concat_cmds is nonempty, it gets a '~' at the end.  That can never
 be part of a shell word, if I see correctly.  Can you give an example?

The content of $concat_cmds is irrelevant due to its later expansion time
compared to $export_symbols_cmds (actually, $concat_cmds is empty):


Sample 1 (with current value): export_symbols_cmds='$NM ...'

Step 0: eval concat_cmds=\\$concat_cmds$export_symbols_cmds\  # the original 
line
Step 1: eval 'concat_cmds=$concat_cmds$NM ...'# concat_cmds not expanded yet
Step 2: concat_cmds=$concat_cmds$NM ... # concat_cmds is expanded now
Step 3: concat_cmds=nm ...


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: concat_cmds=$concat_cmdsdump ...# there is no $concat_cmdsdump
Step 3: concat_cmds=


Sample 3 (with patch): export_symbols_cmds='dump ...'

Step 0: eval concat_cmds=\\${concat_cmds}$export_symbols_cmds\  # the fixed 
line
Step 1: eval 'concat_cmds=${concat_cmds}dump ...'  # concat_cmds not expanded 
yet
Step 2: concat_cmds=${concat_cmds}dump ...   # concat_cmds is expanded now
Step 3: concat_cmds=dump ...

 @@ -7636,7 +7636,7 @@ EOF
 -  eval concat_cmds=\\$concat_cmds$export_symbols_cmds\
 +  eval concat_cmds=\\${concat_cmds}$export_symbols_cmds\

Thank you!
/haubi/



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

2011-06-28 Thread Michael Haubenwallner

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: concat_cmds=$concat_cmdsdump ...# there is no 
 $concat_cmdsdump
 Step 3: concat_cmds=

Err, this should read:

Step 3: concat_cmds=...   # 'dump' was lost

/haubi/



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

2011-06-27 Thread Michael Haubenwallner
Hello!

Concatening commands breaks when export_symbols_cmds starts with something
like dump, which does not need another shell expansion step. Instead, it
is merged with \$concat_cmds to $concat_cmdsdump for within the eval.

While this isn't a problem right now, it hits me when experimenting 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 export_symbols_cmds starts with 'word'.
+   * libltdl/config/ltmain.m4sh: When export_symbols_cmd starts with some
+   'word', 'word' is joined with 'concat_cmds' to 'concat_cmdsword' due to
+   different expansion time: Need to embrace concat_cmds variable for
+   export_symbols_cmds too as for reload_cmds and old_archive_cmds.
+
 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..53355c4 100644
--- a/libltdl/config/ltmain.m4sh
+++ b/libltdl/config/ltmain.m4sh
@@ -7636,7 +7636,7 @@ EOF
  libobjs=$output
  # Append the command to create the export file.
  test -z $concat_cmds || concat_cmds=$concat_cmds~
- eval concat_cmds=\\$concat_cmds$export_symbols_cmds\
+ eval concat_cmds=\\${concat_cmds}$export_symbols_cmds\
  if test -n $last_robj; then
eval concat_cmds=\\$concat_cmds~\$RM $last_robj\
  fi




Re: DESTDIR install on hppa-hpux #4

2009-07-02 Thread Michael Haubenwallner
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. This patch here was the
last one tested there.

  * Michael Haubenwallner wrote on Mon, Jun 29, 2009 at 11:22:31AM CEST:
   
   Ok, here's the third way of supporting DESTDIR on hppa-hpux, now without
   the +cdp linker flag (#2), but using the absolute target libdir in the
   'internal name' instead, to fix the security issue of #1.
  
  Using absolute paths seems like a step backward, with all the world
  wanting relocatable packages more than anything.  I don't think we
  should go that way unless we cannot help it at all.  But maybe I have
  misunderstood you latest approach?
 
 Do you mean subsequent linked binaries should not contain the location
 the dependent shared library was originally targetted for?
 Well, I can agree here. Patch#2 with the +cdp mess would avoid that.

For completion: The +cdp mess means that for each required local
shared library the linkline gets bloated by
  +cdp $inst_prefix_dir$install_libdir/$soname:$install_libdir/$soname

Here's the fourth try:
The uninstalled shared libraries get absolute $install_libdir/$soname
into the internal name, to be able to create the local executables for
fast_install, without any embedded $builddir or $inst_prefix_dir, and
without the +cdp mess.
But this needs to force each local shared library - even those without
local dependencies - to be relinked for installation. Relinking is done
with $soname only as internal name, requiring +cdp $inst_prefix_dir:
only once to avoid inst_prefix_dir in the fallback path.

The runpath is again hardcoded into shared libraries too.

IMHO the basic problem here is that for binaries there is nothing known
like $install_bindir, similar to $install_libdir for libraries.

Same 12 tests change from SKIP/XFAIL to PASS as before, without any
other test result change.

 Another question:
 HP-UX does support SHLIB_PATH for 32bit hppa, and both LD_LIBRARY_PATH
 and SHLIB_PATH for hppa64 and ia64 (32/64), which can be enabled easily.

This would require the +s linker flag for executables too, but I haven't
found a way to do this. Thoughts?

Thanks!

/haubi/
diff --git a/libltdl/m4/libtool.m4 b/libltdl/m4/libtool.m4
index 1fe09d2..1727070 100644
--- a/libltdl/m4/libtool.m4
+++ b/libltdl/m4/libtool.m4
@@ -2332,6 +2332,10 @@ hpux9* | hpux10* | hpux11*)
 shlibpath_overrides_runpath=no # +s is required to enable SHLIB_PATH
 library_names_spec='${libname}${release}${shared_ext}$versuffix ${libname}${release}${shared_ext}$major $libname${shared_ext}'
 soname_spec='${libname}${release}${shared_ext}$major'
+case $host_os in
+hpux9*) ;;
+*) hardcode_into_libs=yes ;;
+esac
 ;;
   esac
   # HP-UX runs *really* slowly unless shared libraries are mode 555, ...
@@ -4760,25 +4764,59 @@ _LT_EOF
   ;;
 
 hpux10*)
+  # gcc-3.0.1 does some post-link processing which breaks when the
+  # just created binary has a nonexistent 'dynamic dependency'.
+  AC_CACHE_CHECK([whether absolute path of internal name works with $CC],
+	[_LT_TAGVAR(lt_cv_cdp_works, $1)],
+	[_LT_TAGVAR(lt_cv_cdp_works, $1)=:
+	if test $GCC = yes; then
+	  save_LDFLAGS=$LDFLAGS
+	  LDFLAGS=$LDFLAGS -Wl,+cdp -Wl,/usr/lib:/nonexistent -Wl,+cdp -Wl,/lib:/nonexistent
+	  AC_LINK_IFELSE([AC_LANG_PROGRAM([],[])],
+	[], [_LT_TAGVAR(lt_cv_cdp_works, $1)=false])
+	  LDFLAGS=$save_LDFLAGS
+	fi
+  ])
   if test $GCC = yes  test $with_gnu_ld = no; then
-	_LT_TAGVAR(archive_cmds, $1)='$CC -shared -fPIC ${wl}+h ${wl}$soname ${wl}+b ${wl}$install_libdir -o $lib $libobjs $deplibs $compiler_flags'
+	$_LT_TAGVAR(lt_cv_cdp_works, $1) 
+	_LT_TAGVAR(archive_cmds, $1)='$CC -shared -fPIC`test $mode = relink  func_echo_all  ${wl}+cdp ${wl}$inst_prefix_dir: ${wl}+h ${wl} || func_echo_all  ${wl}+h ${wl}$install_libdir/`$soname -o $lib $libobjs $deplibs $compiler_flags~need_relink=yes' ||
+	_LT_TAGVAR(archive_cmds, $1)='$CC -shared -fPIC ${wl}+h ${wl}$soname -o $lib $libobjs $deplibs $compiler_flags'
   else
-	_LT_TAGVAR(archive_cmds, $1)='$LD -b +h $soname +b $install_libdir -o $lib $libobjs $deplibs $linker_flags'
+	$_LT_TAGVAR(lt_cv_cdp_works, $1) 
+	_LT_TAGVAR(archive_cmds, $1)='$LD -b`test $mode = relink  func_echo_all  +cdp $inst_prefix_dir: +h  || func_echo_all  +h $install_libdir/`$soname -o $lib $libobjs $deplibs $linker_flags~need_relink=yes' ||
+	_LT_TAGVAR(archive_cmds, $1)='$LD -b +h $soname -o $lib $libobjs $deplibs $linker_flags'
+	_LT_TAGVAR(hardcode_libdir_flag_spec_ld, $1)='+b $libdir'
   fi
   if test $with_gnu_ld = no; then
 	_LT_TAGVAR(hardcode_libdir_flag_spec, $1)='${wl}+b ${wl}$libdir'
-	_LT_TAGVAR(hardcode_libdir_flag_spec_ld, $1)='+b $libdir'
 	_LT_TAGVAR(hardcode_libdir_separator, $1)=:
 	_LT_TAGVAR

Re: DESTDIR install on hppa-hpux #3

2009-07-01 Thread Michael Haubenwallner
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 wrote on Mon, Jun 29, 2009 at 11:22:31AM CEST:
  
  Ok, here's the third way of supporting DESTDIR on hppa-hpux, now without
  the +cdp linker flag (#2), but using the absolute target libdir in the
  'internal name' instead, to fix the security issue of #1.
 
 Using absolute paths seems like a step backward, with all the world
 wanting relocatable packages more than anything.  I don't think we
 should go that way unless we cannot help it at all.  But maybe I have
 misunderstood you latest approach?

Do you mean subsequent linked binaries should not contain the location
the dependent shared library was originally targetted for?
Well, I can agree here. Patch#2 with the +cdp mess would avoid that.

But another try: It should work to *link* the shared libraries *with*
the absolute internal name, so in-package executables get this as
fallback path without the +cdp mess, and to *relink* the shared
libraries *without* the absolute internal name, but using the +cdp
linker flag once to drop the $inst_prefix_dir.

Another question:
HP-UX does support SHLIB_PATH for 32bit hppa, and both LD_LIBRARY_PATH
and SHLIB_PATH for hppa64 and ia64 (32/64), which can be enabled easily.

Is it preferred to use the runpath from an environment variable?

Thanks!

/haubi/





Re: DESTDIR install on hppa-hpux #3

2009-06-29 Thread Michael Haubenwallner
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 the 'internal name' of a shared
 library does contain an absolute path instead of just a filename (or
 relative path), this absolute path is recorded as-is in the 'shared
 library list' as the fallback path into subsequent binaries.
 
 I'm playing around with +h $install_libdir/$soname, to come up with
 another patch to avoid the +cdp thing, which is a mess regarding cmdline
 length.

Ok, here's the third way of supporting DESTDIR on hppa-hpux, now without
the +cdp linker flag (#2), but using the absolute target libdir in the
'internal name' instead, to fix the security issue of #1.

Fix DESTDIR install for hpux10 and hppa-hpux11 (32bit).
* libltdl/m4/libtool.m4: Set hardcode_into_libs=yes, to allow
for dlopening local uninstalled shared libraries even when they
have the final target location encoded as fallback for dependant
local shared libraries. Do not explicitly set runpath (+b linker
flag) in archive_cmds, as this would defeat
hardcode_into_libs=yes. Set hardcode_libdir_flag_spec_ld only
when archive_cmds contains $LD, to get hardcode_into_libs
working.
Add check if gcc does work with nonexistent fallback locations
for dependant shared libraries. If yes, prepend shared library's
'internal name' with $install_libdir/ to have the final target
location stored into subsequent binaries as fallback instead of
the linktime location. Also set hardcode_minus_L=no in this
case, as it is not hardcoded when 'internal name' contains an
absolute path.
* tests/demo-hardcode.test: Try 'chatr' to read hardcoded paths,
to detect 'static'-type dependant shared libraries, and to avoid
false positives due to cc/aCC storing the cmdline into object
files.

Do you think the change to use absolute path in 'internal name' should
be explicitly mentioned in doc/notes.texi?

This patch does have the same effect on test-results as before: 12 tests
changing from SKIP/XFAIL to PASS on hppa-hpux1[01] 32bit, no result
change for other tests/platforms.

Thank you!

/haubi/
diff --git a/libltdl/m4/libtool.m4 b/libltdl/m4/libtool.m4
index 1fe09d2..dba121e 100644
--- a/libltdl/m4/libtool.m4
+++ b/libltdl/m4/libtool.m4
@@ -2332,6 +2332,10 @@ hpux9* | hpux10* | hpux11*)
 shlibpath_overrides_runpath=no # +s is required to enable SHLIB_PATH
 library_names_spec='${libname}${release}${shared_ext}$versuffix ${libname}${release}${shared_ext}$major $libname${shared_ext}'
 soname_spec='${libname}${release}${shared_ext}$major'
+case $host_os in
+hpux9*) ;;
+*) hardcode_into_libs=yes ;;
+esac
 ;;
   esac
   # HP-UX runs *really* slowly unless shared libraries are mode 555, ...
@@ -4760,25 +4764,64 @@ _LT_EOF
   ;;
 
 hpux10*)
+  # gcc-3.0.1 does some post-link processing which breaks when the
+  # just created binary has a nonexistent 'dynamic dependency'.
+  AC_CACHE_CHECK([for absolute path of internal name with $CC],
+	[_LT_TAGVAR(lt_cv_abspath_internal_name, $1)],
+	[_LT_TAGVAR(lt_cv_abspath_internal_name, $1)=
+	if test $GCC = yes; then
+	  save_LDFLAGS=$LDFLAGS
+	  LDFLAGS=$LDFLAGS -Wl,+cdp -Wl,/usr/lib:/nonexistent -Wl,+cdp -Wl,/lib:/nonexistent
+	  AC_LINK_IFELSE([AC_LANG_PROGRAM([],[])],
+	[_LT_TAGVAR(lt_cv_abspath_internal_name, $1)='$install_libdir/'],
+	[_LT_TAGVAR(lt_cv_abspath_internal_name, $1)=])
+	  LDFLAGS=$save_LDFLAGS
+	else
+	  _LT_TAGVAR(lt_cv_abspath_internal_name, $1)='$install_libdir/'
+	fi
+  ])
   if test $GCC = yes  test $with_gnu_ld = no; then
-	_LT_TAGVAR(archive_cmds, $1)='$CC -shared -fPIC ${wl}+h ${wl}$soname ${wl}+b ${wl}$install_libdir -o $lib $libobjs $deplibs $compiler_flags'
+	_LT_TAGVAR(archive_cmds, $1)='$CC -shared -fPIC ${wl}+h ${wl}'[$]_LT_TAGVAR(lt_cv_abspath_internal_name, $1)'$soname -o $lib $libobjs $deplibs $compiler_flags'
   else
-	_LT_TAGVAR(archive_cmds, $1)='$LD -b +h $soname +b $install_libdir -o $lib $libobjs $deplibs $linker_flags'
+	_LT_TAGVAR(archive_cmds, $1)='$LD -b +h '[$]_LT_TAGVAR(lt_cv_abspath_internal_name, $1)'$soname -o $lib $libobjs $deplibs $linker_flags'
+	_LT_TAGVAR(hardcode_libdir_flag_spec_ld, $1)='+b $libdir'
   fi
   if test $with_gnu_ld = no; then
 	_LT_TAGVAR(hardcode_libdir_flag_spec, $1)='${wl}+b ${wl}$libdir'
-	_LT_TAGVAR(hardcode_libdir_flag_spec_ld, $1)='+b $libdir'
 	_LT_TAGVAR(hardcode_libdir_separator, $1)=:
 	_LT_TAGVAR(hardcode_direct, $1)=yes
 	_LT_TAGVAR(hardcode_direct_absolute, $1)=yes
 	_LT_TAGVAR(export_dynamic_flag_spec, $1)='${wl}-E'
 	# hardcode_minus_L: Not really in the search PATH,
-	# but as the default location of the library

Re: DESTDIR install on hppa-hpux

2009-06-19 Thread Michael Haubenwallner
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 flag, which allows for changing the linktime
 path of a library into something different being stored as fallback path
 into the binary. It does even work on hpux10.20 (ld B.10.37 here)
 although not mentioned in its manpage.

Here's a patch that uses the +cdp linker flag to close the security
issue with the fallback path encoded into the SOM binaries, by adding
another libtool property 'fix_hardcoded_libdir_flag_spec', only used for
hppa-hpux (32bit). It is configure-checked if compiler/linker do support
this flag.

This allows for hardcode_action=immediate and fast_install=yes, required
for DESTDIR support.

tests/deplibs-ident.at has to filter this flag, as it would lead to
false positives.

The same 12 tests as before are turned from SKIP/XFAIL to PASS on all
the setups as before, with one exception: It is collect2 of gcc-3.0.1 on
hppa-hpux10 here, which erroneously interprets -Wl,+cdp and fails to
find libraries. So no tests do change their result in this setup.

Thank you!

/haubi/
diff --git a/libltdl/config/ltmain.m4sh b/libltdl/config/ltmain.m4sh
index 6f44d35..f7d098d 100644
--- a/libltdl/config/ltmain.m4sh
+++ b/libltdl/config/ltmain.m4sh
@@ -3801,6 +3801,8 @@ func_mode_link ()
 lib_search_path=`pwd`
 inst_prefix_dir=
 new_inherited_linker_flags=
+fix_hardcoded_libdir_flag=
+fix_hardcoded_libdir_flag_ld=
 
 avoid_version=no
 dlfiles=
@@ -5436,6 +5438,15 @@ func_mode_link ()
 	  elif test $hardcode_shlibpath_var = no; then
 		add_shlibpath=$dir
 		add=-l$name
+	  elif test -n $fix_hardcoded_libdir_flag_spec; then
+		add_dir=-L${absdir}
+		add=-l$name
+		if test ${linkmode} = prog  test X${absdir} != X${libdir}; then
+		  linkdir=$absdir
+		  eval fix_hardcoded_libdir_flag=\\${fix_hardcoded_libdir_flag} ${fix_hardcoded_libdir_flag_spec}\
+		  # fix_hardcoded_libdir_flag_ld not needed, programs are linked with $CC
+		  $lt_unset linkdir
+		fi
 	  else
 		lib_linked=no
 	  fi
@@ -5503,6 +5514,15 @@ func_mode_link ()
 	elif test $hardcode_minus_L = yes; then
 	  add_dir=-L$libdir
 	  add=-l$name
+	  if test -n $inst_prefix_dir 
+		 test -f $inst_prefix_dir$libdir/$linklib 
+		 test -n ${fix_hardcoded_libdir_flag_spec}; then
+		linkdir=$inst_prefix_dir$libdir
+		add_dir=-L$linkdir
+		eval fix_hardcoded_libdir_flag=\\${fix_hardcoded_libdir_flag} ${fix_hardcoded_libdir_flag_spec}\
+		eval fix_hardcoded_libdir_flag_ld=\\${fix_hardcoded_libdir_flag_ld} ${fix_hardcoded_libdir_flag_spec_ld}\
+		$lt_unset linkdir
+	  fi
 	elif test $hardcode_shlibpath_var = yes; then
 	  case :$finalize_shlibpath: in
 	  *:$libdir:*) ;;
diff --git a/libltdl/m4/libtool.m4 b/libltdl/m4/libtool.m4
index 5f24fab..9907f66 100644
--- a/libltdl/m4/libtool.m4
+++ b/libltdl/m4/libtool.m4
@@ -1905,6 +1905,7 @@ if test -n $_LT_TAGVAR(hardcode_libdir_flag_spec, $1) ||
  # have to relink, otherwise we might link with an installed library
  # when we should be linking with a yet-to-be-installed one
  ## test $_LT_TAGVAR(hardcode_shlibpath_var, $1) != no 
+ test -z $_LT_TAGVAR(fix_hardcoded_libdir_flag_spec, $1) 
  test $_LT_TAGVAR(hardcode_minus_L, $1) != no; then
 # Linking always hardcodes the temporary library directory.
 _LT_TAGVAR(hardcode_action, $1)=relink
@@ -4175,6 +4176,8 @@ m4_if([$1], [CXX], [
   _LT_TAGVAR(hardcode_libdir_separator, $1)=
   _LT_TAGVAR(hardcode_minus_L, $1)=no
   _LT_TAGVAR(hardcode_shlibpath_var, $1)=unsupported
+  _LT_TAGVAR(fix_hardcoded_libdir_flag_spec, $1)=
+  _LT_TAGVAR(fix_hardcoded_libdir_flag_spec_ld, $1)=
   _LT_TAGVAR(inherit_rpath, $1)=no
   _LT_TAGVAR(link_all_deplibs, $1)=unknown
   _LT_TAGVAR(module_cmds, $1)=
@@ -4758,13 +4761,12 @@ _LT_EOF
 
 hpux10*)
   if test $GCC = yes  test $with_gnu_ld = no; then
-	_LT_TAGVAR(archive_cmds, $1)='$CC -shared -fPIC ${wl}+h ${wl}$soname ${wl}+b ${wl}$install_libdir -o $lib $libobjs $deplibs $compiler_flags'
+	_LT_TAGVAR(archive_cmds, $1)='$CC -shared -fPIC ${wl}+h ${wl}$soname -o $lib $libobjs $deplibs $compiler_flags $fix_hardcoded_libdir_flag'
   else
-	_LT_TAGVAR(archive_cmds, $1)='$LD -b +h $soname +b $install_libdir -o $lib $libobjs $deplibs $linker_flags'
+	_LT_TAGVAR(archive_cmds, $1)='$LD -b +h $soname -o $lib $libobjs $deplibs $linker_flags $fix_hardcoded_libdir_flag_ld'
   fi
   if test $with_gnu_ld = no; then
-	_LT_TAGVAR(hardcode_libdir_flag_spec, $1)='${wl}+b ${wl}$libdir'
-	_LT_TAGVAR(hardcode_libdir_flag_spec_ld, $1)='+b $libdir'
+	_LT_TAGVAR(hardcode_libdir_flag_spec, $1)='${wl}+b ${wl}$libdir $fix_hardcoded_libdir_flag'
 	_LT_TAGVAR(hardcode_libdir_separator, $1)=:
 	_LT_TAGVAR(hardcode_direct, $1)=yes
 	_LT_TAGVAR

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

2009-06-18 Thread Michael Haubenwallner
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 b/tests/deplibs-ident.at
index 5758311..8a7d438 100644
--- a/tests/deplibs-ident.at
+++ b/tests/deplibs-ident.at
@@ -67,6 +67,7 @@ int main() { return a1() + a2() + a3() + c(); }
 	   [0],[stdout],[ignore])
   AT_CHECK([$EGREP 'cee.*cee' stdout], 1, [ignore], [ignore])
   AT_XFAIL_IF([case $host in
+ hppa64*-*-hpux*):;;
  *-*-aix*|hppa*-*-hpux*|*-*-interix*|*-*-openbsd*) false;;
  *):;;
esac])


Re: DESTDIR install on hppa-hpux

2009-06-15 Thread Michael Haubenwallner
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 = no; then
  -   _LT_TAGVAR(archive_cmds, $1)='$CC -shared -fPIC ${wl}+h ${wl}$soname 
  ${wl}+b ${wl}$install_libdir -o $lib $libobjs $deplibs $compiler_flags'
  +   _LT_TAGVAR(archive_cmds, $1)='$CC -shared -fPIC ${wl}+h ${wl}$soname -o 
  $lib $libobjs $deplibs $compiler_flags'
 else
  -   _LT_TAGVAR(archive_cmds, $1)='$LD -b +h $soname +b $install_libdir -o 
  $lib $libobjs $deplibs $linker_flags'
  +   _LT_TAGVAR(archive_cmds, $1)='$LD -b +h $soname -o $lib $libobjs 
  $deplibs $linker_flags'
  +   _LT_TAGVAR(hardcode_libdir_flag_spec_ld, $1)='+b $libdir'
 fi
 if test $with_gnu_ld = no; then
  _LT_TAGVAR(hardcode_libdir_flag_spec, $1)='${wl}+b ${wl}$libdir'
  -   _LT_TAGVAR(hardcode_libdir_flag_spec_ld, $1)='+b $libdir'
 
 ... this removed line ...

... this is 'hpux10*', ...

 
  _LT_TAGVAR(hardcode_libdir_separator, $1)=:
 
  @@ -4757,9 +4760,9 @@ _LT_EOF
# (HP92453-01 A.11.01.20 doesn't, HP92453-01 B.11.X.35175-35176.GP 
  does)
_LT_LINKER_OPTION([if $CC understands -b],
  _LT_TAGVAR(lt_cv_prog_compiler__b, $1), [-b],
  -   [_LT_TAGVAR(archive_cmds, $1)='$CC -b ${wl}+h ${wl}$soname ${wl}+b 
  ${wl}$install_libdir -o $lib $libobjs $deplibs $compiler_flags'],
  -   [_LT_TAGVAR(archive_cmds, $1)='$LD -b +h $soname +b $install_libdir 
  -o $lib $libobjs $deplibs $linker_flags'])],
  - [_LT_TAGVAR(archive_cmds, $1)='$CC -b ${wl}+h ${wl}$soname ${wl}+b 
  ${wl}$install_libdir -o $lib $libobjs $deplibs $compiler_flags'])
  +   [_LT_TAGVAR(archive_cmds, $1)='$CC -b ${wl}+h ${wl}$soname -o $lib 
  $libobjs $deplibs $compiler_flags'],
  +   [_LT_TAGVAR(archive_cmds, $1)='$LD -b +h $soname -o $lib $libobjs 
  $deplibs $linker_flags'])],
 
 ... is also used for this older 11.00 compiler version (which you
 probably don't have on your systems).

... while this is 'hpux11*', so how can this happen?

Anyway, maybe the usage of $hardcode_libdir_flag_spec_ld in ltmain.m4sh
is problematic instead, as it is unconditionally used if set, even when
$CC (but not $LD) is in $archive_cmds:

6652 if test -n $hardcode_libdir_flag_spec_ld; then
6653   eval dep_rpath=\$hardcode_libdir_flag_spec_ld\
6654 else
6655   eval dep_rpath=\$hardcode_libdir_flag_spec\
6656 fi

$CC might not understand +b directly, which was why I moved setting
hardcode_libdir_flag_spec_ld up to where archive_cmds is set to '$LD',
to not have it set when archive_cmds is '$CC'.

Thanks!

/haubi/





Re: DESTDIR install on hppa-hpux

2009-06-12 Thread Michael Haubenwallner
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', as the encoded library path is used as
fallback location for a specific library when runpath lookup fails.
As this isn't really 'hardcoding' in libtool's sense, hardcode_minus_L
can safely be set to 'no' IMO, opening the door for DESTDIR support.
   
   Hmm.  This does open a small security issue, no?  Imagine the following
   setup: user joe compiles some package, then uses 'sudo make install' to
   install it in a system location.  First issue: the path to the
   compilation location is revealed in the installed libraries and programs
   which have dependencies to newly-installed libraries.  Second, if those
   deplibs are removed for whatever reason, then the runtime linker will
   search in joe's build tree for the shared libraries.  This may not be
   likely to happen, but it's something to think about.
  
  I've thought about this too, but how would the link command have to look
  like to avoid this issue?
 
 I don't know.  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 flag, which allows for changing the linktime
path of a library into something different being stored as fallback path
into the binary. It does even work on hpux10.20 (ld B.10.37 here)
although not mentioned in its manpage.

It should be enough to simply add +cdp ${inst_prefix_dir}: to each
relink line, to replace ${inst_prefix_dir} with .
But I still have to look how to integrate this into libtool - any help
appreciated.

Thanks!

/haubi/





Re: DESTDIR install on hppa-hpux

2009-06-05 Thread Michael Haubenwallner
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', as the encoded library path is used as
fallback location for a specific library when runpath lookup fails.
As this isn't really 'hardcoding' in libtool's sense, hardcode_minus_L
can safely be set to 'no' IMO, opening the door for DESTDIR support.
   
   Hmm.  This does open a small security issue, no?  Imagine the following
   setup: user joe compiles some package, then uses 'sudo make install' to
   install it in a system location.  First issue: the path to the
   compilation location is revealed in the installed libraries and programs
   which have dependencies to newly-installed libraries.  Second, if those
   deplibs are removed for whatever reason, then the runtime linker will
   search in joe's build tree for the shared libraries.  This may not be
   likely to happen, but it's something to think about.
  
  I've thought about this too, but how would the link command have to look
  like to avoid this issue?
 
 I don't know.  That's precisely the reason we haven't gone this way
 before.

Ah, I see.
Hmm, I'll have to keep a patch myself then, as using DESTDIR is a
blocker here...

So the 'chatr' hunk in the test also must not ignore the fallback path
then. But it still helps for cc/aCC, as they both encode the commandline
into each object file leading to false positives otherways.

Another minor one was that there is no need to pass
+b $install_libdir, as the linker ignores subsequent +b values.
   
   Erm, libtool has code to merge multiple run path values (and to let
   ltmain know that this needs to be done).  Weren't semantics on HP-UX
   that way that, if +b was not used, then the linked path with -L is
   searched too?  That would be bad then.
  
  This is done anyway using $hardcode_libdir_flag_spec.
  Leaving +b $install_libdir in $archive_cmds would ignore the
  subsequent collected +b $libdir.
 
 Oh.  So I guess this would be an independent fix anyway?

Hmm, could be indeed.

The 'chatr' part definitively is independent too, although with above
mentioned change.

Thanks!

/haubi/





Re: DESTDIR install on hppa-hpux

2009-06-04 Thread Michael Haubenwallner
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 environments marked with * below.
  No other tests do change their result.

  The most important part of the fix is already suggested in comments
  around 'hardcode_minus_L=yes', as the encoded library path is used as
  fallback location for a specific library when runpath lookup fails.
  As this isn't really 'hardcoding' in libtool's sense, hardcode_minus_L
  can safely be set to 'no' IMO, opening the door for DESTDIR support.
 
 Hmm.  This does open a small security issue, no?  Imagine the following
 setup: user joe compiles some package, then uses 'sudo make install' to
 install it in a system location.  First issue: the path to the
 compilation location is revealed in the installed libraries and programs
 which have dependencies to newly-installed libraries.  Second, if those
 deplibs are removed for whatever reason, then the runtime linker will
 search in joe's build tree for the shared libraries.  This may not be
 likely to happen, but it's something to think about.

I've thought about this too, but how would the link command have to look
like to avoid this issue?

  This does require to use 'chatr' in demo-hardcode.test to not get false
  positives when testing for hardcoded path (more comments inside).
 
 That seems like an acceptable compromise.
 
  Another minor one was that there is no need to pass
  +b $install_libdir, as the linker ignores subsequent +b values.
 
 Erm, libtool has code to merge multiple run path values (and to let
 ltmain know that this needs to be done).  Weren't semantics on HP-UX
 that way that, if +b was not used, then the linked path with -L is
 searched too?  That would be bad then.

This is done anyway using $hardcode_libdir_flag_spec.
Leaving +b $install_libdir in $archive_cmds would ignore the
subsequent collected +b $libdir.

 
  The patch has been tested in these HP-UX environments (as well as on
  linux and aix, without any test result changes there):
  
  arch  HP-UX bits * compiler
  --

 
 What does this table mean?  That for each of the combinations, the
 libtool testsuite was run,

Exactly.

  and there were no failures?

Well, there weren't _no_ failures, but the same failures compared to
vanilla git/master, except for the 12 tests changing from SKIP or XFAIL
to PASS (see above).

Thank you!

/haubi/





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

2009-05-29 Thread Michael Haubenwallner
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 does not use it to search for libraries at all, which causes
hc-libpath creation to fail in this test, while libtool expects it to
succeed (without hardcoding) when set to 'no'.

The patch attached here does tests/demo-hardcode.test change from FAIL
to PASS for *64-hpux with gcc, and when it does have the patch to use
'chatr' too, it also PASSes with cc/aCC.

Eventually, my previous patch for hppa-hpux DESTDIR could be split into
two separate ones, one for demo-hardcode.test and one for libtool.m4.

Thanks!

/haubi/
diff --git a/libltdl/m4/libtool.m4 b/libltdl/m4/libtool.m4
index df64654..100d988 100644
--- a/libltdl/m4/libtool.m4
+++ b/libltdl/m4/libtool.m4
@@ -4773,7 +4773,6 @@ _LT_EOF
 	case $host_cpu in
 	hppa*64*|ia64*)
 	  _LT_TAGVAR(hardcode_direct, $1)=no
-	  _LT_TAGVAR(hardcode_shlibpath_var, $1)=no
 	  ;;
 	*)
 	  _LT_TAGVAR(hardcode_direct, $1)=yes
@@ -5712,7 +5711,6 @@ if test $_lt_caught_CXX_error != yes; then
 case $host_cpu in
   hppa*64*|ia64*)
 _LT_TAGVAR(hardcode_direct, $1)=no
-_LT_TAGVAR(hardcode_shlibpath_var, $1)=no
 ;;
   *)
 _LT_TAGVAR(hardcode_direct, $1)=yes


DESTDIR install on hppa-hpux

2009-05-26 Thread Michael Haubenwallner
Hi,

now I've managed to get 'make install DESTDIR=...' working on
hppa-hpux10 and hppa-hpux11 with libtool.

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 environments marked with * below.
No other tests do change their result.

The most important part of the fix is already suggested in comments
around 'hardcode_minus_L=yes', as the encoded library path is used as
fallback location for a specific library when runpath lookup fails.
As this isn't really 'hardcoding' in libtool's sense, hardcode_minus_L
can safely be set to 'no' IMO, opening the door for DESTDIR support.

This does require to use 'chatr' in demo-hardcode.test to not get false
positives when testing for hardcoded path (more comments inside).

Another minor one was that there is no need to pass
+b $install_libdir, as the linker ignores subsequent +b values.

The patch has been tested in these HP-UX environments (as well as on
linux and aix, without any test result changes there):

arch  HP-UX bits * compiler
--
hppa  10.20  32  * gcc-3.0.1
hppa  10.20  32  * HP C Compiler A.10.32.30 (with CXX=false)

hppa  11.11  32  * gcc-3.3.4
hppa  11.11  32  * HP C Compiler PHCO_27774 + HP ANSI C++ A.03.52
hppa  11.11  64HP C Compiler PHCO_27774 + HP ANSI C++ A.03.52

ia64  11.23  32gcc-4.2.4
ia64  11.23  32HP aC++/ANSI C A.06.10 (both cc/aCC)
ia64  11.23  64gcc-4.2.4
ia64  11.23  64HP aC++/ANSI C A.06.10 (both cc/aCC

hppa  11.31  32  * gcc-4.3.1
hppa  11.31  32  * HP C Compiler PHCO_27774 + HP ANSI C++ A.03.85
hppa  11.31  64HP C Compiler PHCO_27774 + HP ANSI C++ A.03.85


The patch is created and tested using recent libtool.master - I'm just
unsure about the ChangeLog heading (already inside).

Setting 'hardcode_minus_L=no' can be dropped eventually, as it is the
default and a similar comment is in demo-hardcode.test now.

Thanks!

/haubi/
diff --git a/ChangeLog b/ChangeLog
index 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 to 'no', as the stored path only is used as
+	fallback when the library is not found via runpath.
+	Do not set runpath with +b $install_libdir, as this would ignore the
+	collected runpath subsequently set with +b $libdir.
+	Set hardcode_libdir_flag_spec_ld along direct use of $LD only (hpux10).
+	* tests/demo-hardcode.test: Try 'chatr' to read hardcoded paths, to allow
+	for filtering out library paths being used as fallback.
+
 2009-05-05  Rainer Emrich  r.emr...@de.tecosim.com  (tiny change)
 	Peter Rosin  p...@lysator.liu.se
 	Ralf Wildenhues  ralf.wildenh...@gmx.de
diff --git a/libltdl/m4/libtool.m4 b/libltdl/m4/libtool.m4
index 8af17a8..df64654 100644
--- a/libltdl/m4/libtool.m4
+++ b/libltdl/m4/libtool.m4
@@ -2316,6 +2316,9 @@ hpux9* | hpux10* | hpux11*)
 ;;
   *)
 shrext_cmds='.sl'
+case $host_os in hpux9*) ;;
+*) hardcode_into_libs=yes ;;
+esac
 dynamic_linker=$host_os dld.sl
 shlibpath_var=SHLIB_PATH
 shlibpath_overrides_runpath=no # +s is required to enable SHLIB_PATH
@@ -4713,20 +4716,20 @@ _LT_EOF
 
 hpux10*)
   if test $GCC = yes  test $with_gnu_ld = no; then
-	_LT_TAGVAR(archive_cmds, $1)='$CC -shared -fPIC ${wl}+h ${wl}$soname ${wl}+b ${wl}$install_libdir -o $lib $libobjs $deplibs $compiler_flags'
+	_LT_TAGVAR(archive_cmds, $1)='$CC -shared -fPIC ${wl}+h ${wl}$soname -o $lib $libobjs $deplibs $compiler_flags'
   else
-	_LT_TAGVAR(archive_cmds, $1)='$LD -b +h $soname +b $install_libdir -o $lib $libobjs $deplibs $linker_flags'
+	_LT_TAGVAR(archive_cmds, $1)='$LD -b +h $soname -o $lib $libobjs $deplibs $linker_flags'
+	_LT_TAGVAR(hardcode_libdir_flag_spec_ld, $1)='+b $libdir'
   fi
   if test $with_gnu_ld = no; then
 	_LT_TAGVAR(hardcode_libdir_flag_spec, $1)='${wl}+b ${wl}$libdir'
-	_LT_TAGVAR(hardcode_libdir_flag_spec_ld, $1)='+b $libdir'
 	_LT_TAGVAR(hardcode_libdir_separator, $1)=:
 	_LT_TAGVAR(hardcode_direct, $1)=yes
 	_LT_TAGVAR(hardcode_direct_absolute, $1)=yes
 	_LT_TAGVAR(export_dynamic_flag_spec, $1)='${wl}-E'
 	# hardcode_minus_L: Not really in the search PATH,
 	# but as the default location of the library.
-	_LT_TAGVAR(hardcode_minus_L, $1)=yes
+	_LT_TAGVAR(hardcode_minus_L, $1)=no
   fi
   ;;
 
@@ -4740,7 +4743,7 @@ _LT_EOF
 	  _LT_TAGVAR(archive_cmds, $1)='$CC -shared -fPIC ${wl}+h ${wl}$soname ${wl}+nodefaultrpath -o $lib $libobjs $deplibs $compiler_flags'
 	  ;;
 	*)
-	  _LT_TAGVAR(archive_cmds, $1)='$CC -shared -fPIC ${wl}+h ${wl}$soname ${wl}+b ${wl}$install_libdir -o $lib $libobjs $deplibs $compiler_flags'
+	  _LT_TAGVAR(archive_cmds, $1)='$CC -shared -fPIC ${wl}+h ${wl

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

2009-02-11 Thread Michael Haubenwallner
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)='${wl}-bstatic'
 + _LT_TAGVAR(lt_prog_compiler_shared_as_shared, 
 $1)='${wl}-bdynamic'

 Have extracted the parts to statically link against shared libraries on
 AIX, although I don't have an idea how to get better readability for the
 additional tests in ltmain.m4sh.
 
 This also applies to the test-cases, which really should utilize
 '-static' whenever possible.

Any update on this?

However, the same patch again, now including ChangeLog.

Thanks!

/haubi/
diff --git a/ChangeLog b/ChangeLog
index 5fe54d7..1616fe3 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,19 @@
+2009-02-11  Michael Haubenwallner michael.haubenwall...@salomon.at
+
+	AIX can link statically against shared libraries.
+	* doc/notes.texi: Add note that this is done when requested.
+	* libltdl/config/ltmain.m4sh: Listen to new link_shared_as_static_flag/
+	link_shared_as_shared_flag.
+	* libltdl/m4/libtool.m4: Introduce lt_prog_compiler_shared_as_static/
+	lt_prog_compiler_shared_as_shared settings, initialize on AIX and map
+	them to new link_shared_as_static_flag/link_shared_as_shared_flag.
+	* tests/demo/configure.ac: Use '-static' also when statically linking
+	against shared libraries is possible.
+	* tests/depdemo/configure.ac: Likewise.
+	* tests/mdemo/configure.ac: Likewise.
+	* tests/mdemo2/configure.ac: Likewise.
+	* tests/pdemo/configure.ac: Likewise.
+
 2009-02-03  Ralf Wildenhues  ralf.wildenh...@gmx.de
 	Kurt Roeckx k...@roeckx.be
 
diff --git a/doc/notes.texi b/doc/notes.texi
index 44b50d1..923c0f8 100644
--- a/doc/notes.texi
+++ b/doc/notes.texi
@@ -4,6 +4,13 @@
 You currently need GNU make to build the Libtool package itself.
 
 @item
+On AIX, everything is PIC, so there is no need to compile two separate objects
+for shared and static libraries. However, AIX can statically link against
+shared libraries (more specifically shared objects) using some linker flags.
+So libtool does not create the static library when shared-library-creation is
+active, but still links statically against the shared library when requested.
+
+...@item
 On AIX there are two different styles of shared linking, one in which symbols
 are bound at link-time and one in which symbols are bound at runtime only,
 similar to e...@.  In case of doubt use @code{LDFLAGS=-Wl,-brtl} for the latter style.
diff --git a/libltdl/config/ltmain.m4sh b/libltdl/config/ltmain.m4sh
index 49e07c3..f5ac92f 100644
--- a/libltdl/config/ltmain.m4sh
+++ b/libltdl/config/ltmain.m4sh
@@ -3850,8 +3850,10 @@ func_mode_link ()
 	  fi
 	  if test -n $link_static_flag; then
 	dlopen_self=$dlopen_self_static
+	prefer_static_libs=all
+	  else
+	prefer_static_libs=yes
 	  fi
-	  prefer_static_libs=yes
 	  ;;
 	-static)
 	  if test -z $pic_flag  test -n $link_static_flag; then
@@ -5475,7 +5477,17 @@ func_mode_link ()
 	fi
 	if test $linkmode = prog; then
 	  test -n $add_dir  compile_deplibs=$add_dir $compile_deplibs
+	  # AIX can link 'shared objects' statically:
+	  test $use_static_libs != no 
+		test $use_static_libs != all 
+		test -n $link_shared_as_static_flag 
+		eval compile_deplibs=\$link_shared_as_static_flag \$compile_deplibs\
 	  test -n $add  compile_deplibs=$add $compile_deplibs
+	  # switch back to link 'shared objects' dynamically:
+	  test $use_static_libs != no 
+		test $use_static_libs != all 
+		test -n $link_shared_as_shared_flag 
+		eval compile_deplibs=\$link_shared_as_shared_flag \$compile_deplibs\
 	else
 	  test -n $add_dir  deplibs=$add_dir $deplibs
 	  test -n $add  deplibs=$add $deplibs
@@ -5530,10 +5542,30 @@ func_mode_link ()
 
 	if test $linkmode = prog; then
 	  test -n $add_dir  finalize_deplibs=$add_dir $finalize_deplibs
+	  # AIX can link 'shared objects' statically:
+	  test $use_static_libs != no 
+		test $use_static_libs != all 
+		test -n $link_shared_as_static_flag 
+		eval finalize_deplibs=\$link_shared_as_static_flag \$finalize_deplibs\
 	  test -n $add  finalize_deplibs=$add $finalize_deplibs
+	  # switch back to link 'shared objects' dynamically:
+	  test $use_static_libs != no 
+		test $use_static_libs != all 
+		test -n $link_shared_as_shared_flag 
+		eval finalize_deplibs=\$link_shared_as_shared_flag \$finalize_deplibs\
 	else
 	  test -n $add_dir  deplibs=$add_dir $deplibs
+	  # AIX can link 'shared objects' statically:
+	  test $use_static_libs != no 
+		test $use_static_libs != all 
+		test -n $link_shared_as_static_flag 
+		eval deplibs=\$link_shared_as_static_flag \$deplibs\
 	  test -n $add  deplibs=$add $deplibs
+	  # switch back to link 'shared objects' dynamically:
+	  test $use_static_libs != no 
+		test

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

2008-12-18 Thread Michael Haubenwallner
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, 2008-12-08 at 08:10 +0100, Ralf Wildenhues wrote:
  
+   _LT_TAGVAR(lt_prog_compiler_shared_as_static, 
$1)='${wl}-bstatic'
+   _LT_TAGVAR(lt_prog_compiler_shared_as_shared, 
$1)='${wl}-bdynamic'
   
   What is the semantic difference between these switches and this proposal
   http://thread.gmane.org/gmane.comp.gnu.libtool.patches/6727/focus=6730?
   If the difference is too small, we should apply the other patch first
   and adjust your patch accordingly, no?
  
  Haven't seen this thread before. Agreed, it is related, but it depends
  on how the per-deplib-flags would interfere with -static-libtool-libs
  and -static, as - unlike other platforms - the '-bstatic' flag allows
  (and is necessary when not -static) to statically link a shared-only
  library.
 
 Yes, that is definitely different in semantics than what the above
 thread tries to achieve.
 
  So the search for a statically-linkable library would need to know that
  shared-only libraries can match too when '$shared_as_static' is set.
 
 Yep.

Have extracted the parts to statically link against shared libraries on
AIX, although I don't have an idea how to get better readability for the
additional tests in ltmain.m4sh.

This also applies to the test-cases, which really should utilize
'-static' whenever possible.

Thanks!

/haubi/
diff --git a/doc/notes.texi b/doc/notes.texi
index 44b50d1..a0357f2 100644
--- a/doc/notes.texi
+++ b/doc/notes.texi
@@ -4,6 +4,13 @@
 You currently need GNU make to build the Libtool package itself.
 
 @item
+On AIX, everything is PIC, so there is no need to compile two separate objects
+for shared and static libraries. However, AIX can statically link against
+shared libraries (more specifically shared objects) using some linker flags.
+So libtool does not create the static library when shared-library-creation is
+active, but still can link statically against the shared library when requested.
+
+...@item
 On AIX there are two different styles of shared linking, one in which symbols
 are bound at link-time and one in which symbols are bound at runtime only,
 similar to e...@.  In case of doubt use @code{LDFLAGS=-Wl,-brtl} for the latter style.
diff --git a/libltdl/config/ltmain.m4sh b/libltdl/config/ltmain.m4sh
index 2769149..2951b69 100644
--- a/libltdl/config/ltmain.m4sh
+++ b/libltdl/config/ltmain.m4sh
@@ -3853,8 +3853,10 @@ func_mode_link ()
 	  fi
 	  if test -n $link_static_flag; then
 	dlopen_self=$dlopen_self_static
+	prefer_static_libs=all
+	  else
+	prefer_static_libs=yes
 	  fi
-	  prefer_static_libs=yes
 	  ;;
 	-static)
 	  if test -z $pic_flag  test -n $link_static_flag; then
@@ -5478,7 +5480,17 @@ func_mode_link ()
 	fi
 	if test $linkmode = prog; then
 	  test -n $add_dir  compile_deplibs=$add_dir $compile_deplibs
+	  # AIX can link 'shared objects' statically:
+	  test $use_static_libs != no 
+		test $use_static_libs != all 
+		test -n $link_shared_as_static_flag 
+		eval compile_deplibs=\$link_shared_as_static_flag \$compile_deplibs\
 	  test -n $add  compile_deplibs=$add $compile_deplibs
+	  # switch back to link 'shared objects' dynamically:
+	  test $use_static_libs != no 
+		test $use_static_libs != all 
+		test -n $link_shared_as_shared_flag 
+		eval compile_deplibs=\$link_shared_as_shared_flag \$compile_deplibs\
 	else
 	  test -n $add_dir  deplibs=$add_dir $deplibs
 	  test -n $add  deplibs=$add $deplibs
@@ -5533,10 +5545,30 @@ func_mode_link ()
 
 	if test $linkmode = prog; then
 	  test -n $add_dir  finalize_deplibs=$add_dir $finalize_deplibs
+	  # AIX can link 'shared objects' statically:
+	  test $use_static_libs != no 
+		test $use_static_libs != all 
+		test -n $link_shared_as_static_flag 
+		eval finalize_deplibs=\$link_shared_as_static_flag \$finalize_deplibs\
 	  test -n $add  finalize_deplibs=$add $finalize_deplibs
+	  # switch back to link 'shared objects' dynamically:
+	  test $use_static_libs != no 
+		test $use_static_libs != all 
+		test -n $link_shared_as_shared_flag 
+		eval finalize_deplibs=\$link_shared_as_shared_flag \$finalize_deplibs\
 	else
 	  test -n $add_dir  deplibs=$add_dir $deplibs
+	  # AIX can link 'shared objects' statically:
+	  test $use_static_libs != no 
+		test $use_static_libs != all 
+		test -n $link_shared_as_static_flag 
+		eval deplibs=\$link_shared_as_static_flag \$deplibs\
 	  test -n $add  deplibs=$add $deplibs
+	  # switch back to link 'shared objects' dynamically:
+	  test $use_static_libs != no 
+		test $use_static_libs != all 
+		test -n $link_shared_as_shared_flag 
+		eval deplibs=\$link_shared_as_shared_flag

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

2008-04-21 Thread Michael Haubenwallner

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,
   the output is full of lines looking like:
   rm: cannot remove directory 
   `/nfsmount/libtool-2.2.2/tests/testsuite.dir/25/broken/lib': File exists
   
   Although it does not cause any additional test to fail, it's still ugly.
  
  Yep.
  
   This is because AIX keeps shared libraries in use for some time even if
   there are no more programs using it.
  
  Yep, I knew that.
  
   But this only applies to shared libraries having read (execute?)
   permission for 'other'.
  
  Ha!  I wasn't aware of that.  Thank you!
  
  I've confirmed on AIX 5.3 that read permissions are what counts, but it
  shouldn't hurt removing the others as well.
  
   So adding an 'umask 0007' (or 0077) early in testsuite.at can help here.
  
  I'd like to avoid giving more permissions if the user set, say, umask
  077 before.  Thus let's just remove those for others.  I've applied the
  patch below and put you in THANKS.
 
 Thank you!
 
  +case $host_os in
  +aix*) umask o-rwx ;;
 
 As I was not aware of symbolics with umask yet, and being paranoid, I've
 tried that: Unfortunately, it depends on the shell if umask with
 symbolics works: It works with bash as well as AIX' /bin/ksh, while it
 does not work with AIX' /bin/sh, but without any failure notice - it
 just sets umask to 0:
 
 $ /bin/sh
 sh$ umask
 0007
 sh$ umask o-rwx; umask
 
 sh$ umask 007; umask
 0007
 sh$ umask junk; umask
 
 sh$ 

Ohw, sorry - this works for AIX' (5.3) /bin/sh, I've accidentally tested
this on the Solaris box.

 
 So we want to use the numeric umask here...

So there's no need to use numeric umasks on AIX, sorry!

/haubi/