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

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

[Peter Rosin]

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

Then, when you have found an nm/flags combo (or if the user has provided
it), and this part was already ok in the patch, you make libtool detect if
the $NM interface is posix, bsd, MS dumpbin or ..., and build the symbol
pipe accordingly.

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

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 >&AS_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 
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 
---
 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 2>&1 | 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 2>&1 | 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: git commit forces bootstrap

[Peter Rosin]

On 2013-12-09 04:37, Gary V. Vaughan wrote:
> On Dec 9, 2013, at 11:52 AM, Peter Rosin  wrote:
>> ok to push?
> 
> Just to reiterate: I found the barrier for contributing to libtool had
> become insanely high in years past, to the point where even I found it
> hard to motivate myself to push the smallest of straight forward patches
> through...

I haven't tested the patch on an in-tree build, so I figured I'd just
post it instead of pushing it directly. I was heading for the sack
anyway, and had no rush. However, since you had the same patch lined
up, I have now simply pushed it out without in-tree testing. As you
say below, it's easy enough to clean up it case of minor screw ups.

> Nowadays: git makes it very easy to fix up an error after the fact, and
> I want to knock down the barrier, so if you have made a good effort to
> test your patches, and you have a commit bit, just go ahead and push...
> unless you are worried your patch is not right conceptually or something.

Agreed!

Cheers,
Peter

Re: bootstrap breakage starting with fec7d87

[Peter Rosin]

On 2013-11-20 00:32, Gary V. Vaughan wrote:
> Hi Ozkan, Petor,
> 
> On Nov 19, 2013, at 11:57 PM, Peter Rosin  wrote:
> 
>> 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.
> 
> Ouch, sorry about that.
> 
>> 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...
> 
> I don't have access to any Windows environments, but your patch works
> correctly for me on various flavours of  Mac OS, GNU/Linux, Solaris, HPUX,
> and AIX -- I no longer have access to Tru64 Unix, SCO Unix or IRIX.
> 
> Thanks for the quick fix.  Assuming it works on cygwin, mingw and other
> windows variants we support, please go ahead and push.

Works on Cygwin, so pushed. During patch development I tested various
multi-dotted version numbers with various difficulties of the
4.82.620 vs 4.82.2000, 2.82 vs 10.7 and 4.10 vs 4.100 kind, as well
as some simple ones of the 5 vs 8 and 4.3 vs 4.8 variety.

*checks some more*

Hmmm, just checked 1.4.4a vs 1.4-p3a, and the new sort thinks 1.4-p3a
is lesser, which is good I suppose. But the function comment is no longer
accurate...

I don't know what to write instead in that comment, but with the new
sort 1.4-p12a < 1.4-p3a, which looks about as bad as 1.4.4a < 1.4-p3a.
Maybe like this:


diff --git a/bootstrap b/bootstrap
index 852efd5..ca2bb11 100755
--- a/bootstrap
+++ b/bootstrap
@@ -1312,9 +1312,9
 # func_sort_ver VER1 VER2
 # ---
 # 'sort -V' is not generally available.
 # Note this deviates from the version comparison in automake
-# in that it treats 1.5 < 1.5.0, and treats 1.4.4a < 1.4-p3a
+# in that it treats 1.5 < 1.5.0, and treats 1.4-p12a < 1.4-p3a
 # but this should suffice as we won't be specifying old
 # version formats or redundant trailing .0 in bootstrap.conf.
 # If we did want full compatibility then we should probably
 # use m4_version_compare from autoconf.


But I'm not sure if m4_version_compare handles p12a vs p3a, so
I'll leave this for Gary to clean up.

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

[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 
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 
---
 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: 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 
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++] 
: 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.
  

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 
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++] 
: 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 2>&1 | $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

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

[Peter Rosin]

On 2013-08-22 17:48, Alan Modra wrote:
> On Thu, Aug 22, 2013 at 09:34:10PM +0700, Gary V. Vaughan wrote:
>>> 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?
> 
> As far as I understand, this piece of libtool is supplying ld options
> when your host compiler defaults to something other than what $host
> implies.  Which sounds very strange, but consider that on a
> powerpc64-linux host your gcc will usually compile to both 32-bit and
> 64-bit objects.  Both 32-bit and 64-bit objects will run on the host,
> and whether gcc produces 32-bit by default (most common a few years
> ago) or 64-bit (most common now), depends on how gcc was configured.
> 
> So if $host is powerpc64-linux and $CC is gcc and gcc produces 64-bit
> by default, and $LD is powerpc64-linux-ld then no ld options are
> needed.  When generating 32-bit libraries on this system, $host is
> powerpc-linux, $CC is still gcc, and $LD may be powerpc-linux-ld.
> That's a problem because $CC with no options produces 64-bit objects
> but $LD with no options is expecting 32-bit.
> 
> This is all somewhat of a guess on my part, but I've seen these $LD
> and $CC selections.  Most configure scripts seem to prefer
> "powerpc64-linux-ld" over plain "ld" when $host is powerpc64-linux,
> and similarly "powerpc-linux-ld" for $host of powerpc-linux.

