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

[Peter Rosin]

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

[copying my msg from the ML to the patch tracker]

I think these testsuite problems goes away if you configure with something
like ".../configure --build=i686-pc-cygwin --host=mingw32" as indicated in the
manual [1]. Or maybe it's x86_64-pc-cygwin in your case?

The rationale is that when Cygwin is used to drive a MSVC build, I have
considered it a Cygwin to MinGW cross, because that is much closer to the
truth than a native Cygwin build (which is what is assumed if you just
override CC).

But I haven't tested recently, YMMV...

Cheers,
Peter

[1]
https://www.gnu.org/software/libtool/manual/libtool.html#Cygwin-to-MinGW-Cross


___

Reply to this item at:

  

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

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

[Peter Rosin]

On 2017-05-10 16:24, Michael Haubenwallner wrote:
> 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

I think these testsuite problems goes away if you configure with something
like ".../configure --build=i686-pc-cygwin --host=mingw32" as indicated in
the manual [1]. Or maybe it's x86_64-pc-cygwin in your case?

The rationale is that when Cygwin is used to drive a MSVC build, I have
considered it a Cygwin to MinGW cross, because that is much closer to the
truth than a native Cygwin build (which is what is assumed if you just
override CC).

But I haven't tested recently, YMMV...

Cheers,
Peter

[1] 
https://www.gnu.org/software/libtool/manual/libtool.html#Cygwin-to-MinGW-Cross

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

[Peter Rosin]

On 2016-03-14 11:01, Michael Haubenwallner wrote:
> 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

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

[Peter Rosin]

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

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

Re: [PATCH 2/2] libtool: set file_list_spec to '@' on OS/2

[Peter Rosin]

Hi!

On 2016-02-22 12:21, Pavel Raiskup wrote:
> KO Myung-Hun, thanks for this patch but I need to see a bit deeper
> reasoning for this change as I do not understand the code properly.
> 
> As the $file_list_spec is used in libtool under special circumstances, can
> you describe what are the values of important variables (or could you post
> a full libtool output with shell debugging output)?
> 
> Maybe other committers can help with the review?

Stepping up to the plate...

The first hunk is for gnu ld on os2, and I believe '@' is correct there.

The second hunk is for the system linker on os2, whatever that is but I
would guess link.exe or something such. If that's true and this link.exe is
compatible with microsoft link.exe, '@' is also correct. Two big ifs though.
I'm not even sure if it is sensible to talk about a system linker on os2,
but it is not gnu ld (it would have been handled by the first hunk in that
case).

The third hunk is for everything C++, and maybe libtool only works for 
g++ anyway on os2? I don't know, but if that is the case, '@' is ok.

I don't know if anything but gnu tools ever worked with libtool on os2?

Cheers,
Peter

> On Wednesday 16 of December 2015 12:59:17 KO Myung-Hun wrote:
>> Creating and linking reloadable objects sometimes fail.
>>
>> * m4/libtool.m4 (_LT_LINKER_SHLIBS, _LT_LANG_CXX_CONFIG) :
>> Set file_list_spec to '@'.
>> ---
>>  m4/libtool.m4 | 3 +++
>>  1 file changed, 3 insertions(+)
>>
>> diff --git a/m4/libtool.m4 b/m4/libtool.m4
>> index 2e8c3cf..c01f8fb 100644
>> --- a/m4/libtool.m4
>> +++ b/m4/libtool.m4
>> @@ -5169,6 +5169,7 @@ _LT_EOF
>>  emximp -o $lib $output_objdir/$libname.def'
>>_LT_TAGVAR(old_archive_From_new_cmds, $1)='emximp -o 
>> $output_objdir/${libname}_dll.a $output_objdir/$libname.def'
>>_LT_TAGVAR(enable_shared_with_static_runtimes, $1)=yes
>> +  _LT_TAGVAR(file_list_spec, $1)='@'
>>;;
>>  
>>  interix[[3-9]]*)
>> @@ -5874,6 +5875,7 @@ _LT_EOF
>>  emximp -o $lib $output_objdir/$libname.def'
>>_LT_TAGVAR(old_archive_From_new_cmds, $1)='emximp -o 
>> $output_objdir/${libname}_dll.a $output_objdir/$libname.def'
>>_LT_TAGVAR(enable_shared_with_static_runtimes, $1)=yes
>> +  _LT_TAGVAR(file_list_spec, $1)='@'
>>;;
>>  
>>  osf3*)
>> @@ -6743,6 +6745,7 @@ if test yes != "$_lt_caught_CXX_error"; then
>>emximp -o $lib $output_objdir/$libname.def'
>>  _LT_TAGVAR(old_archive_From_new_cmds, $1)='emximp -o 
>> $output_objdir/${libname}_dll.a $output_objdir/$libname.def'
>>  _LT_TAGVAR(enable_shared_with_static_runtimes, $1)=yes
>> +_LT_TAGVAR(file_list_spec, $1)='@'
>>  ;;
>>  
>>dgux*)
>>
> 
> 

Re: [PATCH] Support MSYS2

[Peter Rosin]

On 2015-08-09 21:26, fabrizio...@tiscali.it wrote:
 The output of uname -o is indeed the same in MSYS2 and MinGW/MSYS
 
 Msys
 
 However, that is irrelevant because, config.guess does not use uname -o, it 
 does uname -s
 
 UNAME_SYSTEM=`(uname -s) 2/dev/null`  || UNAME_SYSTEM=unknown
 
 The output of uname -s is different between MSYS2 and the old MinGW/MSYS, and 
 that's the reason why config.guess (at least the latest versions of it) 
 returns something different between MSYS2 and the old MinGW/MSYS. So the 
 patch is ultimately necessary

But the problem is that msys 1.0 uses the envvar MSYSTEM to control
the output of uname -s, and traditionally it is set to msys when
building tools for msys 1.0, and to mingw in the normal end-user
use case where you want MSVCRT instead of the msys C library.

I have the feeling that this patch tramples on this aspect of the
original msys (1.0). Which is not nice...

Since the patch changes branches that were formerly mingw but not
cygwin, I guess that the patch is aiming for changing the case where
msys is used in its normal use case targeting MSVCRT. If I have
assumed wrong here, then the patch is clearly suspect.

But why would you want to change the host-triplet from mingw* to
msys* in the case that my assuption is correct? That would break
a lot of packages that has already been ported to mingw, no?
When you cross-compile from linux using a mingw toolchain, you still
use a mingw* host-triplet, why you you want to wander away from
that when you use the mingw toolchain from msys2? So, the patch is
suspect even if my above assumption is correct.

Cheers,
Peter

Re: [sr #108558] libtool nm test does not really work for W32 versions of nm

[Peter Rosin]

On 2014-05-06 15:30, Peter Rosin wrote:
 Follow-up Comment #8, sr #108558 (project libtool):
 
 I have attached a patch that does the safe-safe-safe version.
 Does it work for you?

*snip*

   http://savannah.gnu.org/support/?108558

To not force everyone to follow the link, here's the patch
in question.

Cheers,
Peter

From 13aa364c0c66f9f6b41f98772d0735039ac974a1 Mon Sep 17 00:00:00 2001
From: Peter Rosin p...@lysator.liu.se
Date: Tue, 6 May 2014 10:11:34 +0200
Subject: [PATCH] libtool: fix nm test for MSYS/MinGW

The check for the -B option of nm does not work as intended on MSYS/MinGW.
MSYS converts /dev/null to the DOW/Windows equivanent special file NUL,
but the MinGW nm treats this file as any empty file. This means that
you might end up with some fallback nm instead of the desired nm. This
is not normally a problem, but if one nm is built without lto support, it
starts to matter.

Fixes sr #108558, reported by LRN.

* m4/libtool.m4 (LT_PATH_NM) [MSYS]: Use a non-existant file instead of
/dev/null when checking if nm supports -B.

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

diff --git a/m4/libtool.m4 b/m4/libtool.m4
index 0454030..320d8b3 100644
--- a/m4/libtool.m4
+++ b/m4/libtool.m4
@@ -3509,8 +3509,13 @@ else
 	# Adding the 'sed 1q' prevents false positives on HP-UX, which says:
 	#   nm: unknown option B ignored
 	# Tru64's nm complains that /dev/null is an invalid object file
-	case `$tmp_nm -B /dev/null 21 | sed '1q'` in
-	*/dev/null* | *'Invalid file or object type'*)
+	# MSYS converts /dev/null to NUL, MinGW nm treats NUL as empty
+	case $build_os in
+	mingw*) lt_bad_file=conftest.nm/nofile ;;
+	*) lt_bad_file=/dev/null ;;
+	esac
+	case `$tmp_nm -B $lt_bad_file 21 | sed '1q'` in
+	*$lt_bad_file* | *'Invalid file or object type'*)
 	  lt_cv_path_NM=$tmp_nm -B
 	  break 2
 	  ;;
-- 
1.7.9

Re: [SCM] GNU Libtool branch, master, updated. v2.4.2.444-2-g581d90b

[Peter Rosin]

On 2014-01-03 02:01, Gary V. Vaughan wrote:
 Joking aside, you're quite right, I'll shuffle the order of bootstrap.in
 to leave that warning at the top, and remove the write bit from the
 generated file.

Thanks for fixing that! (too)

Cheers,
Peter

Re: [SCM] GNU Libtool branch, master, updated. v2.4.2.444-2-g581d90b

[Peter Rosin]

On 2014-01-02 01:32, Gary V. Vaughan wrote:
 Peter's a7462c5 fix was applied to the generated bootstrap script
 instead of the funclib.sh source, and had have been overwritten
 the next time bootstrap was regenerated.

Nice catch! As my feeble defense, I claim that there should have been a
generated, do not edit comment in the files that are generated with
funclib.sh. :-)

Cheers,
Peter

Re: bootstrap breakage starting with fec7d87

[Peter Rosin]

On 2013-11-19 10:08, Ozkan Sezer wrote:
 Starting with fec7d87 (funclib.sh: simplify version comparison
 functions) I am getting the following error from bootstrap:

 bootstrap:   error:   'makeinfo' version == 4.13 is too old
 bootstrap:'makeinfo' version = 4.8 is required

 9fd7b88 is fine.

 This is with Fedora 16, with grep-2.9-3.fc16.x86_64,
 sed-4.2.1-9.fc16.x86_64, and bash-4.2.37-1.fc16.x86_64

 
 Will this be fixed anytime soon?

Yes, please.

I came up with this patch, but I don't know how portable it is, so I would
like someone knowledgeable to comment on it before pushing it...

Cheers,
Peter

From a7462c5563e124e06f4f61ce2a9cea26cf8be390 Mon Sep 17 00:00:00 2001
From: Peter Rosin p...@lysator.liu.se
Date: Tue, 19 Nov 2013 11:54:27 +0100
Subject: [PATCH] bootstrap: fix version sort

Reported by Ozkan Sezer who suffered from makeinfo 4.13 being detected
as lesser than the required makeinfo 4.8.

* bootstrap (func_sort_ver): Sort numerically on the non-primary keys
as well.
---
 bootstrap |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/bootstrap b/bootstrap
index 1b16d95..852efd5 100755
--- a/bootstrap
+++ b/bootstrap
@@ -1323,7 +1323,7 @@ func_sort_ver ()
 $debug_cmd
 
 printf '%s\n%s\n' $1 $2 |
-sort -t. -k1n -k1 -k2n -k2 -k3n -k3 -k4n -k4 -k5n -k5 -k6n -k6 -k7n -k7 -k8n -k8 -k9n -k9
+sort -t. -k 1,1n -k 2,2n -k 3,3n -k 4,4n -k 5,5n -k 6,6n -k 7,7n -k 8,8n -k 9,9n
 }
 
 # func_lt_ver PREV CURR
-- 
1.7.9

Re: g++ and -nostdlib

[Peter Rosin]

[re-adding libtool@]

On 2013-11-11 16:10, Bob Friesenhahn wrote:
 On Mon, 11 Nov 2013, Peter Rosin wrote:

 Quite a lot of effort went into making this work the way it currently does.

 I realize that, but if it really works or not is a different question :-)
 
 Yes, of course. It is obviously primarily working as demonstrated
 by the massive amount of software linked for years and years using
 libtool.

Right, I wasn't really serious.

 I.e., as far as I can tell, $LD is not used for linking. $CXX is used, with
 -nostdlib and some manually detected libs/objects, which end up wrong if
 different flags (such as -pthread) are used when digging and actually 
 linking.
 
 Yes, GCC has known bugs with reporting the libraries which would
 actually be used based on proposed arguments. It must be the case
 that GCC maintainers don't consider this to be a bug since GCC has
 not changed its behavior.

Even if GCC did report dependent libs correctly (for the libtool version
of correctly), libtool would have a difficult time replicating what libs
to actually apply if one project builds a number of libraries/programs
with different GCC options. It's a bit fragile by design.

 Googling a bit more turned up this old quote from Ralf [1] on this subject:

   BTW, I believe libtool does the -nostdlib stuff because, at least in the 
 past,
   not using it could cause situations where later libstdc++ would not be 
 found
   automatically.  I think at least for dlopen'ed modules depending on C++
   libraries this is still the case (completely untested).

 That was 8 years ago, even then it appears noone really knew why -nostdlib
 is used (which is interesting in itself).
 
 As far as I am aware, the issue is primarily due to some C++ standard
 libraries being delivered as static libraries (usually due to C++
 exceptions problems) and therefore necessitating being linked to the
 dependent executable rather than into a shared library (which may
 then be linked with other shared libraries linked into an
 executable). This magic is done via information cached in the .la
 files.

And why wouldn't the standard library be picked up again by the compiler
driver when linking the dependent executable?

 Intuiting all the libraries which would be used has been a core
 tenant of libtool given that it attempts to record all the linkage
 dependencies in its .la files.

I don't understand why it is necessary to relist dependencies that
the compiler driver is going to find anyway. Why does libtool need
this degree of control?

 So, someone needs to write some test cases that tries to build a library
 with --static-libgcc and then use that in a program w/o --static-libgcc
 (and vice versa), as well as doing some dlopen test with C++ modules to
 try to deduce if the above problem described by Ralf can still be
 reproduced (but his wording suggest that it might be subtle). And lastly we
 might need some test that tries to throw C++ exceptions over DLL boundaries,
 if that isn't already done by tests/exceptions.at...
 
 The tests/exceptions.at tests the ability to catch exceptions thrown
 from a DLL. It is not uncommon for it to fail with GCC for certain
 targets due to target-specific libtool bugs or GCC compiler bugs.
 Even with this test, it very difficult to tell if the C++ exceptions
 framework is really working. In my experience, C++ exceptions are
 reliably working with proprietary compilers and sometimes failing
 with GCC.

Ok, so this test sometimes fails even if libtool tries to be clever.
Maybe it fails because libtool is too clever? It would be interesting
to know if the test continues to fail if libtool just trusts the
compiler driver (i.e. with the patch applied). I can't tell, because
the test works both with and without the patch for me.

 In my opinion, this topic is significant enough that it should be
 discussed on the general libtool list before any decision to rip out
 the existing special GCC support and treat GCC similar to other
 compilers.

I didn't notice that libtool@ was dropped by Chuck. So, I'm switching
to that list instead. Please drop libtool-patches@ next time.

Anyway, when I started this thread, my main interest was to understand
*why* libtool does the -nostdlib dance. But as I'm not personally
affected by it, I'm not really pushing for my patch, it is mainly there
to trigger discussion. What I would like to see is some test cases that
actually fails when libtool simply trusts GCC to DTRT. Currently the
test suite is clean with my patch, at least on Cygwin. If we have some
test cases we know what is sacrificed if -nostdlib is dropped.

If we can't construct a valid test case that works with -nostdlib, but
fails without it, that would be quite telling though...

So, can someone conjure up such a test case? I can't, I'd be fumbling and
wouldn't know where to start.

Cheers,
Peter

Re: g++ and -nostdlib

[Peter Rosin]

On 2013-11-08 20:07, Charles Wilson wrote:
 On 11/8/2013 1:49 PM, Bob Friesenhahn wrote:
 Isn't it because libtool wants to control the order of the linking and
 assure that all dependencies (including static) are tracked/known and
 applied at the correct times?  It wants to assure that static
 dependencies are linked into the dependent program rather than into some
 dependent shared library (and thus causing a problem).

 It was common (and perhaps still is) for the GNU C++ library to be
 delivered as a static library for Windows/MinGW because C++ exceptions
 were not handled properly when thrown by DLLs.

 Quite a lot of effort went into making this work the way it currently does.

I realize that, but if it really works or not is a different question :-)

 First libtool tries to take away all of the libraries which would be
 added automatically and then it applies the libraries that GCC says it
 would use at the correct time.

 One of my wishlist roundtuit items is to special-case this behavior
 for libtool + GNU toolchains. For that combo, instead of the
 procedure Bob outlines, and then using $LD to linkjust use the
 compiler driver (e.g. g++, or gfortran, or gcc) to link, WITHOUT
 -nostdlib [1]. We're already passing the ABI-modifying -m and -f
 flags anyway, and it would really REALLY simplify libtool's logic...

 [1] unless of course the end user put -nostdlib in $LDFLAGS or something.

Hmmm, I don't get it. For me (on Cygwin, but reading the code suggests that
the following holds for all hosts) libtool already uses the compiler driver
to link C++ for GNU toolchains. The only abnormal thing I see is the
-nostdlib dance.

I.e., as far as I can tell, $LD is not used for linking. $CXX is used, with
-nostdlib and some manually detected libs/objects, which end up wrong if
different flags (such as -pthread) are used when digging and actually linking.

I also had a closer look at the result of my first patch and have attached
a 2nd attempt that zaps more cruft (predep and postdep libraries) from the
linking stage. This version should be close to the above wishlist item
mentioned by Chuck (even if the complicated logic isn't actually removed
by my small change, it's just bypassed for g++).

Googling a bit more turned up this old quote from Ralf [1] on this subject:

   BTW, I believe libtool does the -nostdlib stuff because, at least in the 
past,
   not using it could cause situations where later libstdc++ would not be found
   automatically.  I think at least for dlopen'ed modules depending on C++
   libraries this is still the case (completely untested).

That was 8 years ago, even then it appears noone really knew why -nostdlib
is used (which is interesting in itself).

So, someone needs to write some test cases that tries to build a library
with --static-libgcc and then use that in a program w/o --static-libgcc
(and vice versa), as well as doing some dlopen test with C++ modules to
try to deduce if the above problem described by Ralf can still be
reproduced (but his wording suggest that it might be subtle). And lastly we
might need some test that tries to throw C++ exceptions over DLL boundaries,
if that isn't already done by tests/exceptions.at...

Is that it?

Cheers,
Peter

[1] http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25460

From 56080c9349ae56fcac6e7bf7f6081dfa48a7fc67 Mon Sep 17 00:00:00 2001
From: Peter Rosin p...@lysator.liu.se
Date: Mon, 11 Nov 2013 09:48:23 +0100
Subject: [PATCH] libtool: Do not use -nostdlib when linking with g++.

Fixes part of bug#15646 and Debian bug 468555.

* m4/libtool.m4 (_LT_LANG_CXX_CONFIG) [g++] archive_cmds
archive_expsym_cmds: Drop -nostdlib, $predep_objects and
$postdep_objects.
(_LT_LANG_CXX_CONFIG) [g++]: Do not look for hidden library
dependencies.
* NEWS: Update.
---
 NEWS  |6 ++
 m4/libtool.m4 |   34 ++
 2 files changed, 24 insertions(+), 16 deletions(-)

diff --git a/NEWS b/NEWS
index 0c85812..5717385 100644
--- a/NEWS
+++ b/NEWS
@@ -2,6 +2,12 @@ NEWS - list of user-visible changes between releases of GNU Libtool
 
 * Noteworthy changes in release ?.? (-??-??) [?]
 
+** Important incompatible changes:
+
+  - When linking shared libraries with g++, trust the compiler driver to
+interface correctly with the linker.  I.e., drop the -nostdlib
+option in this case. Fixes point 2 (and perhaps 3) in bug#15646, as
+well as Debian bug 468555.
 
 * Noteworthy changes in release 2.4.2.418 (2013-10-27) [alpha]
 
diff --git a/m4/libtool.m4 b/m4/libtool.m4
index 4bc6b22..e34e021 100644
--- a/m4/libtool.m4
+++ b/m4/libtool.m4
@@ -6046,8 +6046,8 @@ if test yes != $_lt_caught_CXX_error; then
   # Check if GNU C++ uses GNU ld as the underlying linker, since the
   # archiving commands below assume that GNU ld is being used.
   if test yes = $with_gnu_ld; then
-_LT_TAGVAR(archive_cmds, $1)='$CC $pic_flag -shared -nostdlib $predep_objects $libobjs $deplibs $postdep_objects

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

[Peter Rosin]

Hi!

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

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

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

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

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

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

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

[Peter Rosin]

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

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

Cheers,
Peter

g++ and -nostdlib

[Peter Rosin]

Hi!

There seem to be a longstanding complaint that libtool is using
-nostdlib when it links libraries using g++. It interferes with
-pthread and I think I have also seen other issues. No one can
give a satisfactory explanation why libtool does this, it seems
like it is just the way it has always been and noone dares
changing it. To me, it all smells like something that was needed
once upon a time when g++ was still immature, and whatever issues
it solved we no longer need to worry about. So, just for thrills
I had a quick peek at the code, and it looks quite simple to
simply nix this obnoxious -nostdlib use.

I realize that the timing isn't the best with the alpha release
and all, but this probably needs to be tested a bit more before
it's pushed anyway, so I'm simply posting this as an RFC and
don't expect it to be committed until later.

Should it be listed as an incompatible change? Or simply a bug
fix?

BTW, it even appears to work, but please test, as I have only
done very light testing...

Oh well. Any thoughts?

Cheers,
Peter
From a233b4562d4274053852bc0353e36931beeb4803 Mon Sep 17 00:00:00 2001
From: Peter Rosin p...@lysator.liu.se
Date: Fri, 8 Nov 2013 19:01:24 +0100
Subject: [PATCH] libtool: Do not use -nostdlib when linking with g++.

Fixes part of bug#15646 and Debian bug 468555.

* m4/libtool.m4 (_LT_LANG_CXX_CONFIG) [g++] archive_cmds
archive_expsym_cmds: Drop -nostdlib, $predep_objects and
$postdep_objects.
* NEWS: Update.
---
 NEWS  |6 ++
 m4/libtool.m4 |   30 +++---
 2 files changed, 21 insertions(+), 15 deletions(-)

diff --git a/NEWS b/NEWS
index 0c85812..5717385 100644
--- a/NEWS
+++ b/NEWS
@@ -2,6 +2,12 @@ NEWS - list of user-visible changes between releases of GNU Libtool
 
 * Noteworthy changes in release ?.? (-??-??) [?]
 
+** Important incompatible changes:
+
+  - When linking shared libraries with g++, trust the compiler driver to
+interface correctly with the linker.  I.e., drop the -nostdlib
+option in this case. Fixes point 2 (and perhaps 3) in bug#15646, as
+well as Debian bug 468555.
 
 * Noteworthy changes in release 2.4.2.418 (2013-10-27) [alpha]
 
diff --git a/m4/libtool.m4 b/m4/libtool.m4
index 4bc6b22..d13afc3 100644
--- a/m4/libtool.m4
+++ b/m4/libtool.m4
@@ -6046,8 +6046,8 @@ if test yes != $_lt_caught_CXX_error; then
   # Check if GNU C++ uses GNU ld as the underlying linker, since the
   # archiving commands below assume that GNU ld is being used.
   if test yes = $with_gnu_ld; then
-_LT_TAGVAR(archive_cmds, $1)='$CC $pic_flag -shared -nostdlib $predep_objects $libobjs $deplibs $postdep_objects $compiler_flags $wl-soname $wl$soname -o $lib'
-_LT_TAGVAR(archive_expsym_cmds, $1)='$CC $pic_flag -shared -nostdlib $predep_objects $libobjs $deplibs $postdep_objects $compiler_flags $wl-soname $wl$soname $wl-retain-symbols-file $wl$export_symbols -o $lib'
+_LT_TAGVAR(archive_cmds, $1)='$CC $pic_flag -shared $libobjs $deplibs $compiler_flags $wl-soname $wl$soname -o $lib'
+_LT_TAGVAR(archive_expsym_cmds, $1)='$CC $pic_flag -shared $libobjs $deplibs $compiler_flags $wl-soname $wl$soname $wl-retain-symbols-file $wl$export_symbols -o $lib'
 
 _LT_TAGVAR(hardcode_libdir_flag_spec, $1)='$wl-rpath $wl$libdir'
 _LT_TAGVAR(export_dynamic_flag_spec, $1)='$wl--export-dynamic'
@@ -6073,7 +6073,7 @@ if test yes != $_lt_caught_CXX_error; then
 # linker, instead of GNU ld.  If possible, this setting should
 # overridden to take advantage of the native linker features on
 # the platform it is being used on.
-_LT_TAGVAR(archive_cmds, $1)='$CC -shared -nostdlib $predep_objects $libobjs $deplibs $postdep_objects $compiler_flags -o $lib'
+_LT_TAGVAR(archive_cmds, $1)='$CC -shared $libobjs $deplibs $compiler_flags -o $lib'
   fi
 
   # Commands to make compiler produce verbose output that lists
@@ -6296,7 +6296,7 @@ if test yes != $_lt_caught_CXX_error; then
 	  _LT_TAGVAR(enable_shared_with_static_runtimes, $1)=yes
 
 	  if $LD --help 21 | $GREP 'auto-import'  /dev/null; then
-	_LT_TAGVAR(archive_cmds, $1)='$CC -shared -nostdlib $predep_objects $libobjs $deplibs $postdep_objects $compiler_flags -o $output_objdir/$soname $wl--enable-auto-image-base -Xlinker --out-implib -Xlinker $lib'
+	_LT_TAGVAR(archive_cmds, $1)='$CC -shared $libobjs $deplibs $compiler_flags -o $output_objdir/$soname $wl--enable-auto-image-base -Xlinker --out-implib -Xlinker $lib'
 	# If the export-symbols file already is a .def file, use it as
 	# is; otherwise, prepend EXPORTS...
 	_LT_TAGVAR(archive_expsym_cmds, $1)='if _LT_DLL_DEF_P([$export_symbols]); then
@@ -6305,7 +6305,7 @@ if test yes != $_lt_caught_CXX_error; then
   echo EXPORTS  $output_objdir/$soname.def;
   cat $export_symbols  $output_objdir/$soname.def;
 fi~
-$CC -shared -nostdlib $output_objdir/$soname.def $predep_objects

Re: Two-month patch ping: Re: powerpc*le-linux support

[Peter Rosin]

On 2013-08-22 09:40, Gary V. Vaughan wrote:
 Can we please get this simple patch pushed?
 
 Done.

To me, it appears as if what you actually pushed was not what was posted?

Cheers,
Peter

Re: powerpc*le-linux support

[Peter Rosin]

Hi!

Ok, Gary pushed something while I wrote this, but I'm sending it
anyway since what he pushed didn't look quite right to me...

On 2013-06-06 07:18, Alan Modra wrote:
 On Thu, Jun 06, 2013 at 11:31:34AM +0930, Alan Modra wrote:
 This adds support for little-endian powerpc linux, and tidies the
 existing host match for powerpc.  config.sub won't return ppc*-*linux*
 so there isn't much point in matching that.
 
 -  ppc*-*linux*|powerpc*-*linux*)
 +  powerpcle*)
 +LD=${LD-ld} -m elf64lppc
 +;;
 +  powerpc*)
  LD=${LD-ld} -m elf64ppc
  ;;
 
 I didn't get that quite right.  'powerpc*' in the above matches too
 much, for example when your host is powerpc64-linux and target
 powerpc64le-linux you'll get -melf64ppc added to LD.  Since
 powerpc64le-linux-ld wants -melf64lppc (or nothing) that will fail.
 Revised as follows.
 
   * m4/libtool.m4 (ld -m flags): Remove non-canonical ppc host match.

The macro/function you are changing is _LT_ENABLE_LOCK, so that should be

* m4/libtool.m4 (_LT_ENABLE_LOCK): ...

   Support little-endian powerpc linux host.
 
 diff --git a/m4/libtool.m4 b/m4/libtool.m4
 index d7013c5..501246d 100644
 --- a/m4/libtool.m4
 +++ b/m4/libtool.m4
 @@ -1307,7 +1307,7 @@ ia64-*-hpux*)
rm -rf conftest*
;;
  
 -x86_64-*kfreebsd*-gnu|x86_64-*linux*|ppc*-*linux*|powerpc*-*linux*| \
 +x86_64-*kfreebsd*-gnu|x86_64-*linux*|powerpc*-*linux*| \
  s390*-*linux*|s390*-*tpf*|sparc*-*linux*)
# Find out which ABI we are using.
echo 'int i;'  conftest.$ac_ext
 @@ -1328,7 +1328,10 @@ s390*-*linux*|s390*-*tpf*|sparc*-*linux*)
   ;;
   esac
   ;;
 -   ppc64-*linux*|powerpc64-*linux*)
 +   powerpc64le-*)
 + LD=${LD-ld} -m elf32lppclinux
 + ;;
 +   powerpc64-*)
   LD=${LD-ld} -m elf32ppclinux
   ;;
 s390x-*linux*)

All other inner cases match one of the outer or-ed expressions (i.e.
from the first hunk) quite closely, but the outer match is still
powerpc*-*linux* while the inner match has dropped the trailing
-*linux* part. I would have kept them in sync. This also made me think
about the 32-bit case; is there no le variant for 32-bit powerpc?
Compare with the x86_64 case just above this hunk. To me, it seems as
if -m elf32lppclinux should be added to $LD at least in some case?