Sheesh. You are lying about $host, and get to keep all the pieces when
it breaks. If you have host=powerpc64le-*, but the compiler produces
powerpcle-* output, then why on earth didn't you say host=powerpcle-*
from the beginning? And when there is an obvious mismatch between $host
and the compiler output, that seems like a reason to abort to me, and
not a reason to use the obviously wrong value of $host to infer
something about what the compiler produces and spread the lie to ld.

I mean, if the compiler produces powerpcle output and $host matches
powerpc64-*, it is just dead wrong to feed -m elf32ppclinux to ld.
And similar for other three cases of crossing both the 32/64 boundary
and the endian boundary.

Taking one example I know of (I'm sure there are plenty), my Octave will
print this (among other things) when it starts up:

Octave was configured for "i686-pc-cygwin".

I bet this is just a copy of $host. If you lie about $host when you
build software, that lie is going to spread like mad. So, there are
multiple reasons why this model is not sane. The only sane model is
to trust $host.

If you are building for 32le, say host=powerpcle-*
If you are building for 32be, say host=powerpc-*
If you are building for 64le, say host=powerpc64le-*
If you are building for 64be, say host=powerpc64-*

If you then want to avoid the cross-compile mode of autotools (which
is what all this boils down to, methinks), it is probably better to lie
about $build, it is not used nearly as much as $host. 

I realize that it is probably too late for the above. Sad. And I haven't
tried any of it either, so no doubt it's going to fail in some spectacular
way, but it seems much saner to me...

Given all the pain the "avoid cross-compile mode at all costs" mentality
is causing, it would be really nice if autotools could be taught (or told
how) to run run-time checks even in cross-compile mode, whenever that is
possible to do as in cases like this.

Crosses to MinGW from Cygwin or *ix with Wine come to mind as other
examples when people lie about $host/$build to evade the cross-compile
mode.

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

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: 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: [PATCH] Fix conversion warnings in cwrapper

[Peter Rosin]

On 2013-05-28 09:07, Peter Rosin wrote:
> 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.

It has now been cleared up, and I have thus pushed the attached.

Cheers, and thanks,
Peter

>From c37bc1a334661d58a35b4520ad0c98d5ccc23e7d Mon Sep 17 00:00:00 2001
From: Yaakov Selkowitz 
Date: Mon, 17 Jun 2013 23:46:54 +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.
THANKS: Update.

Signed-off-by: Yaakov Selkowitz 
Signed-off-by: Peter Rosin 
---
 THANKS  |1 +
 build-aux/ltmain.in |   22 +++++-----
 2 files changed, 10 insertions(+), 13 deletions(-)

diff --git a/THANKS b/THANKS
index 040c6d1..d6f9153 100644
--- a/THANKS
+++ b/THANKS
@@ -61,6 +61,7 @@
   Peter Rosin			p...@lysator.liu.se		  2005-04-12
   Tim Rice			t...@multitalents.net		  2005-11-10
   Eric Blake			e...@byu.net			  2006-01-18
+  Yaakov Selkowitz		yselkow...@users.sourceforge.net  2009-07-30
 
 
 * The following additional people made especially gracious contributions of
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);
  

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 
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 
Co-authored-by: Peter Rosin 
---
 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 

Re: [PATCH] Fix conversion warnings in cwrapper

[Peter Rosin]

On 2013-05-21 00:49, Yaakov (Cygwin/X) wrote:
> From: Yaakov Selkowitz 
> 
> Signed-off-by: Yaakov Selkowitz 
> ---
>  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 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-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-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 
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 
---
 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 2>&1 | 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 2>&1 | sed '1q'` in
 	  */dev/null*)
 	lt_cv_path_NM="$tmp_nm -p"
-	break
+	break 2
 	;;
 	  *)
 	lt_cv_path_NM=${lt_cv_path_NM="$tmp_nm"} # keep the first match, but
-- 
1.7.9

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

[Peter Rosin]

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?

(patch untested)

Cheers,
Peter

diff --git a/m4/libtool.m4 b/m4/libtool.m4
index 3f50b0c..a8a71da 100644
--- a/m4/libtool.m4
+++ b/m4/libtool.m4
@@ -3383,8 +3383,9 @@ else
   if test -n "$ac_tool_prefix" && test "$build" = "$host"; then
 lt_nm_to_check="$lt_nm_to_check nm"
   fi
+  lt_save_ifs=$IFS
   for lt_tmp_nm in $lt_nm_to_check; do
-lt_save_ifs=$IFS; IFS=$PATH_SEPARATOR
+IFS=$PATH_SEPARATOR
 for ac_dir in $PATH /usr/ccs/bin/elf /usr/ccs/bin /usr/ucb /bin; do
   IFS=$lt_save_ifs
   test -z "$ac_dir" && ac_dir=.
@@ -3397,13 +3398,13 @@ else
 	case `"$tmp_nm" -B /dev/null 2>&1 | 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 2>&1 | 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
@@ -3416,6 +3417,7 @@ else
 done
 IFS=$lt_save_ifs
   done
+  IFS=$lt_save_ifs
   : ${lt_cv_path_NM=no}
 fi])
 if test no != "$lt_cv_path_NM"; then

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

[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)
: 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 

# 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  

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

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

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

[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 
---
 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 2>&1; then
 v=UNKNOWN
+else
+v=$fallback
 fi
 
 v=`echo "$v" |sed "s/^$prefix//"`
-- 
1.7.9

[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 
---
 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 2>&1; 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 2>&1; then  \
  cd $(srcdir) &&   \
  git submodule --quiet foreach \
  test '"$$(git rev-parse "$$sha1")"'   \
-- 
1.7.9

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

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

[PATCH v3 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 
---
 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 2>&1; 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 2>&1; then  \
  cd $(srcdir) &&   \
  git submodule --quiet foreach \
  test '"$$(git rev-parse "$$sha1")"'   \
-- 
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 
---
 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 2>&1; then
 v=UNKNOWN
+else
+v=$fallback
 fi
 
 v=`echo "$v" |sed "s/^$prefix//"`
-- 
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 
---
 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 2>&1; then
 v=UNKNOWN
+else
+v=$fallback
 fi
 
 v=`echo "$v" |sed "s/^$prefix//"`
-- 
1.7.9

[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 
---
 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 2>&1; 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 2>&1; then  \
  cd $(srcdir) &&   \
  git submodule --quiet foreach \
  test '"$$(git rev-parse "$$sha1")"'   \
-- 
1.7.9

[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

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 2>&1".

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

Re: git-version-gen w/o git

[Peter Rosin]

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

Cheers,
Peter

[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 
---
 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"' < "$nlist"S > "$nlist"I'
+ 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 "$nlist"I; 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 *) \&&;/' < "$nlist"I >> "$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 "$nlist"I; then
+   echo >> "$output_objdir/$my_dlsyms" "\
+  {\"@INIT@\", (void *) <_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 (sym

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

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

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

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  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*)¬hing;
>> #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]

 0},
  {"@INIT@", (void *) <_syminit},
  {"hello-2.dll", (void *) 0},
  {"foo", (void *) &foo},
  {"hello", (void *) &hello},
  {"nothing", (void *) 0},
  {0, (void *) 0}
};

/* This works around a problem in FreeBSD linker */
#ifdef FREEBSD_WORKAROUND
static const void *lt_preloaded_setup() {
  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 
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 "$nlist"S; then
-	eval "$global_symbol_to_cdecl"' < "$nlist"S >> "$output_objdir/$my_dlsyms"'
+	eval "$global_symbol_to_cdecl"' < "$nlist"S' | $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 "$nlist"S; then
+	eval "$global_symbol_to_cdecl"' < "$nlist"S' | $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 *) <_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:
-	  

Re: git-version-gen w/o git

[Peter Rosin]

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.

Here's an update of the gnulib parts, with long lines wrapped and
a scriptversion update.

--- gnulib/build-aux/git-version-gen.orig   2012-10-02 17:10:58.935840500 
+0200
+++ gnulib/build-aux/git-version-gen2012-10-18 15:47:40.711565800 +0200
@@ -1,6 +1,6 @@
 #!/bin/sh
 # Print a version string.
-scriptversion=2012-03-18.17; # UTC
+scriptversion=2012-10-18.13; # UTC
 
 # Copyright (C) 2007-2012 Free Software Foundation, Inc.
 #
@@ -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 15:26:50.200179600 +0200
@@ -1327,7 +1327,8 @@
 
 .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 +1346,8 @@
 # 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

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)'  \

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

Re: Windows Line Endings

[Peter Rosin]

[I'm going to try to only respond to the technical sides of this]

On 2012-10-09 22:51, Roumen Petrov wrote:
> Peter Rosin wrote:
>> 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.
> 
> Did you think that world to follow you stupid patches ?

I'm not sure how I should parse that, but are you saying that
you have not checked if git-master works for you after the
last change?

> It is enough do throw out you commits to bring system in stable state again.

No, because reverting them leaves the testsuite broken on
Windows. That's not stable.

>>> 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
> 
> You even didn't wait  72 hours for feedback !
> 
> Each of you recent "obvious (!!)"  patches break libtool.

I apologize for breaking things for you, and I hope that I have
repaired it. However, I will defend my changes with the fact that
the testsuite was broken before I committed anything, and that I
consider the whole testsuite to currently by in an abnormal state
of flux after the big changes by Gary, which relaxes the commit
rules considerably. My commits fixes real problems, and if the
testsuite is working for your linux->mingw setup as of now (which
is unclear, please test), then it is apparent that it will not work
for you if you yank all my patches from the last month or so.

>> 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,
> 
> Exactly .
> 
>> and that the test failed with the patch.
> Exactly after you fluctuations .
> 
>> 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).
> 
> You must investigate more why in this particular case LT_AT_HOST_DATA fail in 
> you environment .

LT_AT_HOST_DATA does not fail, it creates \r\n line endings just
fine. It is then a fact that in MSYS "/bin/grep -E" clobbers the
newlines to \n, while on your Linux system that doesn't happen.
I'm sure there are good reasons for the MSYS grep to use text
mode. So, in this case LT_AT_HOST_DATA is unusable as is, since
it doesn't know whether to create \r\n or \n line endings.

>> So, the newlines has to be normalized after the $EGREP, or the
>> test has to be rewritten in a deeper way.
> 
> Take care that LT_AT_HOST_DATA is used more then once !

So is LT_AT_UNIFY_NL, what's your point? LT_AT_UNIFY_NL is for
when the line ending style is hard to predict, as in this case.

BTW, do you realize that I added the LT_AT_HOST_DATA invocations
that you are now championing?

>> 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?
> You just wrote to the world that you don't know author of LT_AT_HOST_DATA !
> 
> "Ralf did not write the code I'm changing here" - ha ha ha .

Well, it's a fact that Gary wrote the code I'm cha

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]

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.