When you build 32-bit output and $host is 64-bit, you need to specify
endianess (elf32lppclinux or elf32ppclinux). When you build 64-bit
output and $host is 64-bit, you need to specify endianess (elf64lppc
or elf64ppc). I miss the case when you build 32-bit output and $host
is 32-bit, i.e. something like the below (assuming $host is
powerpcle-* and powerpc-* for 32-bit) at the end of the second hunk:

+ powerpcle-*linux*)
+   LD=${LD-ld} -m elf32lppclinux
+   ;;
+ powerpc-*linux*)
+   LD=${LD-ld} -m elf32ppclinux
+   ;;

If there is no 32-bit le powerpc variant (why wouldn't there be?), then
the subject is somewhat misleading when le is only handled for 64-bit
hosts.

 @@ -1347,7 +1350,10 @@ s390*-*linux*|s390*-*tpf*|sparc*-*linux*)
 x86_64-*linux*)
   LD=${LD-ld} -m elf_x86_64
   ;;
 -   ppc*-*linux*|powerpc*-*linux*)
 +   powerpcle-*)
 + LD=${LD-ld} -m elf64lppc
 + ;;
 +   powerpc-*)
   LD=${LD-ld} -m elf64ppc
   ;;
 s390*-*linux*|s390*-*tpf*)
 
 

Or what am I not getting? I'm probably just ignorant...ö

Cheers,
Peter

Re: powerpc*le-linux support

[Peter Rosin]

On 2013-08-22 10:19, Gary V. Vaughan wrote:
 On Aug 22, 2013, at 2:59 PM, Peter Rosin p...@lysator.liu.se wrote:
 On 2013-06-06 07:18, Alan Modra wrote:

*snip*

 diff --git a/m4/libtool.m4 b/m4/libtool.m4
 index d7013c5..501246d 100644
 --- a/m4/libtool.m4
 +++ b/m4/libtool.m4
 @@ -1307,7 +1307,7 @@ ia64-*-hpux*)
   rm -rf conftest*
   ;;

 -x86_64-*kfreebsd*-gnu|x86_64-*linux*|ppc*-*linux*|powerpc*-*linux*| \
 +x86_64-*kfreebsd*-gnu|x86_64-*linux*|powerpc*-*linux*| \
 s390*-*linux*|s390*-*tpf*|sparc*-*linux*)
   # Find out which ABI we are using.
   echo 'int i;'  conftest.$ac_ext
 @@ -1328,7 +1328,10 @@ s390*-*linux*|s390*-*tpf*|sparc*-*linux*)
 ;;
 esac
 ;;
 - ppc64-*linux*|powerpc64-*linux*)
 + powerpc64le-*)
 +   LD=${LD-ld} -m elf32lppclinux
 +   ;;
 + powerpc64-*)
 LD=${LD-ld} -m elf32ppclinux
 ;;
   s390x-*linux*)

*snip*

 This also made me think
 about the 32-bit case; is there no le variant for 32-bit powerpc?
 Compare with the x86_64 case just above this hunk. To me, it seems as
 if -m elf32lppclinux should be added to $LD at least in some case?
 
 That's only because I fumbled the initial commit.  The original patch
 catches ppcle on 32 and 64 bit legs of that case statement.

No, that's no what I meant at all, my above paragraph was about the
same issue as my below paragraph (your munged commit just happened to
inconveniently fit the description).

 When you build 32-bit output and $host is 64-bit, you need to specify
 endianess (elf32lppclinux or elf32ppclinux). When you build 64-bit
 output and $host is 64-bit, you need to specify endianess (elf64lppc
 or elf64ppc). I miss the case when you build 32-bit output and $host
 is 32-bit, i.e. something like the below (assuming $host is
 powerpcle-* and powerpc-* for 32-bit) at the end of the second hunk:

 +  powerpcle-*linux*)
 +LD=${LD-ld} -m elf32lppclinux
 +;;
 +  powerpc-*linux*)
 +LD=${LD-ld} -m elf32ppclinux
 +;;

 If there is no 32-bit le powerpc variant (why wouldn't there be?), then
 the subject is somewhat misleading when le is only handled for 64-bit
 hosts.

I guess I'm just thoroughly confused, but in my world there ought to
be four variations of $host; 64- or 32-bit, and big or little endian.

This patch seems to only handle builds going from 64-bit to 32-bit
($host powerpc64-* and 32-bit output) and compiles going from 32-bit
to 64-bit ($host powerpc-* and 64-bit output).

Both of those cases ought to be cross compiles. But I don't get why you
apparently do not need to give any -m option to ld when you cross-compile
from 32-bit little-endian to 32-bit big-endian and from 64-bit l-e to
64-bit b-e? Is the user required to provide the appropriate -m option
manually in that case? Why is it important to be more helpful for
crosses over the 32/64 boundary?

Sorry for my ppc ignorance...

*snip*

Cheers,
Peter

Re: powerpc*le-linux support

[Peter Rosin]

On 2013-08-22 15:25, Alan Modra wrote:
 On Thu, Aug 22, 2013 at 01:16:04PM +0200, Peter Rosin wrote:
 I guess I'm just thoroughly confused, but in my world there ought to
 be four variations of $host; 64- or 32-bit, and big or little endian.

 This patch seems to only handle builds going from 64-bit to 32-bit
 ($host powerpc64-* and 32-bit output) and compiles going from 32-bit
 to 64-bit ($host powerpc-* and 64-bit output).

 Both of those cases ought to be cross compiles. But I don't get why you
 apparently do not need to give any -m option to ld when you cross-compile
 from 32-bit little-endian to 32-bit big-endian and from 64-bit l-e to
 64-bit b-e? Is the user required to provide the appropriate -m option
 manually in that case? Why is it important to be more helpful for
 crosses over the 32/64 boundary?
 
 Yes, we might need to handle those cases too.  I've only just started
 looking into the cross-endian multilib support in gcc..
 
 As to why the cases I handled are more important:  On a powerpc64le
 linux host where the compiler defaulted to producing 64-bit objects
 (which is how we generally build compilers nowadays) libtool added
 -m elf64ppc to $LD here.  Being the option for 64-bit big-endian, that
 caused complete failure for *native* 64-bit little-endian.  Which is
 where the action is at the moment.

Ah, I see. Thanks!

Cheers,
Peter

Re: Two-month patch ping: Re: powerpc*le-linux support

[Peter Rosin]

On 2013-08-22 10:20, Gary V. Vaughan wrote:
 Hi Peter,
 
 On Aug 22, 2013, at 2:54 PM, Peter Rosin p...@lysator.liu.se wrote:
 
 On 2013-08-22 09:40, Gary V. Vaughan wrote:
 Can we please get this simple patch pushed?

 Done.

 To me, it appears as if what you actually pushed was not what was posted?
 
 I am an idiot.  Thanks for the heads up, fixed in the following change set.

Still not right though, sorry.

You ended up doing:

- ppc64-*linux*|powerpc64-*linux*)
+ powerpcle-*)
+   LD=${LD-ld} -m elf32lppclinux
+   ;;
+ powerpc-*)

but the original wanted:

- ppc64-*linux*|powerpc64-*linux*)
+ powerpc64le-*)
+   LD=${LD-ld} -m elf32lppclinux
+   ;;
+ powerpc64-*)

But, the originally supplied version confuses me yet again, so I'm not
committing the fix myself...

How can it be correct to say -m elf32lppclinux (32-bit) when $host is
explicitly 64-bit? That seems like utter garbage to me. What am I
missing this time?

Cheers,
Peter

Re: [PATCH] Fix conversion warnings in cwrapper

[Peter Rosin]

On 2013-05-27 21:21, Yaakov (Cygwin/X) wrote:
 On 2013-05-27 11:28, Peter Rosin wrote:
 Ok, I took the liberty of writing a ChangeLog and removed the above
 mentioned lines, as well as changing one unsigned int cast to a
 size_t cast, when figured I should double-check your email-address
 and realized that you had some previous tiny changes under your
 belt. Now, these changes are also tiny, but my understanding is
 that you are not allowed more than 10 or so total line edits and
 still get away with a tiny change. You are getting dangerously
 close to the limit, and should probably refrain from sending any
 more patches w/o a copyright assignment in place.
 
 I have had an assignment on file with FSF since 2009.

That fact has sadly not been recorded in the Libtool THANKS file. The
only thing I have found is this paragraph near the end of an old patch
submission [1] you co-authored with Chuck.

FYI, Yaakov has submitted all the necessary copyright papers
and received acknowledgement from the FSF.

Since I can't see the rush, I'll hold this a bit further in the hope
that this omission will be cleared up first.

Cheers,
Peter

[1] http://lists.gnu.org/archive/html/libtool-patches/2010-02/msg00019.html

Re: [PATCH] Fix conversion warnings in cwrapper

[Peter Rosin]

Hi Yaakov,

On 2013-05-21 08:53, Peter Rosin wrote:
 I have no problem with this patch from a cursory look (haven't tested
 it yet), but I will wait a couple of days with committing it to see
 if Chuck (or someone else for that matter) has something to add.
 Meanwhile, could we please have an update that also zap these lines
 (inside a _MSC_VER #ifdef) as they are no longer needed?
 
 # ifndef _INTPTR_T_DEFINED
 #  define _INTPTR_T_DEFINED
 #  define intptr_t int
 # endif

Ok, I took the liberty of writing a ChangeLog and removed the above
mentioned lines, as well as changing one unsigned int cast to a
size_t cast, when figured I should double-check your email-address
and realized that you had some previous tiny changes under your
belt. Now, these changes are also tiny, but my understanding is
that you are not allowed more than 10 or so total line edits and
still get away with a tiny change. You are getting dangerously
close to the limit, and should probably refrain from sending any
more patches w/o a copyright assignment in place. Also, before I
push this, I require a go-ahead from a maintainer.

Cheers,
Peter

From 44216d533edc4fd6649fce12314b7f719ef69fc3 Mon Sep 17 00:00:00 2001
From: Yaakov Selkowitz yselkow...@users.sourceforge.net
Date: Mon, 27 May 2013 18:22:38 +0200
Subject: [PATCH] libtool: fix conversion warnings in cwrapper

build-aux/ltmain.in (func_emit_cwrapperexe_src:main): XMALLOC wants a
size_t. Also use int instead of intptr_t for the return value (which
is fine since the _spawnv call is synchronous).
(func_emit_cwrapper_src) [MSVC]: Remove the intptr_t helper define.
(func_emit_cwrapperexe_src:find_executable): Use size_t for variables
involved in strlen computations.
(func_emit_cwrapperexe_src:lt_setenv): Likewise.
(func_emit_cwrapperexe_src:lt_extend_str): Likewise.
(func_emit_cwrapperexe_src:lt_update_exe_path): Likewise.

Copyright-paperwork-exempt: Yes
Signed-off-by: Yaakov Selkowitz yselkow...@users.sourceforge.net
Co-authored-by: Peter Rosin p...@lysator.liu.se
---
 build-aux/ltmain.in |   22 +-
 1 files changed, 9 insertions(+), 13 deletions(-)

diff --git a/build-aux/ltmain.in b/build-aux/ltmain.in
index 4c56b98..2d7acdd 100644
--- a/build-aux/ltmain.in
+++ b/build-aux/ltmain.in
@@ -3637,10 +3637,6 @@ int setenv (const char *, const char *, int);
 # define getcwd  _getcwd
 # define putenv  _putenv
 # define S_IXUSR _S_IEXEC
-# ifndef _INTPTR_T_DEFINED
-#  define _INTPTR_T_DEFINED
-#  define intptr_t int
-# endif
 #elif defined __MINGW32__
 # define setmode _setmode
 # define stat_stat
@@ -3797,12 +3793,12 @@ main (int argc, char *argv[])
   char *actual_cwrapper_name;
   char *target_name;
   char *lt_argv_zero;
-  intptr_t rval = 127;
+  int rval = 127;
 
   int i;
 
   program_name = (char *) xstrdup (base_name (argv[0]));
-  newargz = XMALLOC (char *, argc + 1);
+  newargz = XMALLOC (char *, (size_t) argc + 1);
 
   /* very simple arg parsing; don't want to rely on getopt
* also, copy all non cwrapper options to newargz, except
@@ -3964,7 +3960,7 @@ EOF
 		cat EOF
   /* execv doesn't actually work on mingw as expected on unix */
   newargz = prepare_spawn (newargz);
-  rval = _spawnv (_P_WAIT, lt_argv_zero, (const char * const *) newargz);
+  rval = (int) _spawnv (_P_WAIT, lt_argv_zero, (const char * const *) newargz);
   if (rval == -1)
 {
   /* failed to start process */
@@ -4068,7 +4064,7 @@ find_executable (const char *wrapper)
   const char *p_next;
   /* static buffer for getcwd */
   char tmp[LT_PATHMAX + 1];
-  int tmp_len;
+  size_t tmp_len;
   char *concat_name;
 
   lt_debugprintf (__FILE__, __LINE__, (find_executable): %s\n,
@@ -4119,7 +4115,7 @@ find_executable (const char *wrapper)
 	  for (q = p; *q; q++)
 		if (IS_PATH_SEPARATOR (*q))
 		  break;
-	  p_len = q - p;
+	  p_len = (size_t) (q - p);
 	  p_next = (*q == '\0' ? q : q + 1);
 	  if (p_len == 0)
 		{
@@ -4303,7 +4299,7 @@ lt_setenv (const char *name, const char *value)
 char *str = xstrdup (value);
 setenv (name, str, 1);
 #else
-int len = strlen (name) + 1 + strlen (value) + 1;
+size_t len = strlen (name) + 1 + strlen (value) + 1;
 char *str = XMALLOC (char, len);
 sprintf (str, %s=%s, name, value);
 if (putenv (str) != EXIT_SUCCESS)
@@ -4320,8 +4316,8 @@ lt_extend_str (const char *orig_value, const char *add, int to_end)
   char *new_value;
   if (orig_value  *orig_value)
 {
-  int orig_value_len = strlen (orig_value);
-  int add_len = strlen (add);
+  size_t orig_value_len = strlen (orig_value);
+  size_t add_len = strlen (add);
   new_value = XMALLOC (char, add_len + orig_value_len + 1);
   if (to_end)
 {
@@ -4352,7 +4348,7 @@ lt_update_exe_path (const char *name, const char *value)
 {
   char *new_value = lt_extend_str (getenv (name), value, 0);
   /* some systems can't cope with a ':'-terminated path #' */
-  int len = strlen (new_value);
+  size_t len

Re: [PATCH] Fix conversion warnings in cwrapper

[Peter Rosin]

On 2013-05-21 00:49, Yaakov (Cygwin/X) wrote:
 From: Yaakov Selkowitz yselkow...@users.sourceforge.net
 
 Signed-off-by: Yaakov Selkowitz yselkow...@users.sourceforge.net
 ---
  build-aux/ltmain.in |   18 +-
  1 files changed, 9 insertions(+), 9 deletions(-)
 
 diff --git a/build-aux/ltmain.in b/build-aux/ltmain.in
 index 4c56b98..3d1f5af 100644
 --- a/build-aux/ltmain.in
 +++ b/build-aux/ltmain.in
 @@ -3797,12 +3797,12 @@ main (int argc, char *argv[])
char *actual_cwrapper_name;
char *target_name;
char *lt_argv_zero;
 -  intptr_t rval = 127;
 +  int rval = 127;

*snip a bunch of type changes and casts*

I have no problem with this patch from a cursory look (haven't tested
it yet), but I will wait a couple of days with committing it to see
if Chuck (or someone else for that matter) has something to add.
Meanwhile, could we please have an update that also zap these lines
(inside a _MSC_VER #ifdef) as they are no longer needed?

# ifndef _INTPTR_T_DEFINED
#  define _INTPTR_T_DEFINED
#  define intptr_t int
# endif

Cheers,
Peter

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

[Peter Rosin]

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

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

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

Pushed now, and thanks!

Cheers,
Peter

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

[Peter Rosin]

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

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

Cheers,
Peter

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

[Peter Rosin]

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

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

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

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

Cheers,
Peter

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

[Peter Rosin]

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

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

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

Cheers,
Peter

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

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

Report and analysis by Mike Frysinger.

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

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

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

Re: bug#13462: error: file 'build-aux/funclib.sh' not found

[Peter Rosin]

On 2013-01-18 10:46, Peter Rosin wrote:
 On 2013-01-16 18:00, Peter Rosin wrote:
 Hi!

 If I, in a dirty git checkout (added an insignificant newline) as
 of today, do this

  ./bootstrap -fc
  cd ..
  mkdir foo
  cd foo
  ../libtool/configure
  make
  make check

 all is fine. If I then modify build-aux/ltmain.in (with another
 insignificant newline) followed by

  make

 or
  make check

 I get:

   GEN  ../libtool-msvc/build-aux/ltmain.sh
 inline-source:   error: file 'build-aux/funclib.sh' not found
 inline-source:   error: file 'build-aux/options-parser' not found
   GEN  libtool

 followed by numerous failures that appear to be related.
 
 Hi!
 
 This appears to fix it. Ok to commit?

Ping?

Cheers,
Peter

Re: bug#13414: Valid DLL def file mangled by libtool

[Peter Rosin]

close 13414
thanks

Hi!

On 2013-01-22 19:45, Erik van Pienbroek wrote:
 Erik van Pienbroek schreef op zo 20-01-2013 om 15:54 [+0100]:
 Peter Rosin schreef op zo 20-01-2013 om 08:32 [+0100]:
 But I will hold off the push a couple of days pending feedback from
 those actually using .def files for real things.

 Thanks for the patch. To help out with testing I can perform a test mass
 rebuild of all mingw packages which are currently in Fedora (about 135)
 against a libtool package which contains this patch. With this mass
 rebuild we can at least find out whether the patch introduces
 regressions or not. Running such a test mass rebuild will take about 36
 hours to complete, so I'll give an update in about 2 days.
 
 The test mass rebuild of all Fedora MinGW packages against the latest
 libtool with the proposed patches was successful. The packages which
 required workarounds in order to get built can now be built without
 these workarounds, so the original issue is resolved with the proposed
 patches. All other packages were rebuilt successfully as well, so from
 my point of view I'm +1 to the proposed patches.

Ok, that's good enough for me!  Thanks again for testing.

The patches tested by Erik where slightly different from the ones I
posted. I did the whitespace changes in a separate patch and fixed the
copyright year thing spotted by Gary. I also changed

IFS=' ''
'

into

IFS=$sp$nl

The patches tested where also slightly different from the ones I
actually pushed. The pushed version does not have the unneeded quotes
in the above assignment and I changed one instance of

if ! foo; then
...
fi

into

foo || {
...
}

since if ! foo isn't as portable according to Autoconf docs.

Anyway, those last changes are all harmless, I'm just putting all
cards on the table just in case...

Cheers,
Peter

Re: bug#13414: Valid DLL def file mangled by libtool

[Peter Rosin]

On 2013-01-19 06:12, Gary V. Vaughan wrote:
 Hi Peter,
 
 Thanks for working on this.
 
 On 19 Jan 2013, at 05:55, Peter Rosin p...@lysator.liu.se wrote:
 On 2013-01-12 01:26, Peter Rosin wrote:
 On 2013-01-11 12:34, Martin Doucha wrote:
 I'd like to report a bug in libtool 2.4 (including the latest git 
 revision) which mangles valid DLL def files under MinGW and makes the 
 linker barf.

 This issue has been reported before [1].

 So, as hinted above, I'm following up with a pair of patches that
 appear to mend this.

 Ok to push?
 
 By inspection, these patches look good to me - presuming there are no 
 regressions, please go ahead.

I have found no regressions, and thanks for the speedy review!

 One nit: your new test has a Copyright notice starting at 2007 followed by 
 written in 2013. The new code doesn't look derivative of existing tests, so 
 I'd suggest deleting the years prior to 2013 before pushing.

Done.

 Or are the white-space changes in the first patch too intrusive?
 
 If you would like to separate those into a separate patch then please feel 
 free; but I'd rather see functional progress in Libtool development than 
 being overly anal about changeset minutiae for potential future git 
 archaeology at the expense of using your Libtool hacking time more wisely :)

Splitting the commit in two is simple enough, takes little time to do
and I don't feel obliged to test the intermediate state, so I just did
it.

But I will hold off the push a couple of days pending feedback from
those actually using .def files for real things.

Cheers,
Peter

Re: bug#13462: error: file 'build-aux/funclib.sh' not found

[Peter Rosin]

On 2013-01-16 18:00, Peter Rosin wrote:
 Hi!
 
 If I, in a dirty git checkout (added an insignificant newline) as
 of today, do this
 
   ./bootstrap -fc
   cd ..
   mkdir foo
   cd foo
   ../libtool/configure
   make
   make check
 
 all is fine. If I then modify build-aux/ltmain.in (with another
 insignificant newline) followed by
 
   make
 
 or
   make check
 
 I get:
 
   GEN  ../libtool-msvc/build-aux/ltmain.sh
 inline-source:   error: file 'build-aux/funclib.sh' not found
 inline-source:   error: file 'build-aux/options-parser' not found
   GEN  libtool
 
 followed by numerous failures that appear to be related.

Hi!

This appears to fix it. Ok to commit?

Cheers,
Peter

From 3723f8cf69192cf09825a52447652ae47f8f Mon Sep 17 00:00:00 2001
From: Peter Rosin p...@lysator.liu.se
Date: Fri, 18 Jan 2013 10:40:37 +0100
Subject: [PATCH] maint: find external libraries from a VPATH build

Fixes bug#13462.

* build-aux/ltmain.in: Assume that the external libraries are in the
same directory as this script.

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

diff --git a/build-aux/ltmain.in b/build-aux/ltmain.in
index c8cdb9c..2e85cb0 100644
--- a/build-aux/ltmain.in
+++ b/build-aux/ltmain.in
@@ -61,8 +61,8 @@ package_revision=@package_revision@
 # Much of our low-level functionality needs to be sourced from external
 # libraries, which are installed to $pkgauxdir.
 
-. build-aux/funclib.sh
-. build-aux/options-parser
+. `echo $0 |${SED-sed} 's|[^/]*$||'`funclib.sh
+. `echo $0 |${SED-sed} 's|[^/]*$||'`options-parser
 
 # Set a version string.
 scriptversion='(GNU @PACKAGE@) @VERSION@'
-- 
1.7.9

Re: bug#13414: Valid DLL def file mangled by libtool

[Peter Rosin]

Hi Martin, Erik,

On 2013-01-12 01:26, Peter Rosin wrote:
 Hi Martin,
 
 Thanks for the report.
 
 On 2013-01-11 12:34, Martin Doucha wrote:
 Hi,
 I'd like to report a bug in libtool 2.4 (including the latest git revision) 
 which mangles valid DLL def files under MinGW and makes the linker barf.

 The bug is caused by incorect check for EXPORTS keyword in the def file 
 which libtool does this way:
 if test x`$SED 1q $export_symbols` != xEXPORTS; then ... [add another 
 EXPORTS line at the beginning of file]

 This test is incorrect because the EXPORTS keyword does not have to appear 
 on the very first line. You should replace the test with this:
 if test x`$GREP EXPORTS $export_symbols` != xEXPORTS; then ...

 Also note that this test appears on several places throughout libtool 
 sources (both as xEXPORTS and just EXPORTS) so you need to fix all of 
 them.
 
 This issue has been reported before [1].
 
 It's been on my back burner for a while, but I've been held up by
 build system issues. At least, that's my excuse :-)
 
 Anyway, I think your suggested alternative with grep is a bit too
 relaxed, as any symbol involving the substring EXPORTS would
 trigger it. Also, it scans the whole file, which is suboptimal.
 
 I'm looking into a patch that uses
 
   $SED -n \
   -e '/^[ ]*//' \
   -e '/^;/D' \
   -e '/^$/D' \
   -e 's/^EXPORTS.*/DEF/p' \
   -e 's/^LIBRARY.*/DEF/p' \
   -e q \
   $export_symbols
 
 instead (coupled with a test for DEF instead, naturally). Does
 anybody have any issues with such a beast? Yes, I know that it
 will not catch any valid .def file, but I don't fancy writing a
 full .def file parser for this [2].
 
 The above steps past initial comment and whitespace lines waiting
 for the first real line, and triggers if it starts with EXPORTS
 or LIBRARY (at least, that's the intention...)
 
 [1] http://lists.gnu.org/archive/html/libtool/2012-02/msg00023.html
 [2] http://msdn.microsoft.com/en-us/library/h41zhe21(v=vs.110).aspx

I'm back, with suggested changes against latest git, and I'm curious
if it is enough to solve your problem?

If you are not able to check for some reason, it might be possible for
you to provide the .def file you had the problem with? (this question
was mainly for Martin, Erik had enough specifics in his report)

Also, while I recognize that my evaluation of Martin's patch was
flawed in that his grep-based patch doesn't trigger on any symbol
with EXPORTS as a substring (which I stated, I was using the
mental model of my patch on his code, and stumbled), it still
reads the whole .def file and doesn't catch .def files with a
symbol on the same line as the EXPORTS keyword...

So, as hinted above, I'm following up with a pair of patches that
appear to mend this.

Ok to push?

Or are the white-space changes in the first patch too intrusive?

Cheers,
Peter

[PATCH 1/2] libtool: allow tabs in $cmds variables

[Peter Rosin]

build-aux/ltmain.in (func_execute_cmds, func_mode_link): Don't collapse
tabs and surrounding whitespace into a single space when executing a
tilde-separated cmds construct, instead keep any tabs intact.
m4/libtool.m4: Convert indenting tabs to spaces for all *_cmds
variables affected by the above.

Signed-off-by: Peter Rosin p...@lysator.liu.se
---
 build-aux/ltmain.in |8 ++-
 m4/libtool.m4   |  170 +-
 2 files changed, 91 insertions(+), 87 deletions(-)

diff --git a/build-aux/ltmain.in b/build-aux/ltmain.in
index c8cdb9c..eb224e3 100644
--- a/build-aux/ltmain.in
+++ b/build-aux/ltmain.in
@@ -656,8 +656,10 @@ func_execute_cmds ()
 
 save_ifs=$IFS; IFS='~'
 for cmd in $1; do
-  IFS=$save_ifs
+  IFS=' ''
+'
   eval cmd=\$cmd\
+  IFS=$save_ifs
   func_show_eval $cmd ${2-:}
 done
 IFS=$save_ifs
@@ -7964,8 +7966,10 @@ EOF
 
save_ifs=$IFS; IFS='~'
for cmd in $cmds; do
- IFS=$save_ifs
+ IFS=' ''
+'
  eval cmd=\$cmd\
+ IFS=$save_ifs
  $opt_quiet || {
func_quote_for_expand $cmd
eval func_echo $func_quote_for_expand_result
diff --git a/m4/libtool.m4 b/m4/libtool.m4
index eb44de6..4bc9e98 100644
--- a/m4/libtool.m4
+++ b/m4/libtool.m4
@@ -4785,12 +4785,12 @@ _LT_EOF
# If the export-symbols file already is a .def file (1st line
# is EXPORTS), use it as is; otherwise, prepend...
_LT_TAGVAR(archive_expsym_cmds, $1)='if test EXPORTS = `$SED 1q 
$export_symbols`; then
- cp $export_symbols $output_objdir/$soname.def;
-   else
- echo EXPORTS  $output_objdir/$soname.def;
- cat $export_symbols  $output_objdir/$soname.def;
-   fi~
-   $CC -shared $output_objdir/$soname.def $libobjs $deplibs 
$compiler_flags -o $output_objdir/$soname $wl--enable-auto-image-base -Xlinker 
--out-implib -Xlinker $lib'
+  cp $export_symbols $output_objdir/$soname.def;
+else
+  echo EXPORTS  $output_objdir/$soname.def;
+  cat $export_symbols  $output_objdir/$soname.def;
+fi~
+$CC -shared $output_objdir/$soname.def $libobjs $deplibs 
$compiler_flags -o $output_objdir/$soname $wl--enable-auto-image-base -Xlinker 
--out-implib -Xlinker $lib'
   else
_LT_TAGVAR(ld_shlibs, $1)=no
   fi
@@ -4868,9 +4868,9 @@ _LT_EOF
 
 if test yes = $supports_anon_versioning; then
   _LT_TAGVAR(archive_expsym_cmds, $1)='echo { global:  
$output_objdir/$libname.ver~
-   cat $export_symbols | sed -e s/\(.*\)/\1;/  
$output_objdir/$libname.ver~
-   echo local: *; };  $output_objdir/$libname.ver~
-   $CC '$tmp_sharedflag$tmp_addflag' $libobjs $deplibs 
$compiler_flags $wl-soname $wl$soname $wl-version-script 
$wl$output_objdir/$libname.ver -o $lib'
+cat $export_symbols | sed -e s/\(.*\)/\1;/  
$output_objdir/$libname.ver~
+echo local: *; };  $output_objdir/$libname.ver~
+$CC '$tmp_sharedflag$tmp_addflag' $libobjs $deplibs 
$compiler_flags $wl-soname $wl$soname $wl-version-script 
$wl$output_objdir/$libname.ver -o $lib'
 fi
 
case $cc_basename in
@@ -4881,9 +4881,9 @@ _LT_EOF
  _LT_TAGVAR(archive_cmds, $1)='$LD -shared $libobjs $deplibs 
$linker_flags -soname $soname -o $lib'
  if test yes = $supports_anon_versioning; then
_LT_TAGVAR(archive_expsym_cmds, $1)='echo { global:  
$output_objdir/$libname.ver~
- cat $export_symbols | sed -e s/\(.*\)/\1;/  
$output_objdir/$libname.ver~
- echo local: *; };  $output_objdir/$libname.ver~
- $LD -shared $libobjs $deplibs $linker_flags -soname $soname 
-version-script $output_objdir/$libname.ver -o $lib'
+  cat $export_symbols | sed -e s/\(.*\)/\1;/  
$output_objdir/$libname.ver~
+  echo local: *; };  $output_objdir/$libname.ver~
+  $LD -shared $libobjs $deplibs $linker_flags -soname $soname 
-version-script $output_objdir/$libname.ver -o $lib'
  fi
  ;;
esac
@@ -5163,13 +5163,13 @@ _LT_EOF
# FIXME: Setting linknames here is a bad hack.
_LT_TAGVAR(archive_cmds, $1)='$CC -o $output_objdir/$soname $libobjs 
$compiler_flags $deplibs 
-Wl,-DLL,-IMPLIB:$tool_output_objdir$libname.dll.lib~linknames='
_LT_TAGVAR(archive_expsym_cmds, $1)='if test EXPORTS = `$SED 1q 
$export_symbols`; then
-   cp $export_symbols $output_objdir/$soname.def;
-   echo $tool_output_objdir$soname.def  
$output_objdir/$soname.exp;
- else
-   $SED -e '\''s/^/-link -EXPORT:/'\''  $export_symbols  
$output_objdir/$soname.exp;
- fi~
- $CC -o $tool_output_objdir$soname $libobjs $compiler_flags $deplibs 
@$tool_output_objdir$soname.exp 
-Wl,-DLL,-IMPLIB:$tool_output_objdir$libname.dll.lib~
- linknames='
+cp $export_symbols $output_objdir/$soname.def;
+echo

[PATCH 2/2] libtool: factor out the dll .def file test and improve it

[Peter Rosin]

Resolves bug#13414. Problem reported by Erik van Pienbroek
and Martin Doucha.

build-aux/ltmain.in (func_mode_link): Factor out the test if a
given symbol file is a module-definition (.def) file into...
(func_dll_def_p): ...this function, which also improves the check.
m4/libtool.m4 (_LT_LINKER_SHLIBS, _LT_LANG_CXX_CONFIG)
cygwin, mingw, pw32, cegcc: Similarly, factor out the test if
a given symbol file is a module-definition (.def) file into...
(_LT_DLL_DEF_P): ...this macro, which also improves the check.
tests/export-def.at: New test.
Makefile.am (TESTSUITE_AT): Add above test.
NEWS: Update.
THANKS: Update.

Signed-off-by: Peter Rosin p...@lysator.liu.se

# Conflicts:
#
#   m4/libtool.m4
---
 Makefile.am |1 +
 NEWS|3 +
 THANKS  |2 +
 build-aux/ltmain.in |   19 +++-
 m4/libtool.m4   |   31 ---
 tests/export-def.at |  139 +++
 6 files changed, 186 insertions(+), 9 deletions(-)
 create mode 100755 tests/export-def.at

diff --git a/Makefile.am b/Makefile.am
index a3e3c7d..e5f3805 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -627,6 +627,7 @@ TESTSUITE_AT= tests/testsuite.at \
  tests/runpath-in-lalib.at \
  tests/static.at \
  tests/export.at \
+ tests/export-def.at \
  tests/search-path.at \
  tests/indirect_deps.at \
  tests/archive-in-archive.at \
diff --git a/NEWS b/NEWS
index c202c43..514768b 100644
--- a/NEWS
+++ b/NEWS
@@ -66,6 +66,9 @@ NEWS - list of user-visible changes between releases of GNU 
Libtool
 the Microsoft Visual C/C++ linker via the -export-symbols argument to
 the libtool script, thus matching how .def files are handled when
 using GNU tools.
+  - Recognize more variants (e.g. those starting with a LIBRARY statement)
+of module-definitions (.def) files when using them instead of a raw
+list of symbols to export.
 
 ** Important incompatible changes:
 
diff --git a/THANKS b/THANKS
index d4c1f1b..92e6dff 100644
--- a/THANKS
+++ b/THANKS
@@ -98,6 +98,7 @@
   Edouard G. Parmelan  edouard.parme...@france.ncr.com
   Erez Zadok   e...@shekel.mcl.cs.columbia.edu
   Eric Estievenart e...@via.ecp.fr
+  Erik van Pienbroek   erik-...@vanpienbroek.nl
   Ethan Malloveethan.mall...@sun.com
   Frank Ch. Eigler f...@cygnus.com
   Fred Cox sailorf...@yahoo.com
@@ -140,6 +141,7 @@
   Marcel Loose lo...@astron.nl
   Mark Ketteniskette...@phys.uva.nl
   Markus Duft  markus.d...@salomon.at
+  Martin Douchadou...@integri.cz
   Matthijs Kooijmanmatth...@stdin.nl
   Micheal E. Faenzamfae...@mitre.org
   Michael Haubenwallnermichael.haubenwall...@salomon.at
diff --git a/build-aux/ltmain.in b/build-aux/ltmain.in
index eb224e3..f0168da 100644
--- a/build-aux/ltmain.in
+++ b/build-aux/ltmain.in
@@ -1316,6 +1316,23 @@ func_convert_path_nix_to_cygwin ()
 # end func_convert_path_nix_to_cygwin
 
 
+# func_dll_def_p FILE
+# True iff FILE is a Windows DLL '.def' file.
+# Keep in sync with _LT_DLL_DEF_P in libtool.m4
+func_dll_def_p ()
+{
+  $debug_cmd
+
+  func_dll_def_p_tmp=`$SED -n \
+-e 's/^[   ]*//' \
+-e '/^\(;.*\)*$/d' \
+-e 's/^\(EXPORTS\|LIBRARY\)\([ ].*\)*$/DEF/p' \
+-e q \
+$1`
+  test DEF = $func_dll_def_p_tmp
+}
+
+
 # func_mode_compile arg...
 func_mode_compile ()
 {
@@ -7572,7 +7589,7 @@ EOF
cygwin* | mingw* | cegcc*)
  if test -n $export_symbols  test -z $export_symbols_regex; then
# exporting using user supplied symfile
-   if test EXPORTS != `$SED 1q $export_symbols`; then
+   if ! func_dll_def_p $export_symbols; then
  # and it's NOT already a .def file. Must figure out
  # which of the given symbols are data symbols and tag
  # them as such. So, trigger use of export_symbols_cmds.
diff --git a/m4/libtool.m4 b/m4/libtool.m4
index 4bc9e98..0a6c334 100644
--- a/m4/libtool.m4
+++ b/m4/libtool.m4
@@ -3530,6 +3530,21 @@ _LT_DECL([], [MANIFEST_TOOL], [1], [Manifest tool])dnl
 ])# _LT_PATH_MANIFEST_TOOL
 
 
+# _LT_DLL_DEF_P([FILE])
+# -
+# True iff FILE is a Windows DLL '.def' file.
+# Keep in sync with func_dll_def_p in the libtool script
+AC_DEFUN([_LT_DLL_DEF_P],
+[dnl
+  test DEF = `$SED -n dnl
+-e '\''s/^[[   ]]*//'\'' dnl Strip leading whitespace
+-e '\''/^\(;.*\)*$/d'\'' dnl  Delete empty lines and comments
+-e '\''s/^\(EXPORTS\|LIBRARY\)\([[ ]].*\)*$/DEF/p'\'' dnl
+-e q dnl  Only consider the first real line
+$1` dnl
+])# _LT_DLL_DEF_P
+
+
 # LT_LIB_M
 # 
 # check for math library
@@ -4782,9 +4797,9 @@ _LT_EOF
 
   if $LD --help 21 | $GREP

Re: [PATCH v4 2/2] git-version-gen: add --fallback option to use if git is not present

[Peter Rosin]

Hi Eric,

Thanks for the push!

On 2012-12-31 23:45, Eric Blake wrote:
 On 12/28/2012 03:13 PM, Peter Rosin wrote:
 When building in a git checkout, but from a system lacking git, it
 is useful to fall back to the version determined when the git
 checkout was last used from a system sporting git.

 * build-aux/git-version-gen: Add support for the new option --fallback,
 which comes into play when there is no $tarball_version_file and
 git is not working.
 
 You didn't really document how to wire up makefiles to properly inject a

I wanted to keep the patch small to evade the copyright assignment process
from stalling the changes.

 decent --fallback option into the script; but I'm at least satisfied
 that this patch in isolation doesn't break existing packages that don't
 use the --falback option, while leaving the door open for packages that
 DO want to support the use of --fallback.
 
 As I understand it, the idea is that you have a shared folder that can
 be accessed via multiple machines; on some machines, you have git, and
 can therefore do a git checkout that populates Makefile with the right
 information for use as a fallback.  On other machines you lack git but
 can see the .git directory in the shared directory; since it is still a
 development build and you never ran 'make dist', you still want to have
 the effect of a devel checkout, rather than building from a tarball, and
 if all that git was needed for can be injected from the machine that has
 git installed, then the other machine can benefit from the --falback.

Right. (one nit though, it might be the same machine that accesses the
shared folder through different means, Cygwin vs MSYS in my case, where
Cygwin has git, but not MSYS)

 I just now noticed v5, so I'll check that out before pushing anything.

Good thing that.

 I will point out that your script introduces yet another instance of a
 non-portable construct:
 
 test -z $fallback
 
 Per the Autoconf manual:
 
  Posix also says that `test ! STRING', `test -n STRING' and
  `test -z STRING' work with any string, but many shells (such as
  Solaris, AIX 3.2, UNICOS 10.0.0.6, Digital Unix 4, etc.) get
  confused if STRING looks like an operator:
 
   $ test -n =
   test: argument expected
   $ test ! -n
   test: argument expected
   $ test -z ); echo $?
   0

Sigh...

 However, this idiom is already in use elsewhere in git-version-gen, so
 it should be fixed in an independent patch.

Thanks for tidying up!

And for the record, I have now fixed the Libtool regression using this
new support.

Cheers,
Peter

[no subject]

[Peter Rosin]

 Sure thing, I also rebased them while at it...

...but forgot the script-version. v4 coming up.

Sorry for the noise.

Cheers,
Peter

[PATCH v4 1/2] maint.mk: handle missing git with more grace

[Peter Rosin]

* top/maint.mk (no-submodule-changes, public-submodule-commit): Quietly
proceed if git is not present.

Copyright-paperwork-exempt: yes
Signed-off-by: Peter Rosin p...@lysator.liu.se
---
 top/maint.mk |6 --
 1 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/top/maint.mk b/top/maint.mk
index 93c2508..28a84ae 100644
--- a/top/maint.mk
+++ b/top/maint.mk
@@ -1370,7 +1370,8 @@ endef
 
 .PHONY: no-submodule-changes
 no-submodule-changes:
-   $(AM_V_GEN)if test -d $(srcdir)/.git; then  \
+   $(AM_V_GEN)if test -d $(srcdir)/.git\
+git --version /dev/null 21; then  \
  diff=$$(cd $(srcdir)  git submodule -q foreach  \
  git diff-index --name-only HEAD)  \
|| exit 1;  \
@@ -1388,7 +1389,8 @@ submodule-checks ?= no-submodule-changes 
public-submodule-commit
 # cannot be built from a fresh clone.
 .PHONY: public-submodule-commit
 public-submodule-commit:
-   $(AM_V_GEN)if test -d $(srcdir)/.git; then  \
+   $(AM_V_GEN)if test -d $(srcdir)/.git\
+git --version /dev/null 21; then  \
  cd $(srcdir)\
  git submodule --quiet foreach \
  test '$$(git rev-parse $$sha1)'   \
-- 
1.7.9

[PATCH v4 2/2] git-version-gen: add --fallback option to use if git is not present

[Peter Rosin]

When building in a git checkout, but from a system lacking git, it
is useful to fall back to the version determined when the git
checkout was last used from a system sporting git.

* build-aux/git-version-gen: Add support for the new option --fallback,
which comes into play when there is no $tarball_version_file and
git is not working.
(scriptversion): Update.

Copyright-paperwork-exempt: yes
Signed-off-by: Peter Rosin p...@lysator.liu.se
---
 build-aux/git-version-gen |9 +++--
 1 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/build-aux/git-version-gen b/build-aux/git-version-gen
index 0fa9063..f123e24 100755
--- a/build-aux/git-version-gen
+++ b/build-aux/git-version-gen
@@ -1,6 +1,6 @@
 #!/bin/sh
 # Print a version string.
-scriptversion=2012-03-18.17; # UTC
+scriptversion=2012-10-31.13; # UTC
 
 # Copyright (C) 2007-2012 Free Software Foundation, Inc.
 #
@@ -86,6 +86,7 @@ Print a version string.
 Options:
 
--prefix   prefix of git tags (default 'v')
+   --fallback fallback version to use if \git --version\ fails
 
--help display this help and exit
--version  output version information and exit
@@ -93,12 +94,14 @@ Options:
 Running without arguments will suffice in most cases.
 
 prefix=v
+fallback=
 
 while test $# -gt 0; do
   case $1 in
 --help) echo $usage; exit 0;;
 --version) echo $version; exit 0;;
 --prefix) shift; prefix=$1;;
+--fallback) shift; fallback=$1;;
 -*)
   echo $0: Unknown option '$1'. 2
   echo $0: Try '--help' for more information. 2
@@ -184,8 +187,10 @@ then
 # Remove the g in git describe's output string, to save a byte.
 v=`echo $v | sed 's/-/./;s/\(.*\)-g/\1-/'`;
 v_from_git=1
-else
+elif test -z $fallback || git --version /dev/null 21; then
 v=UNKNOWN
+else
+v=$fallback
 fi
 
 v=`echo $v |sed s/^$prefix//`
-- 
1.7.9

[PATCH v3 2/2] git-version-gen: add --fallback option to use if git is not present

[Peter Rosin]

When building in a git checkout, but from a system lacking git, it
is useful to fall back to the version determined when the git
checkout was last used from a system sporting git.

* build-aux/git-version-gen: Add support for the new option --fallback,
which comes into play when there is no $tarball_version_file and
git is not working.
(scriptversion): Update.

Copyright-paperwork-exempt: yes
Signed-off-by: Peter Rosin p...@lysator.liu.se
---
 build-aux/git-version-gen |9 +++--
 1 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/build-aux/git-version-gen b/build-aux/git-version-gen
index 0fa9063..f123e24 100755
--- a/build-aux/git-version-gen
+++ b/build-aux/git-version-gen
@@ -1,6 +1,6 @@
 #!/bin/sh
 # Print a version string.
-scriptversion=2012-03-18.17; # UTC
+scriptversion=2012-10-31.13; # UTC
 
 # Copyright (C) 2007-2012 Free Software Foundation, Inc.
 #
@@ -86,6 +86,7 @@ Print a version string.
 Options:
 
--prefix   prefix of git tags (default 'v')
+   --fallback fallback version to use if \git --version\ fails
 
--help display this help and exit
--version  output version information and exit
@@ -93,12 +94,14 @@ Options:
 Running without arguments will suffice in most cases.
 
 prefix=v
+fallback=
 
 while test $# -gt 0; do
   case $1 in
 --help) echo $usage; exit 0;;
 --version) echo $version; exit 0;;
 --prefix) shift; prefix=$1;;
+--fallback) shift; fallback=$1;;
 -*)
   echo $0: Unknown option '$1'. 2
   echo $0: Try '--help' for more information. 2
@@ -184,8 +187,10 @@ then
 # Remove the g in git describe's output string, to save a byte.
 v=`echo $v | sed 's/-/./;s/\(.*\)-g/\1-/'`;
 v_from_git=1
-else
+elif test -z $fallback || git --version /dev/null 21; then
 v=UNKNOWN
+else
+v=$fallback
 fi
 
 v=`echo $v |sed s/^$prefix//`
-- 
1.7.9

Re: git-version-gen w/o git

[Peter Rosin]

On 2012-12-28 02:35, Paul Eggert wrote:
 On 12/27/2012 03:41 PM, Peter Rosin wrote:
 If it helps I can regenerate with your redirection fix, but I assume
 whoever commits it can fix that part easily enough. Just let me know.
 
 How about if you do that, and we give Eric and/or others a week or
 two  to comment, and if there's no objection then we can
 fold it into gnulib?

Sure thing, I also rebased them while at it...

Cheers,
Peter

Re: git-version-gen w/o git

[Peter Rosin]

 Sure thing, I also rebased them while at it...
 
 ...but forgot the script-version. v4 coming up.
 
 Sorry for the noise.

But sent the wrong patch anyway and also omitted the subject.

*blush*

v5 coming up.

Cheers,
Peter

[PATCH v5 1/2] maint.mk: handle missing git with more grace

[Peter Rosin]

* top/maint.mk (no-submodule-changes, public-submodule-commit): Quietly
proceed if git is not present.

Copyright-paperwork-exempt: yes
Signed-off-by: Peter Rosin p...@lysator.liu.se
---
 top/maint.mk |6 --
 1 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/top/maint.mk b/top/maint.mk
index 93c2508..28a84ae 100644
--- a/top/maint.mk
+++ b/top/maint.mk
@@ -1370,7 +1370,8 @@ endef
 
 .PHONY: no-submodule-changes
 no-submodule-changes:
-   $(AM_V_GEN)if test -d $(srcdir)/.git; then  \
+   $(AM_V_GEN)if test -d $(srcdir)/.git\
+git --version /dev/null 21; then  \
  diff=$$(cd $(srcdir)  git submodule -q foreach  \
  git diff-index --name-only HEAD)  \
|| exit 1;  \
@@ -1388,7 +1389,8 @@ submodule-checks ?= no-submodule-changes 
public-submodule-commit
 # cannot be built from a fresh clone.
 .PHONY: public-submodule-commit
 public-submodule-commit:
-   $(AM_V_GEN)if test -d $(srcdir)/.git; then  \
+   $(AM_V_GEN)if test -d $(srcdir)/.git\
+git --version /dev/null 21; then  \
  cd $(srcdir)\
  git submodule --quiet foreach \
  test '$$(git rev-parse $$sha1)'   \
-- 
1.7.9

[PATCH v5 2/2] git-version-gen: add --fallback option to use if git is not present

[Peter Rosin]

When building in a git checkout, but from a system lacking git, it
is useful to fall back to the version determined when the git
checkout was last used from a system sporting git.

* build-aux/git-version-gen: Add support for the new option --fallback,
which comes into play when there is no $tarball_version_file and
git is not working.
(scriptversion): Update.

Copyright-paperwork-exempt: yes
Signed-off-by: Peter Rosin p...@lysator.liu.se
---
 build-aux/git-version-gen |9 +++--
 1 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/build-aux/git-version-gen b/build-aux/git-version-gen
index 0fa9063..5f3289e 100755
--- a/build-aux/git-version-gen
+++ b/build-aux/git-version-gen
@@ -1,6 +1,6 @@
 #!/bin/sh
 # Print a version string.
-scriptversion=2012-03-18.17; # UTC
+scriptversion=2012-12-28.23; # UTC
 
 # Copyright (C) 2007-2012 Free Software Foundation, Inc.
 #
@@ -86,6 +86,7 @@ Print a version string.
 Options:
 
--prefix   prefix of git tags (default 'v')
+   --fallback fallback version to use if \git --version\ fails
 
--help display this help and exit
--version  output version information and exit
@@ -93,12 +94,14 @@ Options:
 Running without arguments will suffice in most cases.
 
 prefix=v
+fallback=
 
 while test $# -gt 0; do
   case $1 in
 --help) echo $usage; exit 0;;
 --version) echo $version; exit 0;;
 --prefix) shift; prefix=$1;;