>From 0f31e375104b00a181557d3809e556066b3d98b1 Mon Sep 17 00:00:00 2001
From: Peter Rosin 
Date: Mon, 8 Oct 2012 13:10:02 +0200
Subject: [PATCH] tests: rerefix line ending problems on MinGW.

The previous commit broke Linux->MinGW cross-compiling.
Report by Roumen Petrov.

* tests/mdemo.at: Normalize line endings after $EGREP.

Signed-off-by: Peter Rosin 
---
 tests/mdemo.at |   12 +---
 1 files changed, 9 insertions(+), 3 deletions(-)

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

-# Not using LT_AT_HOST_DATA below, since $EGREP normalizes line endings.
+# Normalize line endings after $EGREP instead of using LT_AT_HOST_DATA
+# here, since $EGREP *may* normalize line endings for us.
 AT_DATA([expout],
 [[Welcome to GNU libtool mdemo2!
 module name: foo1
@@ -849,9 +850,14 @@ LT_AT_CHECK_CONFIG([--with-included-ltdl])

 LT_AT_MAKE

-LT_AT_EXEC_CHECK([./mdemo2_static], 0, [expout], [],
+LT_AT_EXEC_CHECK([./mdemo2_static], 0, [stdout], [],
 [./foo1.la ./libfoo2.la | $EGREP -v '^module filename: '])
-LT_AT_EXEC_CHECK([./mdemo2], 0, [expout], [],
+LT_AT_UNIFY_NL([stdout])
+LT_AT_CHECK([diff expout stdout])
+
+LT_AT_EXEC_CHECK([./mdemo2], 0, [stdout], [],
 [./foo1.la ./libfoo2.la | $EGREP -v '^module filename: '])
+LT_AT_UNIFY_NL([stdout])
+LT_AT_CHECK([diff expout stdout])

 AT_CLEANUP
--
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 
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 
---
 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: 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  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 
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 
---
 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

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"  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 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-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: 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  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 


> 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: [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: [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... (cac

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

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

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 
>>>> ---
>>>>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: [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 
>>> ---
>>>   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 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 
>> ---
>>   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: 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 
>> ---
>>   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: 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  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 
>>>> ---
>>>> 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 
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 stomp

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 
>> ---
>>  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 
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: 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  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 see "  " as 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 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 
> ---
>  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

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

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

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]

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

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

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