+--fallback) shift; fallback=$1;;
 -*)
   echo $0: Unknown option '$1'. 2
   echo $0: Try '--help' for more information. 2
@@ -184,8 +187,10 @@ then
 # Remove the g in git describe's output string, to save a byte.
 v=`echo $v | sed 's/-/./;s/\(.*\)-g/\1-/'`;
 v_from_git=1
-else
+elif test -z $fallback || git --version /dev/null 21; then
 v=UNKNOWN
+else
+v=$fallback
 fi
 
 v=`echo $v |sed s/^$prefix//`
-- 
1.7.9

Re: git-version-gen w/o git

[Peter Rosin]

On 2012-12-24 03:05, Paul Eggert wrote:
 On 11/29/2012 11:12 PM, Peter Rosin wrote:
 This seems to be stalled because of a misconception. Can I please get
 a second opinion? Please?
 
 I'm afraid I don't understand the problem well enough to offer
 an opinion -- maybe it's because I don't understand the desire
 to do maintenance without git -- but I did look over the patch
 and noticed that it used  /dev/null, which isn't portable;
 it should use /dev/null 21.

I would like to be able to use a git checkout from a system that lacks git.
In my case the system which lack git is MSYS. Sure, there is
MSYS-git, but that is a misnomer as it does not provide an MSYS git
version at all. It instead provides a MinGW git, with a bundled MSYS
installation, but that's not at all the same thing.

So, since there is no MSYS version of git, my preference is to use the
Cygwin git to work with various projects, e.g. Libtool. But Cygwin is
slow to work with, so I prefer to not do the make dist dance from
Cygwin in order to check if whatever changes I'm doing at the moment
work for the MSYS case. It is just much faster to make with a VPATH
build from MSYS, but then that has to work in a git checkout but with
git missing.

This used to work nicely for me until Gary overhauled the Libtool
build machinery to do things the Gnulib way, and my proposed changes
fixes the Libtool regression (quotes here since after all it is very
much an edge case and not all that much to quarrel about).

Erik stated that half the changes looked useful and made sense. The
rest was already possible to do according to him, but that's just plain
wrong. The .tarball-version hook in the git-version-gen script can't be
used as that screws up the git checkout from the Cygwin side of things.
When I pointed this out there has been two months of silence until your
response.

Libtool remains regressed and a PITA to work with for me until this is
fixed. I'm a bit frustrated since the changes are tiny and non-intrusive,
at least in my opinion.

If it helps I can regenerate with your redirection fix, but I assume
whoever commits it can fix that part easily enough. Just let me know.

Cheers,
Peter

Re: git-version-gen w/o git

[Peter Rosin]

On 2012-11-13 15:32, Peter Rosin wrote:
 On 2012-10-18 15:56, Peter Rosin wrote:
 Hi Eric!

 On 2012-10-18 15:02, Eric Blake wrote:
 [adding-gnulib]

 I'm not subscribed, please (continue to) keep me in CC.

 On 10/18/2012 06:50 AM, Peter Rosin wrote:
 Hi!

 I used to use a libtool git checkout from a platform that lacks
 git [MSYS], but that broke at some point. I would like something
 like the below to unbreak my work flow.

 Please?

 Cheers,
 Peter

 diff --git a/Makefile.am b/Makefile.am
 index 176325c..3bcb419 100644
 --- a/Makefile.am
 +++ b/Makefile.am
 @@ -46,7 +46,7 @@ EXTRA_LTLIBRARIES=
  # Using `cd' in backquotes may print the directory name, use this instead:
  lt__cd= CDPATH=$${ZSH_VERSION+.}$(PATH_SEPARATOR)  cd
  
 -git_version_gen = '$(SHELL)' '$(aux_dir)/git-version-gen' 
 '.tarball-version'
 +git_version_gen = '$(SHELL)' '$(aux_dir)/git-version-gen' '--fallback' 
 '$(VERSION)' '.tarball-version'

 I'm not sure that makes sense - git-version-gen is ALREADY supposed to
 use the contents of .tarball-version as the fallback version.

 No, .tarball-version is the primary source, or the fallfront as
 some call it :-) Once you create that file you will no longer
 attempt to run git, even if you switch back to the platform that
 created the git checkout in the first place.
 
 Ping for these patches:
 http://lists.gnu.org/archive/html/bug-gnulib/2012-10/msg00123.html
 http://lists.gnu.org/archive/html/bug-gnulib/2012-10/msg00124.html

Ping again.

This seems to be stalled because of a misconception. Can I please get
a second opinion? Please?

Cheers,
Peter

Preloading import libraries with MSVC

[Peter Rosin]

Hi!

As discussed earlier[1], there are problems with preloading import
libraries when using Microsoft Visual C/C++. This series is a
polished version of the previously posted rough cut. However, the
first two patches are largely unrelated to the topic, but they
help visualize what the meat in the third patch is all about. So,
I guess they are related after all, which is why I posted them
as a series. :-)

This version will not create an @INIT@ symbol in the preloader
table unless one is neaded, i.e. an actual data import item
is needed to trigger the creation of the lt_syminit function
and the fake @INIT@ symbol providing its address.

Also, the cost in preopen.c is neglectable, as the loops from
the proof of concept first draft are gone.

With:

.../configure \
CC=`pwd`/build-aux/compile cl -nologo \
CFLAGS=-MD -Zi -EHsc \
CXX=`pwd`/build-aux/compile cl -nologo \
CXXFLAGS=-MD -Zi -EHsc \
NM=dumpbin -symbols -headers \
LD=link \
STRIP=: \
AR=`pwd`/build-aux/ar-lib lib \
RANLIB=: \
F77=no FC=no GCJ=no

from MSYS with Microsoft Visual C/C++ 2010 on $PATH, I get:

## - ##
## Test results. ##
## - ##

139 tests behaved as expected.
29 tests were skipped.

So, all failures are fixed. The testsuite is also clean on Cygwin
and MinGW (which makes me confident that the added special caseing
doesn't mess up systems that don't make use of them).

Is it unintrusive enough? Ok to push?

(confession: I did a few last minute trivial changes just before
posting which (drumroll) shouldn't affect things. Anyway, the testsuite
is part way through with thouse changes and the patch has been somewhat
exercised so it is looking good, but I will naturally post a followup
if anything untoward surfaces)

Cheers,
Peter

[1] http://lists.gnu.org/archive/html/libtool-patches/2012-10/msg00055.html

[PATCH 2/3] libtool: unify the global symbol transformations

[Peter Rosin]

Since it is safe for $lt_cv_sys_global_symbol_to_cdecl to match
with a simple /^T .* .*$/ type expression, it is ok for the other
transformations as well.  At least if you require at least one
$symcode at the start of the line, so that the just generated output
doesn't match the next sed expression.

* m4/libtool.m4 (_LT_CMD_GLOBAL_SYMBOLS): Unify the matching expressions
in the sed programs that transform the extracted symbol lines.

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

diff --git a/m4/libtool.m4 b/m4/libtool.m4
index 79a4222..e59e0fb 100644
--- a/m4/libtool.m4
+++ b/m4/libtool.m4
@@ -3654,19 +3654,19 @@ esac
 # so use this general approach.
 lt_cv_sys_global_symbol_to_cdecl=sed -n\
  -e 's/^T .* \(.*\)$/extern int \1();/p'\
- -e 's/^$symcode* .* \(.*\)$/extern char \1;/p'
+ -e 's/^$symcode$symcode* .* \(.*\)$/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\
- -e 's/^: \([[^ ]]*\)[[ ]]*$/  {1\\\, (void *) 0},/p'\
- -e 's/^$symcode* \([[^ ]]*\) \([[^ ]]*\)$/  {\\2\, (void *) \\2},/p'
+ -e 's/^: \(.*\) .*$/  {\\1\, (void *) 0},/p'\
+ -e 's/^$symcode$symcode* .* \(.*\)$/  {\\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\
- -e 's/^: \([[^ ]]*\)[[ ]]*$/  {1\\\, (void *) 0},/p'\
- -e 's/^$symcode* \([[^ ]]*\) \(lib[[^ ]]*\)$/  {\\2\, (void *) \\2},/p'\
- -e 's/^$symcode* \([[^ ]]*\) \([[^ ]]*\)$/  {\lib\2\, (void *) \\2},/p'
+ -e 's/^: \(.*\) .*$/  {\\1\, (void *) 0},/p'\
+ -e 's/^$symcode$symcode* .* \(lib.*\)$/  {\\1\, (void *) \\1},/p'\
+ -e 's/^$symcode$symcode* .* \(.*\)$/  {\lib\1\, (void *) \\1},/p'
 
 # Handle CRLF in mingw tool chain
 opt_cr=
@@ -3771,7 +3771,7 @@ lt__PROGRAM__LTX_preloaded_symbols[[]] =
 {
   { @PROGRAM@, (void *) 0 },
 _LT_EOF
- $SED s/^$symcode$symcode* \(.*\) \(.*\)$/  {\\2\, (void *) 
\\2},/  $nlist | $GREP -v main  conftest.$ac_ext
+ $SED s/^$symcode$symcode* .* \(.*\)$/  {\\1\, (void *) \\1},/  
$nlist | $GREP -v main  conftest.$ac_ext
  cat \_LT_EOF  conftest.$ac_ext
   {0, (void *) 0}
 };
-- 
1.7.9

[PATCH 1/3] libtool: break up long lines

[Peter Rosin]

* m4/libtool.m4 (_LT_CMD_GLOBAL_SYMBOLS): Break up long lines when
assigning the sed scripts that transform the extracted symbol lines.

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

diff --git a/m4/libtool.m4 b/m4/libtool.m4
index 37f7d7c..79a4222 100644
--- a/m4/libtool.m4
+++ b/m4/libtool.m4
@@ -3652,11 +3652,21 @@ esac
 # 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.
-lt_cv_sys_global_symbol_to_cdecl=sed -n -e 's/^T .* \(.*\)$/extern int 
\1();/p' -e 's/^$symcode* .* \(.*\)$/extern char \1;/p'
+lt_cv_sys_global_symbol_to_cdecl=sed -n\
+ -e 's/^T .* \(.*\)$/extern int \1();/p'\
+ -e 's/^$symcode* .* \(.*\)$/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 -e 's/^: \([[^ ]]*\)[[ ]]*$/ 
 {1\\\, (void *) 0},/p' -e 's/^$symcode* \([[^ ]]*\) \([[^ ]]*\)$/  
{\\2\, (void *) \\2},/p'
-lt_cv_sys_global_symbol_to_c_name_address_lib_prefix=sed -n -e 's/^: \([[^ 
]]*\)[[ ]]*$/  {1\\\, (void *) 0},/p' -e 's/^$symcode* \([[^ ]]*\) 
\(lib[[^ ]]*\)$/  {\\2\, (void *) \\2},/p' -e 's/^$symcode* \([[^ ]]*\) 
\([[^ ]]*\)$/  {\lib\2\, (void *) \\2},/p'
+lt_cv_sys_global_symbol_to_c_name_address=sed -n\
+ -e 's/^: \([[^ ]]*\)[[ ]]*$/  {1\\\, (void *) 0},/p'\
+ -e 's/^$symcode* \([[^ ]]*\) \([[^ ]]*\)$/  {\\2\, (void *) \\2},/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\
+ -e 's/^: \([[^ ]]*\)[[ ]]*$/  {1\\\, (void *) 0},/p'\
+ -e 's/^$symcode* \([[^ ]]*\) \(lib[[^ ]]*\)$/  {\\2\, (void *) \\2},/p'\
+ -e 's/^$symcode* \([[^ ]]*\) \([[^ ]]*\)$/  {\lib\2\, (void *) \\2},/p'
 
 # Handle CRLF in mingw tool chain
 opt_cr=
-- 
1.7.9

[PATCH 3/3] libtool: add @INIT@ to the preloader, for data imports on Windows

[Peter Rosin]

* m4/libtool.m4 (_LT_CMD_GLOBAL_SYMBOLS) [dumpbin]: Adjust
lt_cv_sys_global_symbol_to_cdecl so that it declares imported
data symbols as __declspec(dllimport). Adjust
lt_cv_sys_global_symbol_to_c_name_address and
lt_cv_sys_global_symbol_to_c_name_address_lib_prefix so that they
fill in (void*) 0 for imported data symbols. Add new
lt_cv_sys_global_symbol_to_import which finds imported data
symbols if non-empty and export this variable to the libtool script
in the global_symbol_to_import variable. Adjust
lt_cv_sys_global_symbol_pipe so that data imports can be located.
* build-aux/ltmain.in (func_generate_dlsyms): When data imports
are present, as indicated by global_symbol_to_import, generate
a relocation function lt_syminit that fills in the addresses
of data imports at runtime and point to the new function with a
new virtual @INIT@ entry in the symbol list.
* libltdl/loaders/preopen.c (add_symlist): Look for the virtual
@INIT@ symbol (i.e. lt_syminit) and call it.
(vm_sym): Step past the @INIT@ symbol, if present.
* tests/demo.at (dlmain.c): Call the @INIT@ symbol, if present.
* NEWS: Update.

Signed-off-by: Peter Rosin p...@lysator.liu.se
---
 NEWS  |2 ++
 build-aux/ltmain.in   |   32 
 libltdl/loaders/preopen.c |   12 
 m4/libtool.m4 |   28 +---
 tests/demo.at |2 ++
 5 files changed, 69 insertions(+), 7 deletions(-)

diff --git a/NEWS b/NEWS
index 081e82f..bb33202 100644
--- a/NEWS
+++ b/NEWS
@@ -60,6 +60,8 @@ NEWS - list of user-visible changes between releases of GNU 
Libtool
 in import libraries using the -headers option of dumpbin. Also fix a
 bug in the dumpbin wrapper which could lead to broken symbol listings
 in some corner cases.
+  - Use the improved Microsoft dumpbin support to mend preloading of
+import libraries for Microsoft Visual C/C++.
 
 ** Important incompatible changes:
 
diff --git a/build-aux/ltmain.in b/build-aux/ltmain.in
index 6151ee9..9e790db 100644
--- a/build-aux/ltmain.in
+++ b/build-aux/ltmain.in
@@ -2798,6 +2798,11 @@ extern \C\ {
echo '/* NONE */'  $output_objdir/$my_dlsyms
  fi
 
+ func_show_eval '$RM ${nlist}I'
+ if test -n $global_symbol_to_import; then
+   eval $global_symbol_to_import'  $nlistS  $nlistI'
+ fi
+
  echo  $output_objdir/$my_dlsyms \
 
 /* The mapping between symbol names and symbols.  */
@@ -2806,11 +2811,30 @@ typedef struct {
   void *address;
 } lt_dlsymlist;
 extern LT_DLSYM_CONST lt_dlsymlist
-lt_${my_prefix}_LTX_preloaded_symbols[];
+lt_${my_prefix}_LTX_preloaded_symbols[];\
+
+
+ if test -s $nlistI; then
+   echo  $output_objdir/$my_dlsyms \
+static void lt_syminit(void)
+{
+  LT_DLSYM_CONST lt_dlsymlist *symbol = lt_${my_prefix}_LTX_preloaded_symbols;
+  for (; symbol-name; ++symbol)
+{
+   $SED 's/.*/  if (!strcmp (symbol-name, \\)) symbol-address 
= (void *) \;/'  $nlistI  $output_objdir/$my_dlsyms
+   echo  $output_objdir/$my_dlsyms \
+}
+}
+ fi
+ echo  $output_objdir/$my_dlsyms \
 LT_DLSYM_CONST lt_dlsymlist
 lt_${my_prefix}_LTX_preloaded_symbols[] =
-{\
-  { \$my_originator\, (void *) 0 },
+{ {\$my_originator\, (void *) 0},
+
+ if test -s $nlistI; then
+   echo  $output_objdir/$my_dlsyms \
+  {\@INIT@\, (void *) lt_syminit},
+ fi
 
  case $need_lib_prefix in
  no)
@@ -2869,7 +2893,7 @@ static const void *lt_preloaded_setup() {
func_show_eval '(cd $output_objdir  $LTCC$symtab_cflags 
-c$no_builtin_flag$pic_flag_for_symtable $my_dlsyms)' 'exit $?'
 
# Clean up the generated files.
-   func_show_eval '$RM $output_objdir/$my_dlsyms $nlist ${nlist}S 
${nlist}T'
+   func_show_eval '$RM $output_objdir/$my_dlsyms $nlist ${nlist}S 
${nlist}T ${nlist}I'
 
# Transform the symbol file into the correct name.
symfileobj=$output_objdir/${my_outputname}S.$objext
diff --git a/libltdl/loaders/preopen.c b/libltdl/loaders/preopen.c
index 1670085..5c1bd55 100644
--- a/libltdl/loaders/preopen.c
+++ b/libltdl/loaders/preopen.c
@@ -210,6 +210,11 @@ vm_sym (lt_user_data LT__UNUSED loader_data, lt_module 
module, const char *name)
 {
   lt_dlsymlist*symbol = (lt_dlsymlist*) module;
 
+  if (symbol[1].name  STREQ (symbol[1].name, @INIT@))
+{
+  symbol++;/* Skip optional init entry. */
+}
+
   symbol +=2;  /* Skip header (originator then libname). */
 
   while (symbol-name)
@@ -273,6 +278,13 @@ add_symlist (const lt_dlsymlist *symlist)
  tmp-symlist = symlist;
  tmp-next = preloaded_symlists;
  preloaded_symlists = tmp;
+
+ if (symlist[1].name  STREQ (symlist[1].name, @INIT@))
+   {
+ void (*init_symlist)(void);
+ *(void **)(init_symlist) = symlist[1].address;
+ (*init_symlist

[PATCH 1/2] maint.mk: handle missing git with more grace

[Peter Rosin]

* top/maint.mk (no-submodule-changes, public-submodule-commit): Quietly
proceed if git is not present.

Copyright-paperwork-exempt: yes
Signed-off-by: Peter Rosin p...@lysator.liu.se
---
 top/maint.mk |6 --
 1 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/top/maint.mk b/top/maint.mk
index ea44ece..8afac72 100644
--- a/top/maint.mk
+++ b/top/maint.mk
@@ -1370,7 +1370,8 @@ endef
 
 .PHONY: no-submodule-changes
 no-submodule-changes:
-   $(AM_V_GEN)if test -d $(srcdir)/.git; then  \
+   $(AM_V_GEN)if test -d $(srcdir)/.git\
+git --version  /dev/null; then \
  diff=$$(cd $(srcdir)  git submodule -q foreach  \
  git diff-index --name-only HEAD)  \
|| exit 1;  \
@@ -1388,7 +1389,8 @@ submodule-checks ?= no-submodule-changes 
public-submodule-commit
 # cannot be built from a fresh clone.
 .PHONY: public-submodule-commit
 public-submodule-commit:
-   $(AM_V_GEN)if test -d $(srcdir)/.git; then  \
+   $(AM_V_GEN)if test -d $(srcdir)/.git\
+git --version  /dev/null; then \
  cd $(srcdir)\
  git submodule --quiet foreach test '$$(git rev-parse $$sha1)' \
  = '$$(git merge-base origin $$sha1)'  \
-- 
1.7.9

[PATCH 2/2] git-version-gen: add --fallback option to use if git is not present

[Peter Rosin]

When building in a git checkout, but from a system lacking git, it
is useful to fall back to the version determined when the git
checkout was last used from a system sporting git.

* build-aux/git-version-gen: Add support for the new option --fallback,
which comes into play when there is no $tarball_version_file and
git is not working.
(scriptversion): Update.

Copyright-paperwork-exempt: yes
Signed-off-by: Peter Rosin p...@lysator.liu.se
---
 build-aux/git-version-gen |9 +++--
 1 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/build-aux/git-version-gen b/build-aux/git-version-gen
index 0fa9063..d85a126 100755
--- a/build-aux/git-version-gen
+++ b/build-aux/git-version-gen
@@ -1,6 +1,6 @@
 #!/bin/sh
 # Print a version string.
-scriptversion=2012-03-18.17; # UTC
+scriptversion=2012-10-31.13; # UTC
 
 # Copyright (C) 2007-2012 Free Software Foundation, Inc.
 #
@@ -86,6 +86,7 @@ Print a version string.
 Options:
 
--prefix   prefix of git tags (default 'v')
+   --fallback fallback version to use if \git --version\ fails
 
--help display this help and exit
--version  output version information and exit
@@ -93,12 +94,14 @@ Options:
 Running without arguments will suffice in most cases.
 
 prefix=v
+fallback=
 
 while test $# -gt 0; do
   case $1 in
 --help) echo $usage; exit 0;;
 --version) echo $version; exit 0;;
 --prefix) shift; prefix=$1;;
+--fallback) shift; fallback=$1;;
 -*)
   echo $0: Unknown option '$1'. 2
   echo $0: Try '--help' for more information. 2
@@ -184,8 +187,10 @@ then
 # Remove the g in git describe's output string, to save a byte.
 v=`echo $v | sed 's/-/./;s/\(.*\)-g/\1-/'`;
 v_from_git=1
-else
+elif test -z $fallback || git --version  /dev/null; then
 v=UNKNOWN
+else
+v=$fallback
 fi
 
 v=`echo $v |sed s/^$prefix//`
-- 
1.7.9

Re: [RFC] Fix libltdl preloader issues with MSVC

[Peter Rosin]

Hi Gary,

On 2012-10-20 07:26, Gary V. Vaughan wrote:
 Hi Peter,
 
 On Oct 20, 2012, at 4:06 AM, Peter Rosin p...@lysator.liu.se wrote:
 With the latest dumpbin work in place, libtool starts to add
 symbols from import libraries to the generated fooS.c files
 in func_generate_dlsyms, as needed by the preloader. And then
 the next problem naturally rears its head. This time it is
 the age-old data exports problem responsible for code such
 as this (in demo.at):

 else if (STREQ (nothing, name))
 #ifndef _WIN32
  /* In an ideal world we could do this... */
  pnothing = (int*)s-address;
 #else /* !_WIN32 */
  /* In an ideal world a shared lib would be able to export data */
  pnothing = (int*)nothing;
 #endif

 I.e., demo.at isn't even trying to use the data symbol from the
 preloader, it just picks data up directly using the import
 library on Windows. Which is of course cheating and circumvents
 the API etc etc. However, MinGW has long supported pseudo-relocs
 and anto-import and the Ideal world case should work just fine
 with gcc even on _WIN32. But not with MSVC, which fails to link
 since data symbols from import libraries are not declared
 __declspec(dllimport).
 
 That's because demo stems from the original test code that Gord
 wrote over 15 years ago alongside the embryonic preloading
 implementation, all before the current API was available! :)
 
 Having said that, it's kinda nice to have this test of the low-level
 structure of preloaded library data, although calling it demo might
 seem like we're still encouraging folk to use preloaded libraries
 this way :(  If you feel inclined to move the existing low-level tests
 aside and rename them to something less inviting, and then rewrite
 the demo tests to actually use the API that would be great for our
 test coverage too!

Yes, I was kind of surprised that evidently the most involved preloader
test was demo. I thought that libltdl basically worked with MSVC,
as long as you took care to apply the correct #ifdef madness. But that
proved very wrong when you moved demo/ to demo.at and hardened it
ever so slightly...

 Example from demo.at:

 helldl.exeS.obj : error LNK2001: unresolved external symbol _nothing

 Fixing that, and making data symbols __declspec(dllimport) is
 however not the entire solution, as that yields:

 helldl.exeS.c(47) : error C2099: initializer is not a constant

 during compilation instead.

 The underlying problem is that MSVC does not have pseudo-relocs.
 
 More hoops to jump through at the Microsoft circus.  Hurray!

Ain't it fun? :-/

 So, this patch adds an @INIT@ entry to the preloader symbol
 table, with the address of a function that is intended to do the
 relocations of data items from user-provided code instead of
 relying on the tools. This function is then filled with
 relocation code for MSVC, but left empty everywhere else
 where it is not needed.

 This is clearly not a finalized patch (it's actually pretty
 rough), it's just proof of concept. I have e.g. not optimized
 it, but it is clearly possibly to set the @INIT@ address to
 NULL and don't call @INIT@ at all in non-MSVC cases. It should
 also not be necessary to relocate data symbols from static
 libraries from user code, and it should be possible to add a
 done variable to the relocation function, so that it only
 does the work once.

 What I'm looking for is feedback. Is it acceptable to add a
 new virtual @INIT@ entry like this?  I.e. is this approach
 workable or should I just drop it?
 
 I have no objections, except perhaps that it would be good to check
 that the ABI doesn't stop pre-patch libltdl from preloading libraries
 built with post-patch libtool.  But that's likely overly pedantic of me,
 since I don't think anyone is likely to preload libraries built from a
 different package (potentially using different libtool versions)... but
 if it's easy to be compatible, we might as well do that.

Building the actual library has not changed one bit, only the
preloading glue, so as long as the new glue is used I don't expect
any trouble. I didn't even stop to think that it could be a
problem...

 I can't think of any other use for @INIT@ than beating MSVC into
 submission, but as long as you can do the final implementation
 cleanly enough that it doesn't force all the well behaved platforms
 to carry around dead weight for MSVC (eg not adding @INIT@ to
 the symbol list when it's not going to be used), and that we can keep
 everything nicely separated so that people who don't need to
 understand it to contribute in other areas can easily skip past... then,
 sure, go right ahead :)

Good, I'll post an updated patch for review when I have applied
some polish. But not this week, as I'm traveling...

Cheers,
Peter

[RFC] Fix libltdl preloader issues with MSVC

[Peter Rosin]

() {
  return lt__PROGRAM__LTX_preloaded_symbols;
}
#endif

#ifdef __cplusplus
}
#endif
--8


Cheers,
Peter
From 3e840b158f7a9949457273ec070f35ab03b04ade Mon Sep 17 00:00:00 2001
From: Peter Rosin p...@lysator.liu.se
Date: Fri, 19 Oct 2012 22:49:56 +0200
Subject: [PATCH] libtool: add @INIT@ to the preloader, for data imports on
 Windows

* build-aux/ltmain.in (func_generate_dlsyms) [MSVC]: Mark all
data symbols __declspec(dllimport) and handle static libraries
and import libraries equivalently. Generate a relocation function
lt_syminit that fills in the addresses of data items and point it
out with a new virtual @INIT@ entry in the symbol list.
* m4/libtool.m4 (_LT_CMD_GLOBAL_SYMBOLS) [MSVC]: Adjust
lt_cv_sys_global_symbol_to_c_name_address and
lt_cv_sys_global_symbol_to_c_name_address_lib_prefix so that they
fill in (void*) 0 for data symbols which need to be relocated
at runtime by the above lt_syminit.
* libltdl/loaders/preopen.c (add_symlist): Look up the virtual
@INIT@ symbol (i.e. lt_syminit) and call it if non-zero.
(vm_sym, lt_dlpreload_open): Step past the @INIT@ symbol.
* tests/demo.at (dlmain.c): Call the @INIT@ symbol if non-zero.
---
 build-aux/ltmain.in   |   26 +++---
 libltdl/loaders/preopen.c |   22 --
 m4/libtool.m4 |2 ++
 tests/demo.at |2 ++
 4 files changed, 47 insertions(+), 5 deletions(-)

diff --git a/build-aux/ltmain.in b/build-aux/ltmain.in
index ed4a4b1..a153df0 100644
--- a/build-aux/ltmain.in
+++ b/build-aux/ltmain.in
@@ -2659,6 +2659,11 @@ extern \C\ {
 #else
 # define LT_DLSYM_CONST const
 #endif
+#if defined _WIN32  defined _MSC_VER
+#define LT_DLSYM_DATA extern __declspec(dllimport)
+#else
+#define LT_DLSYM_DATA extern
+#endif
 
 /* External symbol declarations for the compiler. */\
 
@@ -2793,7 +2798,7 @@ extern \C\ {
 	  fi
 
 	  if test -f $nlistS; then
-	eval $global_symbol_to_cdecl'  $nlistS  $output_objdir/$my_dlsyms'
+	eval $global_symbol_to_cdecl'  $nlistS' | $SED 's/^extern char /LT_DLSYM_DATA char /'  $output_objdir/$my_dlsyms
 	  else
 	echo '/* NONE */'  $output_objdir/$my_dlsyms
 	  fi
@@ -2807,10 +2812,25 @@ typedef struct {
 } lt_dlsymlist;
 extern LT_DLSYM_CONST lt_dlsymlist
 lt_${my_prefix}_LTX_preloaded_symbols[];
+static void lt_syminit(void)
+{
+#if defined _WIN32  defined _MSC_VER
+	LT_DLSYM_CONST lt_dlsymlist *symbol = lt_${my_prefix}_LTX_preloaded_symbols;
+	  for (; symbol-name; ++symbol)
+	{\
+
+	  if test -f $nlistS; then
+	eval $global_symbol_to_cdecl'  $nlistS' | $SED -n 's/extern char \([^;]*\).*/if (!strcmp (symbol-name, \\1\)) symbol-address = (void *) \\1;/p'  $output_objdir/$my_dlsyms
+	  fi
+
+	  echo  $output_objdir/$my_dlsyms \
+	}
+#endif
+}
 LT_DLSYM_CONST lt_dlsymlist
 lt_${my_prefix}_LTX_preloaded_symbols[] =
-{\
-  { \$my_originator\, (void *) 0 },
+{ {\$my_originator\, (void *) 0},
+  {\@INIT@\, (void *) lt_syminit},
 
 	  case $need_lib_prefix in
 	  no)
diff --git a/libltdl/loaders/preopen.c b/libltdl/loaders/preopen.c
index 1670085..432f552 100644
--- a/libltdl/loaders/preopen.c
+++ b/libltdl/loaders/preopen.c
@@ -210,7 +210,7 @@ vm_sym (lt_user_data LT__UNUSED loader_data, lt_module module, const char *name)
 {
   lt_dlsymlist	   *symbol = (lt_dlsymlist*) module;
 
-  symbol +=2;			/* Skip header (originator then libname). */
+  symbol +=3;			/* Skip header (originator, init then libname). */
 
   while (symbol-name)
 {
@@ -270,9 +270,25 @@ add_symlist (const lt_dlsymlist *symlist)
 
   if (tmp)
 	{
+	  const lt_dlsymlist *symbol;
+
 	  tmp-symlist = symlist;
 	  tmp-next = preloaded_symlists;
 	  preloaded_symlists = tmp;
+
+	  for (symbol = symlist; symbol-name; ++symbol)
+	{
+	  if (STREQ (symbol-name, @INIT@))
+		{
+		  if (symbol-address)
+		{
+		  void (*init_symlist)(void);
+		  *(void **)(init_symlist) = symbol-address;
+		  init_symlist();
+		}
+		  break;
+		}
+	}
 	}
   else
 	{
@@ -345,7 +361,9 @@ lt_dlpreload_open (const char *originator, lt_dlpreload_callback_func *func)
 	  ++found;
 
 	  /* ...load the symbols per source compilation unit:
-	 (we preincrement the index to skip over the originator entry)  */
+	 (we increment the index once to skip over the originator entry
+	 and then preincrement to also skip the init entry)  */
+	  ++idx;
 	  while ((symbol = list-symlist[++idx])-name != 0)
 	{
 	  if ((symbol-address == 0)
diff --git a/m4/libtool.m4 b/m4/libtool.m4
index c85a85f..a7c3f4f 100644
--- a/m4/libtool.m4
+++ b/m4/libtool.m4
@@ -3674,6 +3674,8 @@ for ac_symprfx in  _; do
 
   # Write the raw and C identifiers.
   if test $lt_cv_nm_interface = MS dumpbin; then
+lt_cv_sys_global_symbol_to_c_name_address=sed -n -e 's/^: \([[^ ]]*\)[[ ]]*$/  {1\\\, (void *) 0},/p' -e 's/^T \([[^ ]]*\) \([[^ ]]*\)$/  {\\2\, (void *) \\2},/p' -e 's/^D \([[^ ]]*\) \([[^ ]]*\)$/  {\\2\, (void *) 0},/p

libtool: fix spelling nit

[Peter Rosin]

Hi!

I have pushed the below patch.

Cheers,
Peter

From cfcb7afd26a2c41f3dae62766002cac570417c77 Mon Sep 17 00:00:00 2001
From: Peter Rosin p...@lysator.liu.se
Date: Thu, 18 Oct 2012 14:27:10 +0200
Subject: [PATCH] libtool: fix spelling nit

* build-aux/ltmain.in (func_generate_dlsyms): Fix spelling nit.
* libltdl/libltdl/lt_system.h: Likewise.
* m4/libtool.m4 (_LT_CMD_GLOBAL_SYMBOLS): Likewise.

Signed-off-by: Peter Rosin p...@lysator.liu.se
---
 build-aux/ltmain.in |2 +-
 libltdl/libltdl/lt_system.h |2 +-
 m4/libtool.m4   |2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/build-aux/ltmain.in b/build-aux/ltmain.in
index 7ea2995..e48e45f 100644
--- a/build-aux/ltmain.in
+++ b/build-aux/ltmain.in
@@ -2652,7 +2652,7 @@ extern \C\ {
 
 /* Keep this code in sync between libtool.m4, ltmain, lt_system.h, and tests.  
*/
 #if defined _WIN32 || defined __CYGWIN__ || defined _WIN32_WCE
-/* DATA imports from DLLs on WIN32 con't be const, because runtime
+/* DATA imports from DLLs on WIN32 can't be const, because runtime
relocations are performed -- see ld's documentation on pseudo-relocs.  */
 # define LT_DLSYM_CONST
 #elif defined __osf__
diff --git a/libltdl/libltdl/lt_system.h b/libltdl/libltdl/lt_system.h
index 1a0de98..f8aa732 100644
--- a/libltdl/libltdl/lt_system.h
+++ b/libltdl/libltdl/lt_system.h
@@ -78,7 +78,7 @@ or obtained by writing to the Free Software Foundation, Inc.,
 
 /* Keep this code in sync between libtool.m4, ltmain, lt_system.h, and tests.  
*/
 #if defined _WIN32 || defined __CYGWIN__ || defined _WIN32_WCE
-/* DATA imports from DLLs on WIN32 con't be const, because runtime
+/* DATA imports from DLLs on WIN32 can't be const, because runtime
relocations are performed -- see ld's documentation on pseudo-relocs.  */
 # define LT_DLSYM_CONST
 #elif defined __osf__
diff --git a/m4/libtool.m4 b/m4/libtool.m4
index c234f16..2dac8a1 100644
--- a/m4/libtool.m4
+++ b/m4/libtool.m4
@@ -3730,7 +3730,7 @@ _LT_EOF
  cat _LT_EOF  conftest.$ac_ext
 /* Keep this code in sync between libtool.m4, ltmain, lt_system.h, and tests.  
*/
 #if defined _WIN32 || defined __CYGWIN__ || defined _WIN32_WCE
-/* DATA imports from DLLs on WIN32 con't be const, because runtime
+/* DATA imports from DLLs on WIN32 can't be const, because runtime
relocations are performed -- see ld's documentation on pseudo-relocs.  */
 # define LT@t@_DLSYM_CONST
 #elif defined __osf__
-- 
1.7.9

From cfcb7afd26a2c41f3dae62766002cac570417c77 Mon Sep 17 00:00:00 2001
From: Peter Rosin p...@lysator.liu.se
Date: Thu, 18 Oct 2012 14:27:10 +0200
Subject: [PATCH] libtool: fix spelling nit

* build-aux/ltmain.in (func_generate_dlsyms): Fix spelling nit.
* libltdl/libltdl/lt_system.h: Likewise.
* m4/libtool.m4 (_LT_CMD_GLOBAL_SYMBOLS): Likewise.

Signed-off-by: Peter Rosin p...@lysator.liu.se
---
 build-aux/ltmain.in |2 +-
 libltdl/libltdl/lt_system.h |2 +-
 m4/libtool.m4   |2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/build-aux/ltmain.in b/build-aux/ltmain.in
index 7ea2995..e48e45f 100644
--- a/build-aux/ltmain.in
+++ b/build-aux/ltmain.in
@@ -2652,7 +2652,7 @@ extern \C\ {
 
 /* Keep this code in sync between libtool.m4, ltmain, lt_system.h, and tests.  */
 #if defined _WIN32 || defined __CYGWIN__ || defined _WIN32_WCE
-/* DATA imports from DLLs on WIN32 con't be const, because runtime
+/* DATA imports from DLLs on WIN32 can't be const, because runtime
relocations are performed -- see ld's documentation on pseudo-relocs.  */
 # define LT_DLSYM_CONST
 #elif defined __osf__
diff --git a/libltdl/libltdl/lt_system.h b/libltdl/libltdl/lt_system.h
index 1a0de98..f8aa732 100644
--- a/libltdl/libltdl/lt_system.h
+++ b/libltdl/libltdl/lt_system.h
@@ -78,7 +78,7 @@ or obtained by writing to the Free Software Foundation, Inc.,
 
 /* Keep this code in sync between libtool.m4, ltmain, lt_system.h, and tests.  */
 #if defined _WIN32 || defined __CYGWIN__ || defined _WIN32_WCE
-/* DATA imports from DLLs on WIN32 con't be const, because runtime
+/* DATA imports from DLLs on WIN32 can't be const, because runtime
relocations are performed -- see ld's documentation on pseudo-relocs.  */
 # define LT_DLSYM_CONST
 #elif defined __osf__
diff --git a/m4/libtool.m4 b/m4/libtool.m4
index c234f16..2dac8a1 100644
--- a/m4/libtool.m4
+++ b/m4/libtool.m4
@@ -3730,7 +3730,7 @@ _LT_EOF
 	  cat _LT_EOF  conftest.$ac_ext
 /* Keep this code in sync between libtool.m4, ltmain, lt_system.h, and tests.  */
 #if defined _WIN32 || defined __CYGWIN__ || defined _WIN32_WCE
-/* DATA imports from DLLs on WIN32 con't be const, because runtime
+/* DATA imports from DLLs on WIN32 can't be const, because runtime
relocations are performed -- see ld's documentation on pseudo-relocs.  */
 # define LT@t@_DLSYM_CONST
 #elif defined __osf__
-- 
1.7.9

git-version-gen w/o git

[Peter Rosin]

Hi!

I used to use a libtool git checkout from a platform that lacks
git [MSYS], but that broke at some point. I would like something
like the below to unbreak my work flow.

Please?

Cheers,
Peter

diff --git a/Makefile.am b/Makefile.am
index 176325c..3bcb419 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -46,7 +46,7 @@ EXTRA_LTLIBRARIES =
 # Using `cd' in backquotes may print the directory name, use this instead:
 lt__cd = CDPATH=$${ZSH_VERSION+.}$(PATH_SEPARATOR)  cd
 
-git_version_gen = '$(SHELL)' '$(aux_dir)/git-version-gen' '.tarball-version'
+git_version_gen = '$(SHELL)' '$(aux_dir)/git-version-gen' '--fallback' 
'$(VERSION)' '.tarball-version'
 rebuild = rebuild=:; revision=`$(lt__cd) $(srcdir)  $(git_version_gen) | sed 
's|-.*$$||g'`
 
 
@@ -128,8 +128,10 @@ $(ltversion_m4): $(ltversion_in) $(dotversion)
done; \
if $$rebuild; then \
  rm -f '$@'; \
- if test -f '$(srcdir)/.serial'; then \
-   serial=`cat '$(srcdir)/.serial'`; \
+ if test -d '$(srcdir)/.git'  git --version  /dev/null; then \
+   $(git_commit_count)  '$(srcdir)/.serial'; \
+ fi; \
+ serial=`cat '$(srcdir)/.serial'`; \
  else \
serial=`$(git_commit_count)`; \
  fi; \



And then some support for that in gnulib:

--- gnulib/build-aux/git-version-gen.orig   2012-10-02 17:10:58.935840500 
+0200
+++ gnulib/build-aux/git-version-gen2012-10-18 14:41:57.45846 +0200
@@ -86,6 +86,7 @@
 Options:
 
--prefix   prefix of git tags (default 'v')
+   --fallback fallback version to use if \git --version\ fails
 
--help display this help and exit
--version  output version information and exit
@@ -93,12 +94,14 @@
 Running without arguments will suffice in most cases.
 
 prefix=v
+fallback=
 
 while test $# -gt 0; do
   case $1 in
 --help) echo $usage; exit 0;;
 --version) echo $version; exit 0;;
 --prefix) shift; prefix=$1;;
+--fallback) shift; fallback=$1;;
 -*)
   echo $0: Unknown option '$1'. 2
   echo $0: Try '--help' for more information. 2
@@ -184,8 +187,10 @@
 # Remove the g in git describe's output string, to save a byte.
 v=`echo $v | sed 's/-/./;s/\(.*\)-g/\1-/'`;
 v_from_git=1
-else
+elif test -z $fallback || git --version  /dev/null; then
 v=UNKNOWN
+else
+v=$fallback
 fi
 
 v=`echo $v |sed s/^$prefix//`
--- gnulib/top/maint.mk.orig2012-10-02 17:10:43.846614700 +0200
+++ gnulib/top/maint.mk 2012-10-18 14:41:53.433652900 +0200
@@ -1327,7 +1327,7 @@
 
 .PHONY: no-submodule-changes
 no-submodule-changes:
-   $(AM_V_GEN)if test -d $(srcdir)/.git; then  \
+   $(AM_V_GEN)if test -d $(srcdir)/.git  git --version  /dev/null; 
then \
  diff=$$(cd $(srcdir)  git submodule -q foreach  \
  git diff-index --name-only HEAD)  \
|| exit 1;  \
@@ -1345,7 +1345,7 @@
 # cannot be built from a fresh clone.
 .PHONY: public-submodule-commit
 public-submodule-commit:
-   $(AM_V_GEN)if test -d $(srcdir)/.git; then  \
+   $(AM_V_GEN)if test -d $(srcdir)/.git  git --version  /dev/null; 
then \
  cd $(srcdir)\
  git submodule --quiet foreach test '$$(git rev-parse $$sha1)' \
  = '$$(git merge-base origin $$sha1)'  \

Re: git-version-gen w/o git

[Peter Rosin]

[dropping-gnulib for this part]

On 2012-10-18 15:02, Eric Blake wrote:
 [adding-gnulib]
 
 On 10/18/2012 06:50 AM, Peter Rosin wrote:
 @@ -128,8 +128,10 @@ $(ltversion_m4): $(ltversion_in) $(dotversion)
  done; \
  if $$rebuild; then \
rm -f '$@'; \
 -  if test -f '$(srcdir)/.serial'; then \
 -serial=`cat '$(srcdir)/.serial'`; \
 +  if test -d '$(srcdir)/.git'  git --version  /dev/null; then \
 +$(git_commit_count)  '$(srcdir)/.serial'; \
 +  fi; \
 +  serial=`cat '$(srcdir)/.serial'`; \
 
 However, something like this would be useful in libtool.

That hunk was wrong, this is what I meant:

@@ -128,11 +128,10 @@ $(ltversion_m4): $(ltversion_in) $(dotversion)
done; \
if $$rebuild; then \
  rm -f '$@'; \
- if test -f '$(srcdir)/.serial'; then \
-   serial=`cat '$(srcdir)/.serial'`; \
- else \
-   serial=`$(git_commit_count)`; \
+ if test -d '$(srcdir)/.git'  git --version  /dev/null; then \
+   $(git_commit_count)  '$(srcdir)/.serial'; \
  fi; \
+ serial=`cat '$(srcdir)/.serial'`; \
  if test 0 = '$(V)'; then echo   GEN$@; \
  else echo $(bootstrap_edit) '$(ltversion_in)'  '$@'; fi; \
  $(bootstrap_edit) '$(ltversion_in)'  '$@'; \



else \
  serial=`$(git_commit_count)`; \
fi; \


Sorry for the noise.

Cheers,
Peter

Re: Windows Line Endings

[Peter Rosin]

On 2012-10-08 23:29, Roumen Petrov wrote:
 Peter Rosin wrote:
 Hi Roumen,

 On 2012-10-07 11:37, Roumen Petrov wrote:
 And now test fail in cross environment : linux for mingw host
 Thanks for the report!

 I have pushed this. Let me know if it doesn't help.
 
 No comment.

Thank you, I'm assuming it finally works for everybody.

 Ralf wrote so good code I cannot understand any Peter's  patches.
 Why you just don not use existing working fine macros ?

Please, make a useful suggestion instead of hand-waving it like
that. What working macros should I use? I also don't see where I'm
introducing any new macros, can you please point that out for me?
And Ralf must write very special code indeed if his code somehow
makes it impossible for some to read the code others write.
[Ralf, if you're reading this, I hope you understand that I don't
think that's true, you write very good code, period]


In this particular case,

LT_AT_HOST_DATA([expout],

doesn't work as it creates \r\n newlines in expout, and $EGREP futzes
the newlines on MSYS so that the standard output ends up \n, causing
the test to blow up.

AT_HOST([expout],

doesn't work as $EGREP leaves the newlines alone for Linux-MinGW
(at least that's what I deduced from your report), and then you
have \n in expout and \r\n in standard output. And the test blows up.

Either that, or I misread your And now test fail in cross
environment : linux for mingw host message. I read it as if the
test worked without my patch changing LT_AT_HOST_DATA to AT_HOST,
and that the test failed with the patch. That message made me
assume that neither LT_AT_HOST_DATA nor AT_DATA works for this
test (and the only thing different in this test is that $EGREP
is used).

So, the newlines has to be normalized after the $EGREP, or the
test has to be rewritten in a deeper way.

And, as it happens, Ralf did not write the code I'm changing here,
it was written by Gary when he thankfully eradicated the legacy
testsuite, so I'm not sure why you're dragging Ralf into this?

Cheers,
Peter

Re: [PATCH] tests: skip with-pic test when no real pic flag is used.

[Peter Rosin]

On 2012-10-07 11:59, Roumen Petrov wrote:
 Peter Rosin wrote:
 On 2012-09-19 23:02, Roumen Petrov wrote:
 What about to skip test only if DLL_EXPORT is in pic_flag ?
 Since the patch has already been pushed and it is only a test
 that may be skipped on some other platforms, I'm going to
 wait for a bit until someone can confirm if this change has in
 fact caused skips where the test used to pass.  So, not
 rushing this one...
 
 I can not understand why you expect someone to confirm.
 a) how many users use platform with PIC default ?
 b) how many users build  with libtool instead that vendor (proprietary) build 
 system ?
 c) how many users test libtool ?
 d) how many users report skipped tests if no one of the tests fail ?
e) how many users run unreleased libtools?

I wasn't *expecting* a *user* to confirm. I was *hoping* a
fellow *developer* could provide feedback.

 Anyway, the change is simple if needed:
 So push it.

Right. Pushed, with fixed quoting.

Cheers,
Peter

Re: Windows Line Endings

[Peter Rosin]

On 2012-10-06 06:32, Gary V. Vaughan wrote:
 I'm about to push these changes.  Please let me know
 whether it fixes your fortran test failures -- It'll take
 me a few more days to find the time to build a Windows test
 environment.

The fortran tests are fine now. Thanks!

Cheers,
Peter

Re: Windows Line Endings

[Peter Rosin]

On 2012-10-06 10:13, Gary V. Vaughan wrote:
 On 6 Oct 2012, at 14:05, Gary V. Vaughan g...@gnu.org wrote:
 Scratch that, on closer inspection there are a couple of thinkos and
 portable quoting errors in the original port of quote.test to Autotest.
 
 I'll push if you can confirm that it fixes the test on Windows for you,
 otherwise we'll have to wait until I have a Windows test environment to
 figure out what I'm missing.
 
 I've pushed what I think is the correct fix.  Let me know if you still
 have issues with the test.

It works just fine now, thanks!

Cheers,
Peter

Re: Windows Line Endings

[Peter Rosin]

On 2012-10-06 07:58, Gary V. Vaughan wrote:
 Hi Peter,
 
 On 6 Oct 2012, at 06:20, Peter Rosin p...@lysator.liu.se wrote:
 Over to mdemo.at. It fails on MinGW because I do not have
 any installed libltdl in MinGW. Temporarily moving the
 installed Cygwin libltdl out of the lib search path makes
 the test fail on Cygwin as well. So, I believe this is
 a generic failure.
 
 I've pushed a patch that fixes all of the above.  Pending as-yet-undiscovered
 Windows madness, I think that should allow the test to work on your test
 environments too.

That part of mdemo now works, thanks!

But that said, I'm about to push this revert of one of the line
ending fixes that was masked by this orthogonal problem.

Cheers,
Peter


From b78fd9740ef6a2ed67a1ef14e76483af784fb5f0 Mon Sep 17 00:00:00 2001
From: Peter Rosin p...@lysator.liu.se
Date: Sun, 7 Oct 2012 00:57:26 +0200
Subject: [PATCH] tests: refix line ending problems on MinGW.

In commit 22f5750, one of the hunks actually introduced
line ending problems. Revert that hunk.

* tests/mdemo.at: Use AT_DATA for expected output when the
output from compiled programs is fed through $EGREP.

Signed-off-by: Peter Rosin p...@lysator.liu.se
---
 tests/mdemo.at |3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/tests/mdemo.at b/tests/mdemo.at
index 70c5532..48b7f63 100644
--- a/tests/mdemo.at
+++ b/tests/mdemo.at
@@ -824,7 +824,8 @@ int main (int argc, char **argv)
 }
 ]])

-LT_AT_HOST_DATA([expout],
+# Not using LT_AT_HOST_DATA below, since $EGREP normalizes line endings.
+AT_DATA([expout],
 [[Welcome to GNU libtool mdemo2!
 module name: foo1
 module reference count: 1
--
1.7.9

[PATCH] tests: use dry runs in both parts of 'check link mode operation'

[Peter Rosin]

Hi!

I'm pushing this as obvious as this was how link-2.test used to
do it.

Cheers,
Peter


From 82791b3fb7043f81391bb36047f8533f4dd11b7b Mon Sep 17 00:00:00 2001
From: Peter Rosin p...@lysator.liu.se
Date: Sun, 7 Oct 2012 00:57:10 +0200
Subject: [PATCH] tests: use dry runs in both parts of 'check link mode 
operation'

MSVC exits with status 2 instead of the expected 1 when a
real link is attempted.

* tests/libtool.at (check link mode operation): Use a dry run and
expect a clean exit status instead of expecting a fail.

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

diff --git a/tests/libtool.at b/tests/libtool.at
index 4ab405c..3bcdfe5 100755
--- a/tests/libtool.at
+++ b/tests/libtool.at
@@ -192,7 +192,7 @@ pic_object=none
 non_pic_object=hell.o
 ]])

-AT_CHECK([$LIBTOOL --mode=link $CC -o something foo.o hell.lo], [1], [stdout], 
[ignore])
+AT_CHECK([$LIBTOOL -n --mode=link $CC -o something foo.o hell.lo], [0], 
[stdout], [ignore])
 AT_CHECK([$FGREP '.lo ' stdout], [1], [ignore])

 AT_CLEANUP
--
1.7.9

Re: [SCM] GNU Libtool branch, master, updated. v2.4.2-273-ge24f183

[Peter Rosin]

On 2012-10-05 13:15, Gary V. Vaughan wrote:
 This is an automated email from the git hooks/post-receive script. It was
 generated because a ref change was pushed to the repository containing
 the project GNU Libtool.

ARRRGH!

I assume this is what you referred to when you talked about some stuff
stuck in the review queue? I can dig up this thread:

http://lists.gnu.org/archive/html/libtool-patches/2011-11/msg00160.html

but from here it looks like it ended with Chuck complaining with:

http://lists.gnu.org/archive/html/libtool-patches/2011-11/msg00184.html
http://lists.gnu.org/archive/html/libtool-patches/2011-11/msg00185.html

and then you went silent. Please tell me I'm missing something?


Here's the log from one of numerous failures on MinGW:

# -*- compilation -*-
33. demo.at:381: testing link against a preloaded static library ...
libtoolize: putting auxiliary files in AC_CONFIG_AUX_DIR, `build-aux'.
libtoolize: linking file `build-aux/ltmain.sh'
libtoolize: putting macros in AC_CONFIG_MACRO_DIR, `m4'.
libtoolize: linking file `m4/libtool.m4'
libtoolize: linking file `m4/ltoptions.m4'
libtoolize: linking file `m4/ltsugar.m4'
libtoolize: linking file `m4/ltversion.m4'
libtoolize: linking file `m4/lt~obsolete.m4'
../../libtool-msvc/tests/demo.at:385: $ACLOCAL -I m4
stderr:
stdout:
../../libtool-msvc/tests/demo.at:385: $AUTOHEADER 
stderr:
stdout:
../../libtool-msvc/tests/demo.at:385: $AUTOMAKE --add-missing
stderr:
configure.ac:7: installing `build-aux/config.guess'
configure.ac:7: installing `build-aux/config.sub'
configure.ac:4: installing `build-aux/install-sh'
configure.ac:4: installing `build-aux/missing'
stdout:
../../libtool-msvc/tests/demo.at:385: $AUTOCONF 
stderr:
stdout:
../../libtool-msvc/tests/demo.at:385: : ${CONFIG_SHELL=/bin/sh}; export 
CONFIG_SHELL; $CONFIG_SHELL ./configure $configure_options 
--prefix=$prefixdir --disable-shared
stderr:
stdout:
checking for a BSD-compatible install... /bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.exe
checking for suffix of executables... .exe
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking for style of include used by make... GNU
checking dependency style of gcc... none
checking build system type... i686-pc-mingw32
checking host system type... i686-pc-mingw32
checking how to print strings... printf
checking for a sed that does not truncate output... /bin/sed
checking for grep that handles long lines and -e... /bin/grep
checking for egrep... /bin/grep -E
checking for fgrep... /bin/grep -F
checking for ld used by gcc... c:/mingw/mingw32/bin/ld.exe
checking if the linker (c:/mingw/mingw32/bin/ld.exe) is GNU ld... yes
checking for BSD- or MS-compatible name lister (nm)... /mingw/bin/nm
checking the name lister (/mingw/bin/nm) interface... BSD nm
checking whether ln -s works... no, using cp -p
checking the maximum length of command line arguments... 8192
checking how to convert i686-pc-mingw32 file names to i686-pc-mingw32 format... 
(cached) func_convert_file_msys_to_w32
checking how to convert i686-pc-mingw32 file names to toolchain format... 
(cached) func_convert_file_msys_to_w32
checking for c:/mingw/mingw32/bin/ld.exe option to reload object files... -r
checking for objdump... objdump
checking how to recognize dependent libraries... file_magic ^x86 archive 
import|^x86 DLL
checking for dlltool... dlltool
checking how to associate runtime and link libraries... 
func_cygming_dll_for_implib
checking for archiver @FILE support... @
checking for strip... strip
checking for ranlib... ranlib
checking command to parse /mingw/bin/nm output from gcc object... ok
checking for sysroot... no
checking for mt... :
checking if : is a manifest tool... no
checking how to run the C preprocessor... gcc -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking for dlfcn.h... no
checking for as... as
checking for dlltool... (cached) dlltool
checking for objdump... (cached) objdump
checking for objdir... .libs
checking if gcc supports -fno-rtti -fno-exceptions... no
checking for gcc option to produce PIC... -DDLL_EXPORT -DPIC
checking if gcc PIC flag -DDLL_EXPORT -DPIC works... yes
checking if gcc static flag -static works... yes
checking if gcc supports -c -o file.o... yes
checking if gcc supports -c -o file.o... (cached) 

Re: [SCM] GNU Libtool branch, master, updated. v2.4.2-273-ge24f183

[Peter Rosin]

 The above looks just like a classic Windows failure. I.e. a line
 ending mismatch between the expout file created by the posixy
 shell (\n) and the Win32 program (\r\n) and I would guess that
 this is a problem that caused failures for Chuck last year as
 well.
 
 I think you need to use LT_AT_HOST_DATA instead of AT_DATA, where
 appropriate.

Unfortunately, the below is not enough since LT_AT_HOST_DATA
eats whitespace (  foo - foo) which affects depdemo.at,
f77demo.at and fcdemo.at. mdemo.at also seems to have
more trouble that I need to look into...

Cheers,
Peter

diff --git a/Makefile.am b/Makefile.am
diff --git a/tests/cdemo.at b/tests/cdemo.at
index f50106c..885845c 100644
--- a/tests/cdemo.at
+++ b/tests/cdemo.at
@@ -117,7 +117,7 @@ int main ()
 }
 ]])
 
-AT_DATA([expout],
+LT_AT_HOST_DATA([expout],
 [[Welcome to GNU libtool cdemo!
 ** This is libfoo **
 hello returned: 57616
diff --git a/tests/demo.at b/tests/demo.at
index b79564a..b3d2532 100644
--- a/tests/demo.at
+++ b/tests/demo.at
@@ -339,7 +339,7 @@ int main ()
 }
 ]])
 
-AT_DATA([expout],
+LT_AT_HOST_DATA([expout],
 [[Welcome to GNU Hell!
 cos (0.0) = 1
 ** This is not GNU Hello. There is no built-in mail reader. **
@@ -901,7 +901,7 @@ int foo2 (void) {
 }
 ]])
 
-AT_DATA([expout],
+LT_AT_HOST_DATA([expout],
 [[Welcome to GNU Hell!
 cos (0.0) = 1
 foo2 cos (0.0) = 1
diff --git a/tests/depdemo.at b/tests/depdemo.at
index 3c0666b..763bae4 100644
--- a/tests/depdemo.at
+++ b/tests/depdemo.at
@@ -240,7 +240,7 @@ for i in 1 2 3 4; do
 done
 
 
-AT_DATA([expout],
+LT_AT_HOST_DATA([expout],
 [[dependencies:
 l1 (0)
 l2 (0)
diff --git a/tests/f77demo.at b/tests/f77demo.at
index 78da9a8..5978b3d 100644
--- a/tests/f77demo.at
+++ b/tests/f77demo.at
@@ -249,7 +249,7 @@ m4_define([_LT_CHECK_EXECUTE],
 # on whether it is redirected to a file or sent to stdout, so we
 # just check return status, and ignore output.
 # Advice on this weirdness from a Fortran user much appreciated!
-AT_DATA([expout],
+LT_AT_HOST_DATA([expout],
 [[ Welcome to GNU libtool Fortran demo!
  Real programmers write in FORTRAN.
  fsub called
@@ -262,7 +262,7 @@ AT_DATA([expout],
 ]])
 LT_AT_EXEC_CHECK([./fprogram], 0, [ignore])
 
-AT_DATA([expout],
+LT_AT_HOST_DATA([expout],
 [[Welcome to GNU libtool mixed C/Fortran demo!
 The C subroutine returned, claiming that 2*2 = 4
 The C subroutine is ok!
@@ -294,7 +294,7 @@ _LT_SETUP
 LT_AT_CHECK_CONFIG([--disable-shared],
[^build_old_libs=yes], [^build_libtool_libs=no])
 
-AT_DATA([expout],
+LT_AT_HOST_DATA([expout],
 [[ Welcome to GNU libtool Fortran demo!
  Real programmers write in FORTRAN.
  fsub called
diff --git a/tests/fcdemo.at b/tests/fcdemo.at
index 3a545eb..0ade9bb 100644
--- a/tests/fcdemo.at
+++ b/tests/fcdemo.at
@@ -263,7 +263,7 @@ m4_define([_LT_CHECK_EXECUTE],
 # on whether it is redirected to a file or sent to stdout, so we
 # just check return status, and ignore output.
 # Advice on this weirdness from a Fortran user much appreciated!
-AT_DATA([expout],
+LT_AT_HOST_DATA([expout],
 [[ Welcome to GNU libtool Fortran demo!
  Real programmers write in FORTRAN.
  fsub called
@@ -276,7 +276,7 @@ AT_DATA([expout],
 ]])
 LT_AT_EXEC_CHECK([./fprogram], 0, [ignore])
 
-AT_DATA([expout],
+LT_AT_HOST_DATA([expout],
 [[Welcome to GNU libtool mixed C/Fortran demo!
 The C subroutine returned, claiming that 2*2 = 4
 The C subroutine is ok!
diff --git a/tests/mdemo.at b/tests/mdemo.at
index 40f89b4..5fa77f6 100644
--- a/tests/mdemo.at
+++ b/tests/mdemo.at
@@ -592,7 +592,7 @@ main (int argc, char **argv)
 }
 ]])
 
-AT_DATA([expout],
+LT_AT_HOST_DATA([expout],
 [[Welcome to GNU Hell!
 cos (0.0) = 1
 ** This is not GNU Hello. There is no built-in mail reader. **
@@ -831,7 +831,7 @@ int main (int argc, char **argv)
 }
 ]])
 
-AT_DATA([expout],
+LT_AT_HOST_DATA([expout],
 [[Welcome to GNU libtool mdemo2!
 module name: foo1
 module reference count: 1
diff --git a/tests/tagdemo.at b/tests/tagdemo.at
index 3909d56..d54a612 100644
--- a/tests/tagdemo.at
+++ b/tests/tagdemo.at
@@ -315,7 +315,7 @@ AT_DATA([conv.cpp],
 int convenience (void) { return 1; }
 ]])
 
-AT_DATA([expout],
+LT_AT_HOST_DATA([expout],
 [[Welcome to GNU libtool tagdemo C++!
 ** This is libfoo (tagdemo) **
 foobar::hello returned: 57616

Re: Windows Line Endings [WAS Re: [SCM] GNU Libtool branch, master, updated. v2.4.2-273-ge24f183]

[Peter Rosin]

On 2012-10-05 18:03, Gary V. Vaughan wrote:
 Hi Peter,
 
 Apologies for having entirely forgotten about the old thread reviewing
 those patches first time around.
 
 And thanks for looking into it.  Is there a legal way to get access
 to Windows and the various flavours of gcc and MSVC that libtool users
 care about, without spending hundreds of dollars on software I would
 never use for anything else?  It pretty much sucks that everytime I
 push a well tested (on various Unix varieties) patch, that Windows likes
 to blow up gratuitously.  I don't mind wasting a bit of time checking
 things on Windows, but I really don't want to also waste money on
 Microsoft.

Others have answered this, so I will stop at mentioning that it would be
fantastic if you could run smoke tests on MSYS/MinGW before commit!
The worst case is MSYS/MSVC I think, but I don't mind if you skip that.
Covering MSYS/MinGW would be plenty enough.

 On 5 Oct 2012, at 22:21, Peter Rosin p...@lysator.liu.se wrote:
 I think you need to use LT_AT_HOST_DATA instead of AT_DATA, where
 appropriate.

 Unfortunately, the below is not enough since LT_AT_HOST_DATA
 eats whitespace (  foo - foo) which affects depdemo.at,
 f77demo.at and fcdemo.at. mdemo.at also seems to have
 more trouble that I need to look into...
 
 [[Patch snipped]]

Pushed with this ChangeLog

tests: fix line ending problems on MinGW

* tests/cdemo.at: Use LT_AT_HOST_DATA for expected output from
compiled programs.
* tests/demo.at: Likewise.
* tests/depdemo.at: Likewise.
* tests/f77demo.at: Likewise.
* tests/fcdemo.at: Likewise.
* tests/mdemo.at: Likewise.
* tests/tagdemo.at: Likewise.

Signed-off-by: Peter Rosin p...@lysator.liu.se


 I appear to have arrived at the same patch, and it still passes
 make distcheck on Mac OS X.  So LT_AT_HOST_DATA must only eat
 whitespace on Windows?  So the fix must be in the windows loop to
 rewrite lines with \r\n.  What's wrong with using awk or sed to
 inject the additional character rather than shell?  That would seem
 to be the obvious solution to me:
 
   awk '{printf (%s\r\n, $0);}'  $1  $1.t  mv -f $1.t $1
 
 (untested on Windows, but doesn't mess with whitespace on Mac or Linux)

After hiding $0 from m4 with [$]0, it resolved the whitespace issues
I think. I pushed a patch with that m4-escape folded in.

tests: make LT_AT_HOST_DATA retain whitespace on MinGW

Fixes issues with depdemo.at, f77demo.at and fcdemo.at.

* tests/testsuite.at (LT_AT_HOST_DATA) [MinGW]: Keep leading
and trailing spaces and tabs when converting line endings.
---
 tests/testsuite.at |3 +--
 1 files changed, 1 insertions(+), 2 deletions(-)

diff --git a/tests/testsuite.at b/tests/testsuite.at
index 60ff5d5..2a55d04 100644
--- a/tests/testsuite.at
+++ b/tests/testsuite.at
@@ -256,8 +256,7 @@ AT_CHECK([test -z $leftovers])
 m4_define([LT_AT_HOST_DATA],
 [AT_DATA([$1], [$2])
 case $host_os in mingw*)
-  while read -r l; do printf %s\r\n $l; done  $1  $1.t
-  mv -f $1.t $1 ;;
+  awk '{printf (%s\r\n, [$]0);}'  $1  $1.t  mv -f $1.t $1 ;;
 esac])
 
 

 Please do push patches that improve the situation for Windows rather
 than holding out for a fix-all mega-patch.  This will allow us to
 keep each other informed of breakages on platforms the other doesn't
 have access to.

Done.

The remaining fallout is libtool.at, mdemo.at, f77demo.at and fcdemo.at.
I'll see what I can dig out...

Cheers,
Peter

Re: Windows Line Endings

[Peter Rosin]

On 2012-10-05 22:01, Peter Rosin wrote:
 The remaining fallout is libtool.at, mdemo.at, f77demo.at and fcdemo.at.
 I'll see what I can dig out...

My guess is that f77demo.at and fcdemo.at fails because of
different stdio streams in their mixed mode programs.

Tests 159 and 162 (static library) fails because different
parts of the output has different style line endings with
\n from the C code and \r\n from the Fortran code. With
LT_AT_HOST_DATA all line endings are supposed to by \r\n
and it blows up.

That's strange I guess, but normalizing stdout with
LT_AT_UNIFY_NL instead of using LT_AT_HOST_DATA reveals
another stdio difference in tests 160, 161, 163 and 164.
In these tests the output from the Fortran code appears
at the end of the output, not in the middle as expected.

I thing the cause of this is different usages of the
stdio libraries. I believe the MinGW gcc is using some
wrappers around printf to make up for broken stuff in
the MSVCRT.dll printf and my guess is that MinGW fortran
is hammering directly on the MSVCRT.dll printf.

It is perhaps possible to fix this by adding fflush calls
(and equivalent for Fortran) before switching to the other
language.

I don't have enough mingwfuu to fix this. I also don't
understand why the tests used to work in the old setting?


Over to mdemo.at. It fails on MinGW because I do not have
any installed libltdl in MinGW. Temporarily moving the
installed Cygwin libltdl out of the lib search path makes
the test fail on Cygwin as well. So, I believe this is
a generic failure. Without an installed libltdl, I get this
during configure:

checking where to find libltdl headers... -I$(top_srcdir)/libltdl
checking where to find libltdl library... $(top_build_prefix)libltdl/libltdlc.la

and this when making:

../../libtool-msvc/tests/mdemo.at:646: $unset LIBTOOL LIBTOOLIZE; $MAKE $target 
stderr:
Makefile:1090: warning: overriding commands for target `libltdl/libltdlc.la'
Makefile:573: warning: ignoring old commands for target `libltdl/libltdlc.la'
Makefile:1090: warning: overriding commands for target `libltdl/libltdlc.la'
Makefile:573: warning: ignoring old commands for target `libltdl/libltdlc.la'
libtool: link: cannot find the library `libltdl/libltdlc.la' or unhandled 
argument `libltdl/libltdlc.la'
make[1]: *** [libmlib.la] Error 1

On Cygwin, with the installed libltdl intact, I get this during
configure:

checking where to find libltdl headers... 
checking where to find libltdl library... -lltdl

(and the test is ok, in so far one can consider using the
installed libltdl ok...)

I'm also noting that some time ago, mdemo had this in it's
Makefile.am:

## use @LIBLTDL@ because some broken makes do not accept macros in targets
## we can only do this because our LIBLTDL does not contain ${top_builddir}
top_distdir = ../..
@LIBLTDL@: $(top_distdir)/libtool \
$(top_distdir)/config.h $(srcdir)/$(top_distdir)/libltdl/ltdl.c \
$(srcdir)/$(top_distdir)/libltdl/ltdl.h
(cd $(top_distdir); $(MAKE) `echo $(LIBLTDL) | sed 
's,.*\.\./libltdl/,libltdl/,g'`)

but somewhere along the way, that comment was removed, probably at
the same time @LIBLTDL@ was converted into $(LIBLTDL). Anyway,
mdemo.at has this:

\$(LIBLTDL): ${top_build_prefix}libtool \
${top_build_prefix}config.h $top_srcdir/libltdl/ltdl.c \
$top_srcdir/libltdl/ltdl.h
cd $top_build_prefix; \$(MAKE) \`echo \$(LIBLTDL) | sed 
's|.*\.\./\.\./libltdl/|libltdl/|g'\`

But the second line of the removed comment seems crucial and
as our $(LIBLTDL) is not the expected libltdl/libltdlc.la,
Automake is fooled into creating two targets for the same
file. Or something.

Also, the old mdemo had LTDL_CONVENIENCE([../../libltdl]), and the
new mdemo.at have LT_CONFIG_LTDL_DIR([libltdl]) and
LTDL_INIT([nonrecursive]), which does not seem entirely equivalent?

I don't have enough autofuu to fix this.


And lastly libtool.at. It is only \' that is a problem. If I take
that char out of the backslashified list, the test is ok.
Another data point is that if I replace the grep on line 110 like
this:
-LT_AT_CHECK([$EGREP 
$mode:.*$match_preflag\?$flag\\$mchar:test\\$mchar\?  stdout], [0], 
[ignore])
+LT_AT_CHECK([$EGREP 
$mode:.*$match_preflag\?$flag$mchar:test$mchar\?  stdout], [0], 
[ignore])
it is ok for \ and \', but not for \$ and \\.

Looking at LT_ESCAPE in testsuite.at (which is expanded as part of
LT_AT_CHECK), it seems to handle \` specially, but not $.

My $EGREP is GNU grep 2.6.3 on Cygwin, and GNU grep 2.5.4 on MinGW.

I don't have enough quotefuu to fix this.

Cheers,
Peter

Re: [PATCH] tests: feed -no-undefined when linking libtool libraries

[Peter Rosin]

On 2012-10-03 05:45, Gary V. Vaughan wrote:
 Hi Peter,
 
 On Oct 3, 2012, at 12:32 AM, Peter Rosin p...@lysator.liu.se wrote:
 [snipped loads of stuff]
 
 [snipped a bit more stuff]
 
 You're saying that you are about to:

 $ git checkout master
 $ git merge --strategy=recursive -X theirs gary/reredo-test-operand-order \
 -m 'bla bla bla'

 right?
 
 Pretty much.  But that's just to show the merge in git history, the end
 effect will be identical to having committed the diff back to master.
 
 Is that better than committing the diff between reredo-... and master
 as a revert-light? Why else would you have gone through all the trouble
 of making all the smaller commits in the first place?
 
 It's better to show the branch merged in for future archaeology; the less
 time anyone else has to waste staring at 962aa91, the better a place the
 world will be.  And I'm all about making the world a better place! :-)
 
 I just fired up a test suite run...

Good news! Clean runs on Cygwin, MSYS/MinGW and MSYS/MSVC.

 Thanks!  I'm crossing my fingers -- I'll sleep a lot better when we've put
 this one behind us.

Now into nitpicking and other useless ramblings...

The patch libtool: unroll nested if into a single case statement has
whitespace issues (leading spaces instead of tabs on a few lines), and it
should perhaps use a simple catch-all * (retaining the fast_install is
set to needless comment) as the last case instead of *,needless that
you have put there. But I guess it's harmless as $fast_install is not any
random string, sans hacks, so no rereredo request from me, just a
nitpick that I saw when reviewing the libtool: ... changes at the
tip of gary/reredo-test-operand-order. Can always be cleaned up later,
if someone has the energy.

I also wonder about the relationship between libtool: fold if into a
compound OR statement when more readable and the next commit libtool:
simplify multiple string tests. What I mean is that about half the
tests from the later commit fit the pattern of the first, why did you
for example not change

if test yes,no = $avoid_version,$need_version; then
  major=
  versuffix=
  verstring=
fi

into

test yes,no = $avoid_version,$need_version  {
  major=
  versuffix=
  verstring=
}

(or some such) when you where at it? (but to me it looks like churn)

Anyway, to sum up, I'm ok with merging reredo branch into master.
Lets put this to rest now, thanks!

Cheers,
Peter

Re: [PATCH] tests: feed -no-undefined when linking libtool libraries

[Peter Rosin]

[snipped loads of stuff]

On 2012-10-02 16:54, Gary V. Vaughan wrote:
 The new branch gary/reredo-test-operand-order (notice the double re) has
 everything broken down into digestible chunks.  All the differences between
 that and master now look like improvements upon the original hand rolled
 version made by my recent scripted revisions, or else outright errors in
 the original corrected by the script.  All the errors you flagged on the
 list are corrected, as well as several others.

That last bit makes me curious :-)

 Assuming my running 'make dist' doesn't have any regressions compared to
 master, and unless you have additional problems with Windows using the
 gary/reredo-test-operand-order branch, I plan to merge the differences
 back into master in a day or two.

You're saying that you are about to:

$ git checkout master
$ git merge --strategy=recursive -X theirs gary/reredo-test-operand-order \
-m 'bla bla bla'

right?

Is that better than committing the diff between reredo-... and master
as a revert-light? Why else would you have gone through all the trouble
of making all the smaller commits in the first place?

I just fired up a test suite run...

Cheers,
Peter [who is not as alert as he used to when reading diffs]

Re: [PATCH] tests: feed -no-undefined when linking libtool libraries

[Peter Rosin]

On 2012-09-22 05:31, Gary V. Vaughan wrote:
 Hi Peter,
 
 On 19 Sep 2012, at 21:50, Peter Rosin p...@lysator.liu.se wrote:
 
 On 2012-09-19 16:20, Gary V. Vaughan wrote:
 Hi Peter,

 My bad, I'm embarrassed to say. I started to write a script to make the
 appropriate changes, but ended up doing it manually rather than adding
 more and more corner cases to the throwaway script... a poor choice in
 hindsight :-(

 It's easy to be wise after the fact... If you do redo it, may I suggest
 breaking up the patch in smaller pieces for bisectability?
 
 I've pushed a temporary branch called gary/redo-test-operand-order to
 savannah with seven changesets that reverts the manual version of the
 buggy original and redoes it with a painstaking awk script (also checked
 in, for the morbidly curious).
 
 I'm on the fence about committing in smaller pieces... the policy for
 libtool has always been to make sure the testsuite passes (at least
 on the committer's machine) for every changeset, so that bisecting
 using one of the test cases doesn't fail unexpectedly on another
 commit that was intentionally pushed with know failures.  On the other
 hand, the original was a monster, so I can see the benefits of splitting
 it up a bit too.

Why not commit the sc_prohibit_test_const_follows_var improvement
last, after fixing all violations?

BTW, the revert is also a monster, and I think the current split
is too coarse. It felt better with an autogenerated patch, but
that feeling disappeared when I reviewed the results, see below
for details. You still have hundreds of changes to fundamentally
different parts of the code in a single commit. It's impossible
(well, at least annoyingly time consuming) to find the offending
change if such a commit is found to cause a regression.

 I think it will be safer to revert the broken patch, and then
 write a script to reapply those changes automatically as I
 should have done originally, and only then to merge the result
 back to head. If you hold off for a few days, I'll do that as
 penance for my sins when I get back to my computer.

 I'm not sure a revert of such a big patch is possible after
 50-odd more patches? But I was thinking revert too after
 reading it for a while... Who knows what else hides in
 there?
 
 Well, I wrote and applied the script, diffed the results, and
 the testsuite has no regressions for me.  I get a weird failure
 in distcheck which tries to run distclean in _build/tests/cdemo
 aftec removing _build/tests/cdemo/Makefile, that I haven't had
 time to check against current master to see if it is a new regression
 caused by my patch.
 
 But please hold on to your test case to verify that I've made
 a better job of things on the do over.

 That's easy, on Cygwin:
  make check-local TESTSUITEFLAGS=-k Runpath
 is supposed to PASS (not FAIL) and
  make check-local TESTSUITEFLAGS=-k relpaths
 is supposed to XFAIL (not XPASS)

 (mentioning it here so that I don't forget myself)
 
 Cool.  When you have time, please let me know whether the temporary
 branch I made works properly for you.  I'll do some more regression
 testing, and if all goes well, I'll transplant the branch onto
 master.

No issues in the testsuite here that I notice. Not trusting that
however...

 My awk script also matches your changes in these hunks, so I'm
 moderately confident that it will have caught any other lurkers too.

...and diffing between master (-) and redo-test-operand-order (+) got
me these among a bunch of bring stuff. But I wonder what I missed
this time?

diff --git a/m4/argz.m4 b/m4/argz.m4
index ad1743e..09568ad 100644
--- a/m4/argz.m4
+++ b/m4/argz.m4
@@ -55,11 +55,11 @@ AS_IF([test -z $ARGZ_H],
 lt_os_major=${2-0}
 lt_os_minor=${3-0}
 lt_os_micro=${4-0}
-if test 1 -le $lt_os_major \
+if test 1 -lt $lt_os_major \
|| { test 1 -eq $lt_os_major \
-  { test 5 -le $lt_os_minor \
+  { test 5 -lt $lt_os_minor \
|| { test 5 -eq $lt_os_minor \
-  test 24 -le $lt_os_micro; }; }; }; then
+  test 24 -lt $lt_os_micro; }; }; }; then
   lt_cv_sys_argz_works=yes
 fi
   fi
diff --git a/m4/libtool.m4 b/m4/libtool.m4
index 4413a6d..8ec9beb 100644
--- a/m4/libtool.m4
+++ b/m4/libtool.m4
@@ -4982,7 +4982,7 @@ _LT_EOF
# need to do runtime linking.
case $host_os in aix4.[[23]]|aix4.[[23]].*|aix[[5-9]]*)
  for ld_flag in $LDFLAGS; do
- if (test x-brtl = x$ld_flag || test x-Wl,-brtl = x$ld_flag); then
+ if (test -brtl = $ld_flag || test -Wl,-brtl = $ld_flag); then
aix_use_runtimelinking=yes
break
  fi
@@ -7730,7 +7730,7 @@ for lt_ac_sed in $lt_ac_sed_list /usr/xpg4/bin/sed; do
 $lt_ac_sed -e 's/a$//'  conftest.nl conftest.out || break
 cmp -s conftest.out conftest.nl || break
 # 1 chars as input seems more than

Re: [PATCH] tests: feed -no-undefined when linking libtool libraries

[Peter Rosin]

On 2012-09-26 14:57, Peter Rosin wrote:
 On 2012-09-22 05:31, Gary V. Vaughan wrote:

[Heavily snipped]

 Why not commit the sc_prohibit_test_const_follows_var improvement
 last, after fixing all violations?

That doesn't make sense, sorry. But the idea would have worked
initially, before the check first existed. I.e., write the check,
fixup violations and commit in smaller digestible chunks, then
finally commit the actual check preventing any new violations from
creeping in.

 If not, I will branch before 962aa91, run the script, and then apply
 the rest of master to that branch one patch at a time until I arrive
 at a diff that I can apply to master itself, rather than using revert
 as I did on the current temporary branch.
 
 I have to say, given all these difficulties, is it really worth it?
 Besides, I think

Hmmm, I said that in the wrong context. Your plan above seems like the
best path forward. I guess I was too excited about the bugs and didn't
read properly, sorry again about my poor communication skills.

Some of the noise between master and redo-test-operand-order are a bunch
of hunks with this pattern:
-   if test bar $op $foo; then
+   if test bar $op $foo ; then

You should perhaps add a commit to redo-test-operand-order which silences
that and makes other more substantial changes stand out more before you
proceed with the above plan? There are perhaps other harmless changes
that can be excluded from the light revert? Because who needs the
oscillation?

BTW, here is another strange-looking hunk from
git diff master redo-test-operand-order

diff --git a/m4/libtool.m4 b/m4/libtool.m4
index 4413a6d..8ec9beb 100644
--- a/m4/libtool.m4
+++ b/m4/libtool.m4
@@ -5563,7 +5563,7 @@ _LT_EOF
   ;;
 esac
 
-if test sni = $host_vendor; then
+if test x$host_vendor = xsni; then
   case $host in
   sysv4 | sysv4.2uw2* | sysv4.3* | sysv5*)
_LT_TAGVAR(export_dynamic_flag_spec, $1)='$wl-Blargedynsym'

What has caused the difference in this hunk? Why hasn't the script
caught this instance? And why isn't the syntax-check triggered?
Are the missing quotes the key here?

The check is named sc_prohibit_test_const_follows_var, so one
would guess that it should prohibit test x$foo = xbar, no? Or are
you supposed to be able to dodge the check by needlessly adding x
in front of LHS $variables?

Cheers,
Peter

[PATCH] tests: don't feed -no-undefined to the linker during, configure.

[Peter Rosin]

* tests/deplibs-mingw.at: Restore LDFLAGS for the configure run so that
the linker does not see -no-undefined. Makes the test pass instead of
skip on MinGW.

Signed-off-by: Peter Rosin p...@lysator.liu.se
---
 tests/deplibs-mingw.at |3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

Ok to push?
Or should I simply rename the LDFLAGS variable?  To my_LDFLAGS?

Cheers,
Peter

diff --git a/tests/deplibs-mingw.at b/tests/deplibs-mingw.at
index 6973c4f..dd2b8e8 100644
--- a/tests/deplibs-mingw.at
+++ b/tests/deplibs-mingw.at
@@ -31,6 +31,7 @@ cwd=`pwd`
 instdir=$cwd/inst
 libdir=$instdir/lib
 bindir=$instdir/bin
+save_LDFLAGS=$LDFLAGS
 LDFLAGS=$LDFLAGS -no-undefined

 mkdir inst inst/bin inst/lib
@@ -76,7 +77,9 @@ EOF
   cd new-libtool
   # configure might fail due to in-tree build of toplevel, or
   # missing configure flags and other reasons.
+  LDFLAGS=$save_LDFLAGS
   LT_AT_CONFIGURE([|| exit 77], [$abs_top_srcdir/configure])
+  LDFLAGS=$LDFLAGS -no-undefined
   cd ..
   LIBTOOL=new-libtool/libtool
   export LIBTOOL
--
1.7.9

[PATCH] tests: feed -no-undefined when linking libtool libraries

[Peter Rosin]

* tests/runpath-in-lalib.at: Make sure shared libraries are created
on Windows by passing -no-undefined. Otherwise libb.la fails to record
a dependency on liba.la, and the final link of the program then fails
with undefined symbols.

Signed-off-by: Peter Rosin p...@lysator.liu.se
---
 tests/runpath-in-lalib.at |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

Ok to push?
Or maybe the failure is deeper than this? Should libb.la record a
dependency on liba.la even if libb.la is static only?

The relevant difference in libb.la with this patch is this (I have
elided changes to dlopen and library_names which are empty when
no shared library is built):

@@ -17,7 +17,7 @@
 inherited_linker_flags=''
 
 # Libraries that this one depends upon.
-dependency_libs=' 
-R/home/peda/libtool/git/cygwin/tests/testsuite.dir/047/foobar '
+dependency_libs=' 
-R/home/peda/libtool/git/cygwin/tests/testsuite.dir/047/foobar  
/home/peda/libtool/git/cygwin/tests/testsuite.dir/047/liba.la'
 
 # Names of additional weak libraries provided by this library
 weak_library_names=''

Cheers,
Peter

diff --git a/tests/runpath-in-lalib.at b/tests/runpath-in-lalib.at
index bdd1279..7c433d3 100644
--- a/tests/runpath-in-lalib.at
+++ b/tests/runpath-in-lalib.at
@@ -41,6 +41,7 @@ instdir=`pwd`/inst
 libdir=$instdir/lib
 bindir=$instdir/bin
 addrunpath=`pwd`/foobar
+LDFLAGS=$LDFLAGS -no-undefined

 mkdir $instdir $libdir $bindir

--
1.7.9

[PATCH] tests: skip with-pic test when no real pic flag is used.

[Peter Rosin]

* tests/with-pic.at: Windows uses -DDLL_EXPORT -DPIC as the pic
flag, but never applies it to static libraries. Cater for this
and skip if no real pic flag is in use.

Signed-off-by: Peter Rosin p...@lysator.liu.se
---
 tests/with-pic.at |   11 ++-
 1 files changed, 10 insertions(+), 1 deletions(-)

Ok to push?
I tried to eliminate the loop using variants of this:

real_pic=false
case  $pic_flag  in
* [^-]* | * -[^D]*) real_pic=: ;;
esac
AT_CHECK([$real_pic || exit 77])

...but I never got that to work in the test. It worked in an
interactive bash though. Strange.

Cheers,
Peter

diff --git a/tests/with-pic.at b/tests/with-pic.at
index cee5e32..e4f52c2 100644
--- a/tests/with-pic.at
+++ b/tests/with-pic.at
@@ -24,7 +24,16 @@
 AT_SETUP([test --with-pic])
 eval `$LIBTOOL --config | $EGREP '^(pic_flag|FGREP)='`
 
-AT_CHECK([test -n $pic_flag || exit 77])
+# skip if there is no real pic flag (-D defines don't count)
+set x $pic_flag
+shift
+for pf; do
+  case $1 in
+-D*) shift ;;
+*)   break ;;
+  esac
+done
+AT_CHECK([test $# -ne 0 || exit 77])
 AT_CHECK([test . != $at_srcdir || exit 77])
 
 CONFIGURE=$abs_top_srcdir/tests/demo/configure
--
1.7.9

Re: [PATCH] tests: feed -no-undefined when linking libtool libraries

[Peter Rosin]

On 2012-09-19 09:31, Peter Rosin wrote:
 * tests/runpath-in-lalib.at: Make sure shared libraries are created
 on Windows by passing -no-undefined. Otherwise libb.la fails to record
 a dependency on liba.la, and the final link of the program then fails
 with undefined symbols.
 
 Signed-off-by: Peter Rosin p...@lysator.liu.se
 ---
  tests/runpath-in-lalib.at |1 +
  1 files changed, 1 insertions(+), 0 deletions(-)
 
 Ok to push?
 Or maybe the failure is deeper than this? Should libb.la record a
 dependency on liba.la even if libb.la is static only?
 
 The relevant difference in libb.la with this patch is this (I have
 elided changes to dlopen and library_names which are empty when
 no shared library is built):
 
 @@ -17,7 +17,7 @@
  inherited_linker_flags=''
  
  # Libraries that this one depends upon.
 -dependency_libs=' 
 -R/home/peda/libtool/git/cygwin/tests/testsuite.dir/047/foobar '
 +dependency_libs=' 
 -R/home/peda/libtool/git/cygwin/tests/testsuite.dir/047/foobar  
 /home/peda/libtool/git/cygwin/tests/testsuite.dir/047/liba.la'
  
  # Names of additional weak libraries provided by this library
  weak_library_names=''

I likely is deeper, it seems this is a regression since 2.4.2.

Cheers,
Peter

Re: [PATCH] tests: skip with-pic test when no real pic flag is used.

[Peter Rosin]

On 2012-09-19 11:20, Gary V. Vaughan wrote:
 Hi Peter,
 
 On 19 ก.ย. 2012, at 15:56, Peter Rosin p...@lysator.liu.se wrote:
 
 * tests/with-pic.at: Windows uses -DDLL_EXPORT -DPIC as the pic
 flag, but never applies it to static libraries. Cater for this
 and skip if no real pic flag is in use.
 [[...]]

 Ok to push?
 
 Yes, with nit below addressed. Thanks!
 
 I tried to eliminate the loop using variants of this:

 real_pic=false
 case  $pic_flag  in
 * [^-]* | * -[^D]*) real_pic=: ;;
 esac
 AT_CHECK([$real_pic || exit 77])

 ...but I never got that to work in the test. It worked in an
 interactive bash though. Strange.
 
 M4 will strip one level of square brackets as it generates the testsuite 
 script. Normally we just put an extra level of quoting around regexps/globs 
 to account for that:
 
  [* [^-]* | * -[^D]*]) real_pic=: ;; 

Doh!  Face-palm.  It's been a while...

I needed an extra space to not seeas a real pic flag.
This is what I pushed:

Cheers,
Peter

diff --git a/tests/with-pic.at b/tests/with-pic.at
index cee5e32..915acf5 100644
--- a/tests/with-pic.at
+++ b/tests/with-pic.at
@@ -24,7 +24,11 @@
 AT_SETUP([test --with-pic])
 eval `$LIBTOOL --config | $EGREP '^(pic_flag|FGREP)='`

-AT_CHECK([test -n $pic_flag || exit 77])
+real_pic=false
+case  $pic_flag  in
+[* [^ -]* | * -[^D]*]) real_pic=: ;;
+esac
+AT_CHECK([$real_pic || exit 77])
 AT_CHECK([test . != $at_srcdir || exit 77])

 CONFIGURE=$abs_top_srcdir/tests/demo/configure

Re: [PATCH] tests: feed -no-undefined when linking libtool libraries

[Peter Rosin]

On 2012-09-19 11:26, Peter Rosin wrote:
 On 2012-09-19 09:31, Peter Rosin wrote:
 * tests/runpath-in-lalib.at: Make sure shared libraries are created
 on Windows by passing -no-undefined. Otherwise libb.la fails to record
 a dependency on liba.la, and the final link of the program then fails
 with undefined symbols.

 Signed-off-by: Peter Rosin p...@lysator.liu.se
 ---
  tests/runpath-in-lalib.at |1 +
  1 files changed, 1 insertions(+), 0 deletions(-)

 Ok to push?
 Or maybe the failure is deeper than this? Should libb.la record a
 dependency on liba.la even if libb.la is static only?

 The relevant difference in libb.la with this patch is this (I have
 elided changes to dlopen and library_names which are empty when
 no shared library is built):

 @@ -17,7 +17,7 @@
  inherited_linker_flags=''
  
  # Libraries that this one depends upon.
 -dependency_libs=' 
 -R/home/peda/libtool/git/cygwin/tests/testsuite.dir/047/foobar '
 +dependency_libs=' 
 -R/home/peda/libtool/git/cygwin/tests/testsuite.dir/047/foobar  
 /home/peda/libtool/git/cygwin/tests/testsuite.dir/047/liba.la'
  
  # Names of additional weak libraries provided by this library
  weak_library_names=''
 
 I likely is deeper, it seems this is a regression since 2.4.2.

I have bisected this regression to 962aa919f51cdf8e2cee4fb2d1d9bafa34d50887
syntax-check: fix violations and implement sc_prohibit_test_const_follows_var.

I looked through that insanely huge patch and it was not fun. I did
manage to find a couple of problems:

-if test $pic_mode = no  test $deplibs_check_method != pass_all; then
+if test yes = $pic_mode  test pass_all != $deplibs_check_method; then

-   if test $prev = dlprefiles; then
+   if test dlfiles = $prev; then

-   if test x`$SED 1q $export_symbols` != xEXPORTS; then
+   if test EXPORTS = `$SED 1q $export_symbols`; then

-if test x[$]$2 = xyes; then
+if test yes != [$]$2; then

However, my eyes must have glazed over because it is not enough to fix those
bugs.

Comparing to master, I notice that:

* The export_symbols change has a fixup in
  b804ffabee2ce373d9bac6ae2b235ec68e0b55e8
  fixup: restore EXPORTS test
* The x[$]$2 change has a fixup in
  11869b9c9eb8bcc8cb6a615141f522a447377324
  m4: fix logic error leading to -fno-rtti being added wrongly.

I have removed a long rant on my opinion of the offending patch, it
would do no good anyway...

Bottom line: More eyes needed on that patch!

Ok to push the below?

Cheers,
Peter

From 79d4c09db4317f2f96ba7cbbfc06a8a9da0ff984 Mon Sep 17 00:00:00 2001
From: Peter Rosin p...@lysator.liu.se
Date: Wed, 19 Sep 2012 14:23:26 +0200
Subject: [PATCH] fixup: restore stomped tests

Commit v2.4.2-120-g962aa91
syntax-check: fix violations and implement sc_prohibit_test_const_follows_var
inadvertedly stomped some comparisons.

* build-aux/ltmain.m4sh (func_mode_compile): Reverse test when checking
if non-PIC is attempted in shared libraries.
(func_mode_link): Check for dlprefiles, not dlfiles.
---
 build-aux/ltmain.m4sh |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/build-aux/ltmain.m4sh b/build-aux/ltmain.m4sh
index 14f3c37..69722ef 100644
--- a/build-aux/ltmain.m4sh
+++ b/build-aux/ltmain.m4sh
@@ -1350,7 +1350,7 @@ func_mode_compile ()
   pic_mode=default
   ;;
 esac
-if test yes = $pic_mode  test pass_all != $deplibs_check_method; then
+if test no = $pic_mode  test pass_all != $deplibs_check_method; then
   # non-PIC code in shared libraries is not supported
   pic_mode=default
 fi
@@ -5151,7 +5151,7 @@ func_mode_link ()
fi

# CHECK ME:  I think I busted this.  -Ossama
-   if test dlfiles = $prev; then
+   if test dlprefiles = $prev; then
  # Preload the old-style object.
  func_append dlprefiles  $pic_object
  prev=

Re: [PATCH] tests: feed -no-undefined when linking libtool libraries

[Peter Rosin]

On 2012-09-19 16:20, Gary V. Vaughan wrote:
 Hi Peter,
 
 My bad, I'm embarrassed to say. I started to write a script to make the
 appropriate changes, but ended up doing it manually rather than adding
 more and more corner cases to the throwaway script... a poor choice in
 hindsight :-(

It's easy to be wise after the fact... If you do redo it, may I suggest
breaking up the patch in smaller pieces for bisectability?

 On 19 ก.ย. 2012, at 19:27, Peter Rosin p...@lysator.liu.se wrote:
 On 2012-09-19 11:26, Peter Rosin wrote:
 On 2012-09-19 09:31, Peter Rosin wrote:
 * tests/runpath-in-lalib.at: Make sure shared libraries are created
 on Windows by passing -no-undefined. Otherwise libb.la fails to record
 a dependency on liba.la, and the final link of the program then fails
 with undefined symbols.

 Signed-off-by: Peter Rosin p...@lysator.liu.se
 ---
 tests/runpath-in-lalib.at |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

 Ok to push?
 Or maybe the failure is deeper than this? Should libb.la record a
 dependency on liba.la even if libb.la is static only?

 I likely is deeper, it seems this is a regression since 2.4.2.

 I have bisected this regression to 962aa919f51cdf8e2cee4fb2d1d9bafa34d50887
 syntax-check: fix violations and implement 
 sc_prohibit_test_const_follows_var.

 I looked through that insanely huge patch and it was not fun. I did
 manage to find a couple of problems:

 -if test $pic_mode = no  test $deplibs_check_method != pass_all; 
 then
 +if test yes = $pic_mode  test pass_all != $deplibs_check_method; 
 then

 -if test $prev = dlprefiles; then
 +if test dlfiles = $prev; then

 -if test x`$SED 1q $export_symbols` != xEXPORTS; then
 +if test EXPORTS = `$SED 1q $export_symbols`; then

 -if test x[$]$2 = xyes; then
 +if test yes != [$]$2; then

 However, my eyes must have glazed over because it is not enough to fix those
 bugs.
 
 I guess my whole brain glazed over while I was checking and rechecking
 before pushing, so I'm not surprised.
 
 Comparing to master, I notice that:

 * The export_symbols change has a fixup in
 b804ffabee2ce373d9bac6ae2b235ec68e0b55e8
 fixup: restore EXPORTS test
 * The x[$]$2 change has a fixup in
 11869b9c9eb8bcc8cb6a615141f522a447377324
 m4: fix logic error leading to -fno-rtti being added wrongly.

 I have removed a long rant on my opinion of the offending patch, it
 would do no good anyway...
 
 Thanks for finding it, and sparing me from the additional shame.
 
 Bottom line: More eyes needed on that patch!

 Ok to push the below?
 
 I think it will be safer to revert the broken patch, and then
 write a script to reapply those changes automatically as I
 should have done originally, and only then to merge the result
 back to head. If you hold off for a few days, I'll do that as
 penance for my sins when I get back to my computer.

I'm not sure a revert of such a big patch is possible after
50-odd more patches? But I was thinking revert too after
reading it for a while... Who knows what else hides in
there?

 But please hold on to your test case to verify that I've made
 a better job of things on the do over.

That's easy, on Cygwin:
make check-local TESTSUITEFLAGS=-k Runpath
is supposed to PASS (not FAIL) and
make check-local TESTSUITEFLAGS=-k relpaths
is supposed to XFAIL (not XPASS)

(mentioning it here so that I don't forget myself)


Meanwhile, I found another one by diffing the --debug output
from building libb.la in runpath-in-lalib.at with/without the
offender:

- if test $deplibs_check_method != pass_all; then
+ if test pass_all = $deplibs_check_method; then

A fixup of this change actually makes the above tests behave
on Cygwin/MinGW. So, in case it proves too hard to revert
and redo, the below is my current fixup-patch.

Cheers,
Peter

From 072c4beb6564c39099d4c691620e2fac5f32f7ed Mon Sep 17 00:00:00 2001
From: Peter Rosin p...@lysator.liu.se
Date: Wed, 19 Sep 2012 16:38:34 +0200
Subject: [PATCH] fixup: restore stomped tests

Commit v2.4.2-120-g962aa91
syntax-check: fix violations and implement sc_prohibit_test_const_follows_var
inadvertenty stomped some comparisons.

* build-aux/ltmain.m4sh (func_mode_compile): Reverse test when checking
if non-PIC is attempted in shared libraries.
(func_mode_link): Check for dlprefiles, not dlfiles.
(func_mode_link): Reverse test so that dependencies are checked when
pass_all is not in effect.
---
 build-aux/ltmain.m4sh |6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/build-aux/ltmain.m4sh b/build-aux/ltmain.m4sh
index 14f3c37..0b8defa 100644
--- a/build-aux/ltmain.m4sh
+++ b/build-aux/ltmain.m4sh
@@ -1350,7 +1350,7 @@ func_mode_compile ()
   pic_mode=default
   ;;
 esac
-if test yes = $pic_mode  test pass_all != $deplibs_check_method; then
+if test no = $pic_mode  test pass_all != $deplibs_check_method; then
   # non-PIC code in shared libraries is not supported
   pic_mode

Re: [PATCH] tests: don't feed -no-undefined to the linker during, configure.

[Peter Rosin]

On 2012-09-19 21:25, Roumen Petrov wrote:
 Peter Rosin wrote:
 * tests/deplibs-mingw.at: Restore LDFLAGS for the configure run so that
 the linker does not see -no-undefined. Makes the test pass instead of
 skip on MinGW.

 Signed-off-by: Peter Rosin p...@lysator.liu.se
 ---
   tests/deplibs-mingw.at |3 +++
   1 files changed, 3 insertions(+), 0 deletions(-)

 Ok to push?
 No idea. It pass to me with git code , cross build, tested in emulated 
 environment.

It's strange that you get a pass, if you have mingw.

Note that the test is a bit weird in that it passes instead
of skips on $host_os != mingw*, so are you sure you even get
into the inner configure with your setup? Because if you do,
your compiler must accept -no-undefined and that seems
unlikely to me.

Anyway, in my non-cross, non-emulated setup, the test skips on
line 79:

LT_AT_CONFIGURE([|| exit 77], [$abs_top_srcdir/configure])

where configure bombs out with the compiler not being able to
create executables (due to gcc not understanding -no-undefined).

So, the patch upgrades this completely bogus skip to a pass on
real MinGW.

Cheers,
Peter

Re: [PATCH] tests: skip with-pic test when no real pic flag is used.

[Peter Rosin]

On 2012-09-19 21:43, Roumen Petrov wrote:
 Peter Rosin wrote:
 * tests/with-pic.at: Windows uses -DDLL_EXPORT -DPIC as the pic
 flag, but never applies it to static libraries. Cater for this
 and skip if no real pic flag is in use.
 I'm not sure that this test is suitable for mingw host.
 
 
 Signed-off-by: Peter Rosin p...@lysator.liu.se
 ---
   tests/with-pic.at |   11 ++-
   1 files changed, 10 insertions(+), 1 deletions(-)

 Ok to push?
 No as libtool should define -DPIC and for mingw host pic flag is 
 -DDLL_EXPORT

The test skips on MinGW with the patch, w/o the patch it
fails. You are first saying that the test is not suitable
for MinGW (implying that a skip is in order), and then you
don't like the patch (implying that a fail is good news).
You don't make any sense.

So, what do you mean?

Cheers,
Peter

Re: [PATCH] tests: feed -no-undefined when linking libtool libraries

[Peter Rosin]

On 2012-09-19 21:32, Roumen Petrov wrote:
 Peter Rosin wrote:
 On 2012-09-19 09:31, Peter Rosin wrote:
 * tests/runpath-in-lalib.at: Make sure shared libraries are created
 on Windows by passing -no-undefined. Otherwise libb.la fails to record
 a dependency on liba.la, and the final link of the program then fails
 with undefined symbols.

 Signed-off-by: Peter Rosin p...@lysator.liu.se
 ---
   tests/runpath-in-lalib.at |1 +
   1 files changed, 1 insertions(+), 0 deletions(-)

 Ok to push?
 No idea . Test pass to me with current repository code, cross build , run in 
 emulated .

You haven't finished reading the thread. The problem was
deeper and the regression has been identified as an
accidentally inverted test. Adding -no-undefined was not
the correct answer (I hinted at that suspicion in my
original message), but if your setup works with git
master, then your setup does not behave as the real
MinGW behaves when trying to link with undefined symbols.

Cheers,
Peter

Re: [PATCH] tests: skip with-pic test when no real pic flag is used.

[Peter Rosin]

On 2012-09-19 23:02, Roumen Petrov wrote:
 Peter Rosin wrote:
 On 2012-09-19 21:43, Roumen Petrov wrote:
 Peter Rosin wrote:
 * tests/with-pic.at: Windows uses -DDLL_EXPORT -DPIC as the pic
 flag, but never applies it to static libraries. Cater for this
 and skip if no real pic flag is in use.
 I'm not sure that this test is suitable for mingw host.


 Signed-off-by: Peter Rosin p...@lysator.liu.se
 ---
tests/with-pic.at |   11 ++-
1 files changed, 10 insertions(+), 1 deletions(-)

 Ok to push?
 No as libtool should define -DPIC and for mingw host pic flag is 
 -DDLL_EXPORT
 The test skips on MinGW with the patch, w/o the patch it
 fails. You are first saying that the test is not suitable
 for MinGW (implying that a skip is in order), and then you
 don't like the patch (implying that a fail is good news).
 You don't make any sense.

 So, what do you mean?
 On woe libtool define -DDLL_EXPORT as pic flag . So the value is
 pic_flag= -DDLL_EXPORT -DPIC
 On some other platform PIC default. I don't have asses to
 those platforms and I could guess that the value is pic_flag=-DPIC,
 i.e. only wit defines.

Ah, now the objection makes sense.  Thanks for spelling it out!

 If I understand patched code properly, skip the test if pic_flag
 contain only defines. This mean that other platform will be skipped
 too.

Correct.
 
 What about to skip test only if DLL_EXPORT is in pic_flag ?

Since the patch has already been pushed and it is only a test
that may be skipped on some other platforms, I'm going to
wait for a bit until someone can confirm if this change has in
fact caused skips where the test used to pass.  So, not
rushing this one...

Anyway, the change is simple if needed:

-real_pic=false
+no_dlls=:
 case  $pic_flag  in
-[* [^ -]* | * -[^D]*]) real_pic=: ;;
+* -DDLL_EXPORT *) no_dlls=false ;;
 esac
-AT_CHECK([$real_pic || exit 77])
+AT_CHECK([$no_dlls || exit 77])

Cheers,
Peter

Re: libtool quoting error

[Peter Rosin]

On 2012-08-19 22:18, Peter Rosin wrote:
 Oops, forgot a couple of backslashes, trying again.
 
 Sorry for the noise.
 
 Testsuite running, just in case...

The patch does not seem to affect the testsuite, so I'll push in
a few days.  Unless someone speaks up against it of course.

Cheers,
Peter

Re: libtool quoting error

[Peter Rosin]

On 2012-08-20 16:14, Bob Friesenhahn wrote:
 On Mon, 20 Aug 2012, Peter Rosin wrote:
 
 On 2012-08-19 22:18, Peter Rosin wrote:
 Oops, forgot a couple of backslashes, trying again.

 Sorry for the noise.

 Testsuite running, just in case...

 The patch does not seem to affect the testsuite, so I'll push in
 a few days.  Unless someone speaks up against it of course.
 
 The final version (with backslash) looks good to me.  No need to wait a few 
 days.

Pushed, thanks!

Cheers,
Peter

Re: libtool quoting error

[Peter Rosin]

[Cygwinners: Taking this to the Libtool lists]
[Libtoolers: Following up on a post on the cygwin mailing list]

On 2012-08-19 19:03, Andreas Schiffler wrote:
 The libtool distributed with cygwin has a bug that prevents use in paths 
 containing spaces.
 This was encountered when trying to build SDL2 on Windows (see 
 http://bugzilla.libsdl.org/show_bug.cgi?id=1575 for details or repro).
 
 # Which release of libtool.m4 was used?
 macro_version=2.2.6
 macro_revision=1.3012
 
 The fix is simple: add additional quoting.
 
 $ diff libtool libtool-fixed
 2797c2797
exec_cmd='$SHELL $progpath $preserve_args --finish$current_libdirs'
 ---
   exec_cmd='$SHELL $progpath $preserve_args --finish$current_libdirs'
 8321c8321
if test X$ECHO = X$SHELL $progpath --fallback-echo; then
 ---
   if test X$ECHO = X$SHELL \$progpath\ --fallback-echo; then
 8323,8324c8323,8324
[\\/]* | [A-Za-z]:[\\/]*) qecho=$SHELL $progpath --fallback-echo;;
*) qecho=$SHELL `pwd`/$progpath --fallback-echo;;
 ---
   [\\/]* | [A-Za-z]:[\\/]*) qecho=$SHELL \$progpath\ 
 --fallback-echo;;
   *) qecho=$SHELL `pwd`/\$progpath\ --fallback-echo;;
 8559c8559
relink_command=(cd `pwd`; $SHELL $progpath $preserve_args 
 --mode=relink $libtool_args @inst_prefix_dir@)
 ---
   relink_command=(cd `pwd`; $SHELL \$progpath\ $preserve_args 
 --mode=relink $libtool_args @inst_prefix_dir@)

The code changed in the two middle hunks went out after 2.2.6 and
are thus gone in 2.2.8 and later, so that no longer applies.

I also took the liberty of changing ltmain.m4sh instead of the
generated libtool script.

So, this is a better attempt for a patch, with Andreas added to
THANKS.

Ok to push?

Cheers,
Peter

From c50b8d27d5832ca1c962bf3dec46c1b85eff5bad Mon Sep 17 00:00:00 2001
From: Peter Rosin p...@lysator.liu.se
Date: Sun, 19 Aug 2012 22:06:06 +0200
Subject: [PATCH] libtool: quote progpath properly

Attempt to handle spaces in paths better.

* build-aux/ltmain.m4sh (func_mode_install, func_mode_link): Quote
$progpath.
* THANKS: Update.
---
 THANKS|1 +
 build-aux/ltmain.m4sh |4 ++--
 2 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/THANKS b/THANKS
index 84cb6c9..24f1c91 100644
--- a/THANKS
+++ b/THANKS
@@ -70,6 +70,7 @@
   Alan Hourihane		al...@fairlite.co.uk
   Alexei Sheplyakov		v...@theor.jinr.ru
   Alon Bar-Lev			alon.bar...@gmail.com
+  Andreas Schiffler		aschiff...@ferzkopp.net
   Andreas Schwab		sch...@suse.de
   Andrey Slepuhin		p...@msu.ru
   Aneesh Kumar K.V		kvane...@hotmail.com
diff --git a/build-aux/ltmain.m4sh b/build-aux/ltmain.m4sh
index 30f99f4..968b727 100644
--- a/build-aux/ltmain.m4sh
+++ b/build-aux/ltmain.m4sh
@@ -2449,7 +2449,7 @@ func_mode_install ()
 if test -n $current_libdirs; then
   # Maybe just do a dry run.
   $opt_dry_run  current_libdirs= -n$current_libdirs
-  exec_cmd='$SHELL $progpath $preserve_args --finish$current_libdirs'
+  exec_cmd='$SHELL $progpath $preserve_args --finish$current_libdirs'
 else
   exit $EXIT_SUCCESS
 fi
@@ -8506,7 +8506,7 @@ EOF
 	fi
   done
   # Quote the link command for shipping.
-  relink_command=(cd `pwd`; $SHELL $progpath $preserve_args --mode=relink $libtool_args @inst_prefix_dir@)
+  relink_command=(cd `pwd`; $SHELL $progpath $preserve_args --mode=relink $libtool_args @inst_prefix_dir@)
   relink_command=`$ECHO $relink_command | $SED $sed_quote_subst`
   if test yes = $hardcode_automatic; then
 	relink_command=
-- 
1.7.9

Re: libtool quoting error

[Peter Rosin]

On 2012-08-19 22:09, Peter Rosin wrote:
 [Cygwinners: Taking this to the Libtool lists]
 [Libtoolers: Following up on a post on the cygwin mailing list]
 
 On 2012-08-19 19:03, Andreas Schiffler wrote:
 The libtool distributed with cygwin has a bug that prevents use in paths 
 containing spaces.
 This was encountered when trying to build SDL2 on Windows (see 
 http://bugzilla.libsdl.org/show_bug.cgi?id=1575 for details or repro).

 # Which release of libtool.m4 was used?
 macro_version=2.2.6
 macro_revision=1.3012

 The fix is simple: add additional quoting.

 $ diff libtool libtool-fixed
 2797c2797
exec_cmd='$SHELL $progpath $preserve_args --finish$current_libdirs'
 ---
   exec_cmd='$SHELL $progpath $preserve_args --finish$current_libdirs'
 8321c8321
if test X$ECHO = X$SHELL $progpath --fallback-echo; then
 ---
   if test X$ECHO = X$SHELL \$progpath\ --fallback-echo; then
 8323,8324c8323,8324
[\\/]* | [A-Za-z]:[\\/]*) qecho=$SHELL $progpath --fallback-echo;;
*) qecho=$SHELL `pwd`/$progpath --fallback-echo;;
 ---
   [\\/]* | [A-Za-z]:[\\/]*) qecho=$SHELL \$progpath\ 
 --fallback-echo;;
   *) qecho=$SHELL `pwd`/\$progpath\ --fallback-echo;;
 8559c8559
relink_command=(cd `pwd`; $SHELL $progpath $preserve_args 
 --mode=relink $libtool_args @inst_prefix_dir@)
 ---
   relink_command=(cd `pwd`; $SHELL \$progpath\ $preserve_args 
 --mode=relink $libtool_args @inst_prefix_dir@)
 
 The code changed in the two middle hunks went out after 2.2.6 and
 are thus gone in 2.2.8 and later, so that no longer applies.
 
 I also took the liberty of changing ltmain.m4sh instead of the
 generated libtool script.
 
 So, this is a better attempt for a patch, with Andreas added to
 THANKS.
 
 Ok to push?

Oops, forgot a couple of backslashes, trying again.

Sorry for the noise.

Testsuite running, just in case...

Cheers,
Peter

From 00ed0187c1c6cc3519188bc47d5ed0ff85f2d950 Mon Sep 17 00:00:00 2001
From: Peter Rosin p...@lysator.liu.se
Date: Sun, 19 Aug 2012 22:14:13 +0200
Subject: [PATCH] libtool: quote progpath properly

Attempt to handle spaces in paths better.

* build-aux/ltmain.m4sh (func_mode_install, func_mode_link): Quote
$progpath.
* THANKS: Update.
---
 THANKS|1 +
 build-aux/ltmain.m4sh |4 ++--
 2 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/THANKS b/THANKS
index 84cb6c9..24f1c91 100644
--- a/THANKS
+++ b/THANKS
@@ -70,6 +70,7 @@
   Alan Hourihane		al...@fairlite.co.uk
   Alexei Sheplyakov		v...@theor.jinr.ru
   Alon Bar-Lev			alon.bar...@gmail.com
+  Andreas Schiffler		aschiff...@ferzkopp.net
   Andreas Schwab		sch...@suse.de
   Andrey Slepuhin		p...@msu.ru
   Aneesh Kumar K.V		kvane...@hotmail.com
diff --git a/build-aux/ltmain.m4sh b/build-aux/ltmain.m4sh
index 30f99f4..48e259b 100644
--- a/build-aux/ltmain.m4sh
+++ b/build-aux/ltmain.m4sh
@@ -2449,7 +2449,7 @@ func_mode_install ()
 if test -n $current_libdirs; then
   # Maybe just do a dry run.
   $opt_dry_run  current_libdirs= -n$current_libdirs
-  exec_cmd='$SHELL $progpath $preserve_args --finish$current_libdirs'
+  exec_cmd='$SHELL $progpath $preserve_args --finish$current_libdirs'
 else
   exit $EXIT_SUCCESS
 fi
@@ -8506,7 +8506,7 @@ EOF
 	fi
   done
   # Quote the link command for shipping.
-  relink_command=(cd `pwd`; $SHELL $progpath $preserve_args --mode=relink $libtool_args @inst_prefix_dir@)
+  relink_command=(cd `pwd`; $SHELL \$progpath\ $preserve_args --mode=relink $libtool_args @inst_prefix_dir@)
   relink_command=`$ECHO $relink_command | $SED $sed_quote_subst`
   if test yes = $hardcode_automatic; then
 	relink_command=
-- 
1.7.9

Re: restore EXPORT check

[Peter Rosin]

Roumen Petrov skrev 2012-02-01 22:18:
 Ping ?
 
 Roumen Petrov wrote:
 Hi,
 now export test crash on mingw cross build as one of the patches change
 != to = when swap sides of test expression . As result incorrect
 export file (asyms) is used.

Indeed, thanks for the patch!

I have pushed the patch with the message, next time it would help if your
git commit had a better commit message and a valid author.  That just
might have gotten the patch commited sooner.

Cheers,
Peter


2012-02-02  Roumen Petrov bugtr...@roumenpetrov.info  (tiny change)

fixup: restore EXPORTS test

Commit v2.4.2-120-g962aa91
syntax-check: fix violations and implement 
sc_prohibit_test_const_follows_var
inadvertedly reversed the meaning of the comparison.

* build-aux/ltmain.m4sh (func_mode_link) [cygwin|mingw|cegcc]: Restore
the EXPORTS test.  We need to look at the symbols when it's _not_
already a .def file (in which case we trust the user input blindly).

Copyright-paperwork-exempt: Yes
Signed-off-by: Peter Rosin p...@lysator.liu.se

[PATCH] cwrapper: avoid duplicate strlen calculation.

[Peter Rosin]

Hi!

This is very close to obvious and I very nearly just pushed it out, but
what's the rush?  However, I will push under the 72h rule if noone
speaks up.

It fixes half the issues reported by the clang static analyzer for
my current pet project.

Cheers,
Peter

From a2e87f5bfed174de7d715dcf5ca5b51da4761e75 Mon Sep 17 00:00:00 2001
From: Peter Rosin p...@lysator.liu.se
Date: Mon, 30 Jan 2012 15:26:13 +0100
Subject: [PATCH] cwrapper: avoid duplicate strlen calculation.

* build-aux/ltmain.m4sh (func_emit_cwrapperexe_src:lt_update_exe_path):
Remove duplicate strlen calculation.

Signed-off-by: Peter Rosin p...@lysator.liu.se
---
 build-aux/ltmain.m4sh |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/build-aux/ltmain.m4sh b/build-aux/ltmain.m4sh
index 922e957..a34858a 100644
--- a/build-aux/ltmain.m4sh
+++ b/build-aux/ltmain.m4sh
@@ -4150,7 +4150,7 @@ lt_update_exe_path (const char *name, const char *value)
 {
   char *new_value = lt_extend_str (getenv (name), value, 0);
   /* some systems can't cope with a ':'-terminated path #' */
-  int len = strlen (new_value);
+  int len;
   while (((len = strlen (new_value))  0)  IS_PATH_SEPARATOR 
(new_value[len-1]))
 {
   new_value[len-1] = '\0';
-- 
1.7.5.1

Re: [PATCH] cwrapper: avoid duplicate strlen calculation.

[Peter Rosin]

[Sorry for replying to myself]

Peter Rosin skrev 2012-01-30 15:32:
 Hi!
 
 This is very close to obvious and I very nearly just pushed it out, but
 what's the rush?  However, I will push under the 72h rule if noone
 speaks up.
 
 It fixes half the issues reported by the clang static analyzer for
 my current pet project.
 
 Cheers,
 Peter
 
 From a2e87f5bfed174de7d715dcf5ca5b51da4761e75 Mon Sep 17 00:00:00 2001
 From: Peter Rosin p...@lysator.liu.se
 Date: Mon, 30 Jan 2012 15:26:13 +0100
 Subject: [PATCH] cwrapper: avoid duplicate strlen calculation.
 
 * build-aux/ltmain.m4sh (func_emit_cwrapperexe_src:lt_update_exe_path):
 Remove duplicate strlen calculation.

Hmmm, I like the following better, so I'm going to push that instead,
in case of silence.

Cheers,
Peter

From 7b945cfdaaad8a87a19fcf837dd4bc04f399b1ab Mon Sep 17 00:00:00 2001
From: Peter Rosin p...@lysator.liu.se
Date: Mon, 30 Jan 2012 15:49:05 +0100
Subject: [PATCH] cwrapper: avoid surplus strlen calculations.

* build-aux/ltmain.m4sh (func_emit_cwrapperexe_src:lt_update_exe_path):
Avoid surplus strlen calculations.

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

diff --git a/build-aux/ltmain.m4sh b/build-aux/ltmain.m4sh
index 922e957..00d063c 100644
--- a/build-aux/ltmain.m4sh
+++ b/build-aux/ltmain.m4sh
@@ -4151,9 +4151,9 @@ lt_update_exe_path (const char *name, const char *value)
   char *new_value = lt_extend_str (getenv (name), value, 0);
   /* some systems can't cope with a ':'-terminated path #' */
   int len = strlen (new_value);
-  while (((len = strlen (new_value))  0)  IS_PATH_SEPARATOR 
(new_value[len-1]))
+  while ((len  0)  IS_PATH_SEPARATOR (new_value[len-1]))
 {
-  new_value[len-1] = '\0';
+  new_value[--len] = '\0';
 }
   lt_setenv (name, new_value);
   XFREE (new_value);
-- 
1.7.5.1

Re: [PATCH] cwrapper: avoid duplicate strlen calculation.

[Peter Rosin]

Bob Friesenhahn skrev 2012-01-30 18:11:
 On Mon, 30 Jan 2012, Peter Rosin wrote:
 
 [Sorry for replying to myself]
 
 I do that often.
 
 * build-aux/ltmain.m4sh (func_emit_cwrapperexe_src:lt_update_exe_path):
 Remove duplicate strlen calculation.

 Hmmm, I like the following better, so I'm going to push that instead,
 in case of silence.
 
 Why wait?  Your patch looks fine to apply to me.

Why indeed :-)

Pushed, and thanks for looking!

Cheers,
Peter

Re: [PATCH 3/4] maint: pick XSI funcs at runtime, not configure time.

[Peter Rosin]

Gary V. Vaughan skrev 2011-11-25 09:57:
 Determine, on a function by function basis, what XSI features
 are available in the shell that is actually running the script,
 rather than the one that was picked at configure time by the
 re-execution engine.

Doesn't this mean that the libtool script will do a number of
extra forks each time it is run?  If that's the case, I would like
to know how that impacts the execution time on Cygwin/MinGW...

Cheers,
Peter

Re: [PATCH 3/4] maint: pick XSI funcs at runtime, not configure time.

[Peter Rosin]

Gary V. Vaughan skrev 2011-11-28 10:20:
 Hi Peter,
 
 On 28 Nov 2011, at 15:48, Peter Rosin wrote:
 Gary V. Vaughan skrev 2011-11-25 09:57:
 Determine, on a function by function basis, what XSI features
 are available in the shell that is actually running the script,
 rather than the one that was picked at configure time by the
 re-execution engine.

 Doesn't this mean that the libtool script will do a number of
 extra forks each time it is run?
 
 Well, yes and no.  There will be an extra 4 or 8 evals (depending
 on whether the XSI function is chosen) as libtool starts up when

That's the evals in sub-shells, right? Those with this pattern:

if $_use_fast_funcs  (eval ...) 2/dev/null
then
  eval '...

or this:

if (eval ...) 2/dev/null
then
  eval '...


 compared to 2.4.2, but the fast_funcs will each save a fork or
 two on every invocation compared to if libtool configure found a non-
 XSI shell when libtool was installed.  However, don't forget that
 almost always, libtool is generated by the configure script of the
 project that uses it, and the loss of seds, evals, and file renames
 at configure time to splice in the fast_funcs most likely means
 you'll be at a net win on total execution time for at least a couple
 of dozen libtool invocations.
 
 And let's not forget this actually fixes a bug... we've had reports
 of configure re-execing with a good shell (say /opt/bin/bash) and
 substituting in the XSI fast_funcs, but the libtool script doesn't
 have all the slow re-exec machinery and runs with /bin/sh which then
 chokes on the XSI extensions spliced in to libtool, unless the
 caller manually sets SHELL and CONFIG_SHELL in their environment
 before calling make (which is a bad idea for other reasons).
 
  If that's the case, I would like
 to know how that impacts the execution time on Cygwin/MinGW...
 
 I don't have access to Windows so I can't actually measure it, but
 I doubt that the difference will be noticeable for even a large
 project, and quite possibly a small project like libltdl that only
 runs libtool a hand full of times will actually be (imperceptibly)
 faster.

I think you are underestimating the Cygwin fork pain.

BTW, libltdl runs libtool more like 20 times, but I agree it's very
small and the number of forks will not matter much.

My typical use case is mid-sized at a magnitude or so larger, and
even there with a fork rate of approx 10-15 Hz as I'm seeing, it wouldn't
be too harsh with a couple of extra forks - a minutes or so on the
wall clock time. But it would really add to the pain on some
(hypothetical?) large project with thousands of libtool invocations.
That's all I'm saying, but *I* am not building any of those...

Hmm, looking closer, shouldn't _use_fast_funcs have some kind of lt
prefix?

Cheers,
Peter

Re: FYI: [PATCH] ltmain.sh: append relative path trailing slashes explicitly.

[Peter Rosin]

Gary V. Vaughan skrev 2011-11-14 11:44:
 A small refactoring necessary to enable upcoming changesets.
 
 Applied as obvious.
 
 In addition to being more idiomatic, and hence minimising

minimizing, I think US English is preferred.

 suprises, seeing the slash written explicity when appending to

surprises, explicitly

 the result of a relative path calculation is a lot more
 readable.
 * libltdl/config/general.m4sh (func_relative_path): Don't append
 an implicit trailing slash...
 * libltdl/config/ltmain.m4sh (func_mode_link): ...write it
 explicitly at the time of use.
 
 Signed-off-by: Gary V. Vaughan g...@gnu.org
 ---
  libltdl/config/general.m4sh |9 +++--
  libltdl/config/ltmain.m4sh  |2 +-
  2 files changed, 4 insertions(+), 7 deletions(-)
 
 diff --git a/libltdl/config/general.m4sh b/libltdl/config/general.m4sh
 index 40d5413..f1ee6e5 100644
 --- a/libltdl/config/general.m4sh
 +++ b/libltdl/config/general.m4sh
 @@ -221,9 +221,7 @@ func_normal_abspath ()
  }
  
  # func_relative_path SRCDIR DSTDIR
 -# generates a relative path from SRCDIR to DSTDIR, with a trailing
 -# slash if non-empty, suitable for immediately appending a filename
 -# without needing to append a separator.
 +# generates a relative path from SRCDIR to DSTDIR.
  # value returned in $func_relative_path_result
  func_relative_path ()
  {
 @@ -274,10 +272,9 @@ func_relative_path ()
fi
  
# Normalisation. If bindir is libdir, return empty string,
 -  # else relative path ending with a slash; either way, target
 -  # file name can be directly appended.
 +  # else relative path.
if test ! -z $func_relative_path_result; then
 -func_stripname './' '' $func_relative_path_result/
 +func_stripname './' '' $func_relative_path_result
  func_relative_path_result=$func_stripname_result
fi
  }
 diff --git a/libltdl/config/ltmain.m4sh b/libltdl/config/ltmain.m4sh
 index ca67c8a..24491a9 100644
 --- a/libltdl/config/ltmain.m4sh
 +++ b/libltdl/config/ltmain.m4sh
 @@ -8621,7 +8621,7 @@ EOF
 if test x$bindir != x ;
 then
   func_relative_path $install_libdir $bindir
 - tdlname=$func_relative_path_result$dlname
 + tdlname=$func_relative_path_result/$dlname
 else
   # Otherwise fall back on heuristic.
   tdlname=../bin/$dlname

This breaks if $func_relative_path_result is empty. Luckily I think
you fix that in the next commit (65f9e9a2 general.m4sh: relative path
to the same directory is `.'.), but between these two commits there
is brokenness.

This is just a note to future bisectors. :-)

Cheers,
Peter

Re: [PATCH 1/4] libtoolize: use only space delimited file lists.

[Peter Rosin]

Gary V. Vaughan skrev 2011-11-05 18:04:
 This next series of patches simplifies both Makefile.am and libtoolize.m4sh
 enough that manipulations of the file lists by libtoolize at install time
 become managable enough to do a nice rewrite of the config-build-aux rename
 patch that I'll get to next.
 
 By itself, this one is obvious enough.  The rest of the series each tackles
 one directory full of files and the various variables and functions used by
 libtoolize to copy files around, and for Makefile.am to install.
 
 As with the other series I posted today, I'll push all of these in 72 hours
 or more - subject to any review comments or other issues that need to be
 addressed first.
 
 We don't install any files with whitespace in their file name,
 so using colon delimited lists to make that possible was a
 premature optimisation and an unneeded complication.
 * libtoolize.m4sh (func_copy_some_files): Remove IFS twiddling,
 and just pull space delimited files in a for loop idiomatically.
 (func_massage_aclocal_DATA, func_install_pkgmacro_subproject)
 (func_install_pkgmacro_parent, func_install_pkgmacro_files)
 (func_massage_pkgltdl_files, func_massage_pkgconfig_files):
 Append to file lists with space delimiter.
 
 Signed-off-by: Gary V. Vaughan g...@gnu.org
 ---
  libtoolize.m4sh |   44 +---
  1 files changed, 13 insertions(+), 31 deletions(-)
 
 diff --git a/libtoolize.m4sh b/libtoolize.m4sh

*snip*

 @@ -819,7 +811,7 @@ func_install_pkgmacro_subproject ()
pkgmacro_header=putting macros in AC_CONFIG_MACRO_DIR, 
 \`$subproject_macro_dir'.
  fi
  
 -func_copy_some_files argz.m4:libtool.m4:ltdl.m4:$pkgmacro_files \
 +func_copy_some_files libtool.m4 ltdl.m4 $pkgmacro_files \

You don't mention why it's ok to drop argz.m4, is the drop intentional
or was argz.m4 just lost in the churn?

Cheers,
Peter

Re: [SCM] GNU Libtool branch, master, updated. v2.4-58-g789817d

[Peter Rosin]

Hi Gary,

Extreme nits follows, you have been warned...

Cheers,
Peter

Gary V. Vaughan skrev 2011-10-17 07:42:
 This is an automated email from the git hooks/post-receive script. It was
 generated because a ref change was pushed to the repository containing
 the project GNU Libtool.
 
 The branch, master has been updated
via  789817d512111d063981446efc7493ce87696bb3 (commit)
   from  ecb2ab031be600951c779cb37b885c911c7adb79 (commit)
 
 Those revisions listed above that are new to this repository have
 not appeared on any other notification email; so we list those
 revisions in full, below.
 
 - Log -
 commit 789817d512111d063981446efc7493ce87696bb3
 Author: Gary V. Vaughan g...@vaughan.pe
 Date:   Mon Oct 17 12:40:55 2011 +0700
 
 Make a note to use gnu/linux for version_type.
 
 * libltdl/m4/libtool.m4 (version_type): Add a comment to change
 version_type setting from 'linux' to 'gnu/linux' during the next
 destabilising code refactoring.
 * libltdl/config/ltmain.m4sh: ditto.
 
 Requested by Richard Stallman.
 
 ---
 
 Summary of changes:
  ChangeLog  |9 +
  libltdl/config/ltmain.m4sh |3 ++-
  libltdl/m4/libtool.m4  |   30 +++---
  3 files changed, 26 insertions(+), 16 deletions(-)
 
 diff --git a/ChangeLog b/ChangeLog
 index 5f0d76f..2d72150 100644
 --- a/ChangeLog
 +++ b/ChangeLog
 @@ -1,3 +1,12 @@
 +2011-10-17  Gary V. Vaughan  g...@gnu.org
 +
 + Make a note to use gnu/linux for version_type.
 + * libltdl/m4/libtool.m4 (version_type): Add a comment to change
 + version_type setting from 'linux' to 'gnu/linux' during the next
 + destabilising code refactoring.
 + * libltdl/config/ltmain.m4sh: ditto.
 + Requested by Richard Stallman.
 +
  2011-10-04  Bart Van Assche bvanass...@acm.org
  
   Typo fix - change func_apped into func_append
 diff --git a/libltdl/config/ltmain.m4sh b/libltdl/config/ltmain.m4sh
 index 054bb4c..f9f52e7 100644
 --- a/libltdl/config/ltmain.m4sh
 +++ b/libltdl/config/ltmain.m4sh
 @@ -6543,6 +6543,7 @@ func_mode_link ()
 # which has an extra 1 added just for fun
 #
 case $version_type in
 +  # correct linux to gnu/linux during the next big refactor

You're not following the whitespace convention of the surrounding code.

  darwin|linux|osf|windows|none)
   func_arith $number_major + $number_minor
   current=$func_arith_result
 @@ -6659,7 +6660,7 @@ func_mode_link ()
 versuffix=$major.$revision
 ;;
  
 - linux)
 +linux)  # correct to gnu/linux during the next big refactor

Dito.

 func_arith $current - $age
 major=.$func_arith_result
 versuffix=$major.$age.$revision
 diff --git a/libltdl/m4/libtool.m4 b/libltdl/m4/libtool.m4
 index 0de7f3c..a61f6de 100644
 --- a/libltdl/m4/libtool.m4
 +++ b/libltdl/m4/libtool.m4
 @@ -2247,7 +2247,7 @@ need_version=unknown
  
  case $host_os in
  aix3*)
 -  version_type=linux
 +  version_type=linux # correct to gnu/linux during the next big refactor
library_names_spec='${libname}${release}${shared_ext}$versuffix $libname.a'
shlibpath_var=LIBPATH
  
 @@ -2256,7 +2256,7 @@ aix3*)
;;
  
  aix[[4-9]]*)
 -  version_type=linux
 +  version_type=linux # correct to gnu/linux during the next big refactor
need_lib_prefix=no
need_version=no
hardcode_into_libs=yes
 @@ -2321,7 +2321,7 @@ beos*)
;;
  
  bsdi[[45]]*)
 -  version_type=linux
 +  version_type=linux # correct to gnu/linux during the next big refactor
need_version=no
library_names_spec='${libname}${release}${shared_ext}$versuffix 
 ${libname}${release}${shared_ext}$major $libname${shared_ext}'
soname_spec='${libname}${release}${shared_ext}$major'
 @@ -2460,7 +2460,7 @@ m4_if([$1], [],[
;;
  
  dgux*)
 -  version_type=linux
 +  version_type=linux # correct to gnu/linux during the next big refactor
need_lib_prefix=no
need_version=no
library_names_spec='${libname}${release}${shared_ext}$versuffix 
 ${libname}${release}${shared_ext}$major $libname$shared_ext'
 @@ -2513,7 +2513,7 @@ freebsd* | dragonfly*)
;;
  
  gnu*)
 -  version_type=linux
 +  version_type=linux # correct to gnu/linux during the next big refactor
need_lib_prefix=no
need_version=no
library_names_spec='${libname}${release}${shared_ext}$versuffix 
 ${libname}${release}${shared_ext}${major} ${libname}${shared_ext}'
 @@ -2524,7 +2524,7 @@ gnu*)
;;
  
  haiku*)
 -  version_type=linux
 +  version_type=linux # correct to gnu/linux during the next big refactor
need_lib_prefix=no
need_version=no
dynamic_linker=$host_os runtime_loader
 @@ -2585,7 +2585,7 @@ hpux9* | hpux10* | hpux11*)
;;
  
  interix[[3-9]]*)
 -  version_type=linux
 +  version_type=linux # correct to gnu/linux during the next 

Re: func_convert_file_cygwin_to_w32 woes

[Peter Rosin]

Den 2011-01-06 21:29 skrev Ralf Wildenhues:
 [ dropping libtool@ ]
 
 Hi Peter,
 
 thanks for working on this!
 
 * Peter Rosin wrote on Tue, Jan 04, 2011 at 05:44:58PM CET:
 Subject: [PATCH] Convert ranlib argument to toolchain format.
 
 --- a/libltdl/config/ltmain.m4sh
 +++ b/libltdl/config/ltmain.m4sh
 @@ -2412,6 +2412,8 @@ func_mode_install ()
  
# Set up the ranlib parameters.
oldlib=$destdir/$name
 +  func_to_tool_file $oldlib func_convert_file_msys_to_w32
 +  tool_oldlib=$func_to_tool_file_result
 
 Why does the $old_striplib command a few lines below this one not need
 to use $tool_oldlib?

Spot on (as usual), I managed to look past that one...

 Dan, can you try 'make install-strip'?
 
func_show_eval $install_prog \$file \$oldlib 'exit $?'
  
 @@ -8370,6 +8372,8 @@ EOF
  esac
done
  fi
 +func_to_tool_file $oldlib func_convert_file_msys_to_w32
 +tool_oldlib=$func_to_tool_file_result
  eval cmds=\$old_archive_cmds\
  
  func_len  $cmds
 [...]
 
 * Peter Rosin wrote on Wed, Jan 05, 2011 at 11:06:09AM CET:
 Den 2011-01-05 05:30 skrev Dan McMahill:
 On 1/4/2011 11:44 AM, Peter Rosin wrote:
 Ok, I found a couple of minutes to look at this. Can you check if this
 patch helps?

 (It still needs a ChangeLog etc...)
 
 The patch is OK with me if you fix the missing bits, and address the
 above.
 
 Before I tie up the lose ends with this patch, I wonder if Ralf (or someone
 else) could tell me if I should also fix the other assignments of
 old_archive_cmds -- such as in the below snippet -- or is that completely
 irrelevant?
 
 I wouldn't change them without being sure that the changes are
 necessary.

Well, they are necessary, but in cases which are, errhm, convoluted...

Such as: win32-hosted cross-tools (I mean native win32 here, not
dependent on Cygwin or MSYS) for targeting irix (or whatever) and
running them from Cygwin (or Wine) instead of MSYS.

I think I'll skip the extra changes, as someone doing the above needs
a clue-bat anyway.

Here's what I have now, I'm only awaiting input on the THANKS addition
from Dan.

Cheers,
Peter

From 6de4a15cecc38f0ba2ade4d3ac1d8a24e1160a31 Mon Sep 17 00:00:00 2001
From: Peter Rosin p...@lysator.liu.se
Date: Fri, 7 Jan 2011 09:00:10 +0100
Subject: [PATCH] Convert file name to toolchain format when blessing archives.

* libltdl/config/ltmain.m4sh (func_mode_install): When executing
old_postinstall_cmds and old_archive_cmds, convert $oldlib to a
format appropriate for the tool and provide that in $tool_oldlib.
Also use $tool_oldlib when stripping old libraries.
* libltdl/m4/libtool.m4 (_LT_CMD_OLD_ARCHIVE): Use $tool_oldlib
as argument to $RANLIB.
* THANKS: Update.
Report by Dan McMahill.

Signed-off-by: Peter Rosin p...@lysator.liu.se
---
 ChangeLog  |   12 
 THANKS |1 +
 libltdl/config/ltmain.m4sh |6 +-
 libltdl/m4/libtool.m4  |6 +++---
 4 files changed, 21 insertions(+), 4 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index 4a65c9e..bcbc448 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,15 @@
+2011-01-07  Peter Rosin  p...@lysator.liu.se
+
+   Convert file name to toolchain format when blessing archives.
+   * libltdl/config/ltmain.m4sh (func_mode_install): When executing
+   old_postinstall_cmds and old_archive_cmds, convert $oldlib to a
+   format appropriate for the tool and provide that in $tool_oldlib.
+   Also use $tool_oldlib when stripping old libraries.
+   * libltdl/m4/libtool.m4 (_LT_CMD_OLD_ARCHIVE): Use $tool_oldlib
+   as argument to $RANLIB.
+   * THANKS: Update.
+   Report by Dan McMahill.
+
 2011-01-02  Ralf Wildenhues  ralf.wildenh...@gmx.de
 
Bump copyright years.
diff --git a/THANKS b/THANKS
index 637decf..6b86c5d 100644
--- a/THANKS
+++ b/THANKS
@@ -88,6 +88,7 @@
   Christopher Hulbert  cchgroupm...@gmail.com
   Craig Tierneycraig.tier...@noaa.gov
   Dalibor Topicrobi...@kaffe.org
+  Dan McMahill mcmah...@mtl.mit.edu
   Daniel Reed  n...@ml.org
   Daniel Richard G.sk...@iskunk.org
   Dave Korndave.korn.cyg...@googlemail.com
diff --git a/libltdl/config/ltmain.m4sh b/libltdl/config/ltmain.m4sh
index 336d97b..476f553 100644
--- a/libltdl/config/ltmain.m4sh
+++ b/libltdl/config/ltmain.m4sh
@@ -2412,8 +2412,10 @@ func_mode_install ()
 
   # Set up the ranlib parameters.
   oldlib=$destdir/$name
+  func_to_tool_file $oldlib func_convert_file_msys_to_w32
+  tool_oldlib=$func_to_tool_file_result
 
-  func_show_eval $install_prog \$file \$oldlib 'exit $?'
+  func_show_eval $install_prog \$file \$tool_oldlib 'exit $?'
 
   if test -n $stripme  test -n $old_striplib; then
func_show_eval $old_striplib $oldlib 'exit $?'
@@ -8370,6 +8372,8 @@ EOF
esac
  done
fi
+   func_to_tool_file $oldlib

Re: func_convert_file_cygwin_to_w32 woes

[Peter Rosin]

Den 2011-01-07 09:02 skrev Peter Rosin:
 Den 2011-01-06 21:29 skrev Ralf Wildenhues:
 [ dropping libtool@ ]

 Hi Peter,

 thanks for working on this!

 * Peter Rosin wrote on Tue, Jan 04, 2011 at 05:44:58PM CET:
 Subject: [PATCH] Convert ranlib argument to toolchain format.

 --- a/libltdl/config/ltmain.m4sh
 +++ b/libltdl/config/ltmain.m4sh
 @@ -2412,6 +2412,8 @@ func_mode_install ()
  
# Set up the ranlib parameters.
oldlib=$destdir/$name
 +  func_to_tool_file $oldlib func_convert_file_msys_to_w32
 +  tool_oldlib=$func_to_tool_file_result

 Why does the $old_striplib command a few lines below this one not need
 to use $tool_oldlib?
 
 Spot on (as usual), I managed to look past that one...
 
 Dan, can you try 'make install-strip'?

func_show_eval $install_prog \$file \$oldlib 'exit $?'
  
 @@ -8370,6 +8372,8 @@ EOF
 esac
   done
 fi
 +   func_to_tool_file $oldlib func_convert_file_msys_to_w32
 +   tool_oldlib=$func_to_tool_file_result
 eval cmds=\$old_archive_cmds\
  
 func_len  $cmds
 [...]

 * Peter Rosin wrote on Wed, Jan 05, 2011 at 11:06:09AM CET:
 Den 2011-01-05 05:30 skrev Dan McMahill:
 On 1/4/2011 11:44 AM, Peter Rosin wrote:
 Ok, I found a couple of minutes to look at this. Can you check if this
 patch helps?

 (It still needs a ChangeLog etc...)

 The patch is OK with me if you fix the missing bits, and address the
 above.

 Before I tie up the lose ends with this patch, I wonder if Ralf (or someone
 else) could tell me if I should also fix the other assignments of
 old_archive_cmds -- such as in the below snippet -- or is that completely
 irrelevant?

 I wouldn't change them without being sure that the changes are
 necessary.
 
 Well, they are necessary, but in cases which are, errhm, convoluted...
 
 Such as: win32-hosted cross-tools (I mean native win32 here, not
 dependent on Cygwin or MSYS) for targeting irix (or whatever) and
 running them from Cygwin (or Wine) instead of MSYS.
 
 I think I'll skip the extra changes, as someone doing the above needs
 a clue-bat anyway.
 
 Here's what I have now, I'm only awaiting input on the THANKS addition
 from Dan.

Crap, this one should be better. install is generally not part of the
toolchain...

Cheers,
Peter

From ce87974b8e4315c296629578f9abd089fda60412 Mon Sep 17 00:00:00 2001
From: Peter Rosin p...@lysator.liu.se
Date: Fri, 7 Jan 2011 11:49:10 +0100
Subject: [PATCH] Convert file name to toolchain format when blessing archives.

* libltdl/config/ltmain.m4sh (func_mode_install): When executing
old_postinstall_cmds and old_archive_cmds, convert $oldlib to a
format appropriate for the tool and provide that in $tool_oldlib.
Also use $tool_oldlib when stripping old libraries.
* libltdl/m4/libtool.m4 (_LT_CMD_OLD_ARCHIVE): Use $tool_oldlib
as argument to $RANLIB.
* THANKS: Update.
Report by Dan McMahill.

Signed-off-by: Peter Rosin p...@lysator.liu.se
---
 ChangeLog  |   12 
 THANKS |1 +
 libltdl/config/ltmain.m4sh |6 +-
 libltdl/m4/libtool.m4  |6 +++---
 4 files changed, 21 insertions(+), 4 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index 4a65c9e..bcbc448 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,15 @@
+2011-01-07  Peter Rosin  p...@lysator.liu.se
+
+   Convert file name to toolchain format when blessing archives.
+   * libltdl/config/ltmain.m4sh (func_mode_install): When executing
+   old_postinstall_cmds and old_archive_cmds, convert $oldlib to a
+   format appropriate for the tool and provide that in $tool_oldlib.
+   Also use $tool_oldlib when stripping old libraries.
+   * libltdl/m4/libtool.m4 (_LT_CMD_OLD_ARCHIVE): Use $tool_oldlib
+   as argument to $RANLIB.
+   * THANKS: Update.
+   Report by Dan McMahill.
+
 2011-01-02  Ralf Wildenhues  ralf.wildenh...@gmx.de
 
Bump copyright years.
diff --git a/THANKS b/THANKS
index 637decf..6b86c5d 100644
--- a/THANKS
+++ b/THANKS
@@ -88,6 +88,7 @@
   Christopher Hulbert  cchgroupm...@gmail.com
   Craig Tierneycraig.tier...@noaa.gov
   Dalibor Topicrobi...@kaffe.org
+  Dan McMahill mcmah...@mtl.mit.edu
   Daniel Reed  n...@ml.org
   Daniel Richard G.sk...@iskunk.org
   Dave Korndave.korn.cyg...@googlemail.com
diff --git a/libltdl/config/ltmain.m4sh b/libltdl/config/ltmain.m4sh
index 336d97b..d9e1cd2 100644
--- a/libltdl/config/ltmain.m4sh
+++ b/libltdl/config/ltmain.m4sh
@@ -2412,11 +2412,13 @@ func_mode_install ()
 
   # Set up the ranlib parameters.
   oldlib=$destdir/$name
+  func_to_tool_file $oldlib func_convert_file_msys_to_w32
+  tool_oldlib=$func_to_tool_file_result
 
   func_show_eval $install_prog \$file \$oldlib 'exit $?'
 
   if test -n $stripme  test -n $old_striplib; then
-   func_show_eval $old_striplib $oldlib 'exit $?'
+   func_show_eval $old_striplib

Re: func_convert_file_cygwin_to_w32 woes

[Peter Rosin]

Den 2011-01-07 11:52 skrev Peter Rosin:
 Subject: [PATCH] Convert file name to toolchain format when blessing archives.
 
 * libltdl/config/ltmain.m4sh (func_mode_install): When executing
 old_postinstall_cmds and old_archive_cmds, convert $oldlib to a
 format appropriate for the tool and provide that in $tool_oldlib.
 Also use $tool_oldlib when stripping old libraries.
 * libltdl/m4/libtool.m4 (_LT_CMD_OLD_ARCHIVE): Use $tool_oldlib
 as argument to $RANLIB.
 * THANKS: Update.
 Report by Dan McMahill.
 
 Signed-off-by: Peter Rosin p...@lysator.liu.se

I got an OK from Dan off-list about the THANKS file, so I pushed this.

Cheers,
Peter

Re: func_convert_file_cygwin_to_w32 woes

[Peter Rosin]

Den 2011-01-07 17:55 skrev Charles Wilson:
 On 1/7/2011 3:02 AM, Peter Rosin wrote:
 Den 2011-01-06 21:29 skrev Ralf Wildenhues:
 * Peter Rosin wrote on Tue, Jan 04, 2011 at 05:44:58PM CET:
 Before I tie up the lose ends with this patch, I wonder if Ralf (or someone
 else) could tell me if I should also fix the other assignments of
 old_archive_cmds -- such as in the below snippet -- or is that completely
 irrelevant?

 I wouldn't change them without being sure that the changes are
 necessary.

 Well, they are necessary, but in cases which are, errhm, convoluted...

 Such as: win32-hosted cross-tools (I mean native win32 here, not
 dependent on Cygwin or MSYS) for targeting irix (or whatever) and
 running them from Cygwin (or Wine) instead of MSYS.

 I think I'll skip the extra changes, as someone doing the above needs
 a clue-bat anyway.
 
 Err...that's not really uncommon.  Take the following fer-instance:
   1) You use a vendor-provided gcc for your fav embedded target
   1a) naturally, it's a MinGW-$foo cross compiler
   2) But, you like to work from a cygwin shell because it doesn't suck
 as bad as dosbox, and provides tools that MSYS does not.
 
 Now, MOST of the time, if you're using a vendor-provided compiler,
 you're also going to use the vendor-provided IDE, so...the fact that you
 like to play in the cygwin shell doesn't matter; the IDE doesn't use
 your shell anyway.
 
 But...if you step outside of the IDE...say, you just want to use the
 normal configure/make process with --host=$foo
 CC=/path/to/vendor/bin/gcc, since you don't really want to set up an
 IDE project for $third-party-package-with-perfectly-good-autoconfigury,
 do you really need a cluebat?  Don't do that, download and install the
 (limited in functionality compared to cygwin) MSYS environment, even
 though you are not using real MinGW gcc, but a vendor toolchain?
 Or...a few more, already identified and well-understood changes in libtool?

Below is a patch that changes all old_archive_cmds assignments.

If you examine it for a bit you will notice that the special casing of
old_archive_cmds happens for major OSes like Solaris and Irix, which
are not very likely to end up on embedded systems.  Changing the default
old_archive_cmds will change things for cases which are more interesting
(at least for me), namely using the ar-lib wrapper to wrap MS lib.exe.
So, I'd have to do extensive tests before signing off on this patch.

BTW, I (consciously) didn't state on whom the cluebat should be applied,
and that could easily be me :-)  It's always good to have one lying
around.

One last note, my guess is that in the vast majority of cases, $oldlib
will be a relative path when old_archive_cmds is executed, thus making
the conversion a NOP anyway.

Cheers,
Peter


From 0d175d6a4e9b2d78e6b2f12543d62501efb4399c Mon Sep 17 00:00:00 2001
From: Peter Rosin p...@lysator.liu.se
Date: Fri, 7 Jan 2011 21:22:10 +0100
Subject: [PATCH] Convert to toolchain format when invoking the archiver.

---
 libltdl/m4/libtool.m4 |   18 +-
 1 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/libltdl/m4/libtool.m4 b/libltdl/m4/libtool.m4
index c144755..261c953 100644
--- a/libltdl/m4/libtool.m4
+++ b/libltdl/m4/libtool.m4
@@ -1441,7 +1441,7 @@ _LT_DECL([], [RANLIB], [1],
 [Commands used to install an old-style archive])
 
 # Determine commands to create old-style static archives.
-old_archive_cmds='$AR $AR_FLAGS $oldlib$oldobjs'
+old_archive_cmds='$AR $AR_FLAGS $tool_oldlib$oldobjs'
 old_postinstall_cmds='chmod 644 $oldlib'
 old_postuninstall_cmds=
 
@@ -5147,7 +5147,7 @@ _LT_EOF
# The linker will automatically build a .lib file if we build a DLL.
_LT_TAGVAR(old_archive_from_new_cmds, $1)='true'
# FIXME: Should let the user specify the lib program.
-   _LT_TAGVAR(old_archive_cmds, $1)='lib -OUT:$oldlib$oldobjs$old_deplibs'
+   _LT_TAGVAR(old_archive_cmds, $1)='lib 
-OUT:$tool_oldlib$oldobjs$old_deplibs'
_LT_TAGVAR(enable_shared_with_static_runtimes, $1)=yes
;;
   esac
@@ -6347,7 +6347,7 @@ if test $_lt_caught_CXX_error != yes; then
# CC -ar, where CC is the IRIX C++ compiler.  This is
# necessary to make sure instantiated templates are included
# in the archive.
-   _LT_TAGVAR(old_archive_cmds, $1)='$CC -ar -WR,-u -o $oldlib 
$oldobjs'
+   _LT_TAGVAR(old_archive_cmds, $1)='$CC -ar -WR,-u -o $tool_oldlib 
$oldobjs'
;;
   *)
if test $GXX = yes; then
@@ -6390,7 +6390,7 @@ if test $_lt_caught_CXX_error != yes; then
 
# Archives containing C++ object files must be created using
# CC -Bstatic, where CC is the KAI C++ compiler.
-   _LT_TAGVAR(old_archive_cmds, $1)='$CC -Bstatic -o $oldlib $oldobjs'
+   _LT_TAGVAR(old_archive_cmds, $1)='$CC -Bstatic -o $tool_oldlib 
$oldobjs'
;;
  icpc* | ecpc* )
# Intel C++
@@ -6500,7 +6500,7

Re: func_convert_file_cygwin_to_w32 woes

[Peter Rosin]

Den 2011-01-05 05:30 skrev Dan McMahill:
 On 1/4/2011 11:44 AM, Peter Rosin wrote:
 Den 2011-01-04 05:39 skrev Dan McMahill:
 On 1/2/2011 12:37 AM, Ralf Wildenhues wrote:
 Hi Dan,

 * Dan McMahill wrote on Sat, Jan 01, 2011 at 04:53:25AM CET:
 I am trying to build a program under cygwin but using the mingw tool
 chain in a fake cross build way.  In my configure environment, I have:

  export lt_cv_to_tool_file_cmd=func_convert_file_cygwin_to_w32

 as suggested by the libtool manual.  I'm using libtool 2.4.

 Everything goes smoothly until install time when libtool calls ranlib
 (the mingw one) on an absolute path and of course the cygwin absolute
 path doesn't make sense to the mingw ranlib.  I thought that's what the
 func_convert... bit was for.

 Please copy and paste 'libtool --mode={link,relink,install}' commands
 for the libraries and programs involved.  We may provide better help
 then.

 attached.

 Ok, I found a couple of minutes to look at this. Can you check if this
 patch helps?

 (It still needs a ChangeLog etc...)

 Cheers,
 Peter

 
 
 I'm not running a git version but applying the patch to the libtool-2.4
 I was using worked.  This seems to address the problem.
 
 Many thanks.

And thank you Dan, for confirming!  Is it ok to add your name to the THANKS
file?

Before I tie up the lose ends with this patch, I wonder if Ralf (or someone
else) could tell me if I should also fix the other assignments of
old_archive_cmds -- such as in the below snippet -- or is that completely
irrelevant?

Cheers,
Peter

  irix5* | irix6*)
case $cc_basename in
  CC*)
# SGI C++
_LT_TAGVAR(archive_cmds, $1)='$CC -shared -all -multigot 
$predep_objects $libobjs $deplibs $postdep_objects $compiler_flags -soname 
$soname `test -n $verstring  func_echo_all -set_version $verstring` 
-update_registry ${output_objdir}/so_locations -o $lib'

# Archives containing C++ object files must be created using
# CC -ar, where CC is the IRIX C++ compiler.  This is
# necessary to make sure instantiated templates are included
# in the archive.
_LT_TAGVAR(old_archive_cmds, $1)='$CC -ar -WR,-u -o $oldlib 
$oldobjs'
;;

Re: func_convert_file_cygwin_to_w32 woes

[Peter Rosin]

Den 2011-01-04 05:39 skrev Dan McMahill:
 On 1/2/2011 12:37 AM, Ralf Wildenhues wrote:
 Hi Dan,

 * Dan McMahill wrote on Sat, Jan 01, 2011 at 04:53:25AM CET:
 I am trying to build a program under cygwin but using the mingw tool
 chain in a fake cross build way.  In my configure environment, I have:

  export lt_cv_to_tool_file_cmd=func_convert_file_cygwin_to_w32

 as suggested by the libtool manual.  I'm using libtool 2.4.

 Everything goes smoothly until install time when libtool calls ranlib
 (the mingw one) on an absolute path and of course the cygwin absolute
 path doesn't make sense to the mingw ranlib.  I thought that's what the
 func_convert... bit was for.

 Please copy and paste 'libtool --mode={link,relink,install}' commands
 for the libraries and programs involved.  We may provide better help
 then.
 
 attached.

Ok, I found a couple of minutes to look at this. Can you check if this
patch helps?

(It still needs a ChangeLog etc...)

Cheers,
Peter

From 589ec246bb679612441a849d852b153cf4820466 Mon Sep 17 00:00:00 2001
From: Peter Rosin p...@lysator.liu.se
Date: Tue, 4 Jan 2011 17:39:06 +0100
Subject: [PATCH] Convert ranlib argument to toolchain format.

---
 libltdl/config/ltmain.m4sh |4 
 libltdl/m4/libtool.m4  |6 +++---
 2 files changed, 7 insertions(+), 3 deletions(-)

diff --git a/libltdl/config/ltmain.m4sh b/libltdl/config/ltmain.m4sh
index 336d97b..036fa1b 100644
--- a/libltdl/config/ltmain.m4sh
+++ b/libltdl/config/ltmain.m4sh
@@ -2412,6 +2412,8 @@ func_mode_install ()
 
   # Set up the ranlib parameters.
   oldlib=$destdir/$name
+  func_to_tool_file $oldlib func_convert_file_msys_to_w32
+  tool_oldlib=$func_to_tool_file_result
 
   func_show_eval $install_prog \$file \$oldlib 'exit $?'
 
@@ -8370,6 +8372,8 @@ EOF
esac
  done
fi
+   func_to_tool_file $oldlib func_convert_file_msys_to_w32
+   tool_oldlib=$func_to_tool_file_result
eval cmds=\$old_archive_cmds\
 
func_len  $cmds
diff --git a/libltdl/m4/libtool.m4 b/libltdl/m4/libtool.m4
index 4239395..c144755 100644
--- a/libltdl/m4/libtool.m4
+++ b/libltdl/m4/libtool.m4
@@ -1448,13 +1448,13 @@ old_postuninstall_cmds=
 if test -n $RANLIB; then
   case $host_os in
   openbsd*)
-old_postinstall_cmds=$old_postinstall_cmds~\$RANLIB -t \$oldlib
+old_postinstall_cmds=$old_postinstall_cmds~\$RANLIB -t \$tool_oldlib
 ;;
   *)
-old_postinstall_cmds=$old_postinstall_cmds~\$RANLIB \$oldlib
+old_postinstall_cmds=$old_postinstall_cmds~\$RANLIB \$tool_oldlib
 ;;
   esac
-  old_archive_cmds=$old_archive_cmds~\$RANLIB \$oldlib
+  old_archive_cmds=$old_archive_cmds~\$RANLIB \$tool_oldlib
 fi
 
 case $host_os in
-- 
1.7.2.3