GNU bug report logs - #13414
Valid DLL def file mangled by libtool

Previous Next

To reply to this bug, email your comments to 13414 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Martin Doucha <doucha <at> integri.cz>
To: bug-libtool <at> gnu.org
Subject: Valid DLL def file mangled by libtool
Date: Fri, 11 Jan 2013 12:34:26 +0100

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.

Regards,
Martin Doucha

Message #8 received at 13414 <at> debbugs.gnu.org (full text, mbox):

From: Peter Rosin <peda <at> lysator.liu.se>
To: Martin Doucha <doucha <at> integri.cz>
Cc: 13414 <at> debbugs.gnu.org
Subject: Re: bug#13414: Valid DLL def file mangled by libtool
Date: Sat, 12 Jan 2013 01:26:10 +0100

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

Cheers,
Peter

Message #11 received at 13414 <at> debbugs.gnu.org (full text, mbox):

From: Peter Rosin <peda <at> lysator.liu.se>
To: Earnie Boyd <earnie <at> users.sourceforge.net>
Cc: 13414 <at> debbugs.gnu.org
Subject: Re: bug#13414: Valid DLL def file mangled by libtool
Date: Mon, 14 Jan 2013 15:13:37 +0100

On 2013-01-13 16:56, Earnie Boyd wrote:
> On Fri, Jan 11, 2013 at 7:26 PM, Peter Rosin wrote:
>>         $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...)
> 
> Does GCC DTRT with LIBRARY?  Or is anyone using libtool with MSVC?

A short while binutils required "LIBRARY", if present, to be the first
statement in the .def file (which is a requirement consistent with
MSDN). I believe this requirement has been lifted from binutils.

I'm using libtool with MSVC, but I have never used a LIBRARY statement
myself.

> I.E.: The file containing LIBRARY tells the link command to create a
> DLL and the import library file (unless a .exp file is also used) but
> only if the /DLL switch is used.

I don't understand this, I thought the /DLL switch accomplished most of
that by itself? I thought LIBRARY only provided the library name, which
can also be specified on the command line (using the -Fe option to cl.exe
or the -OUT option to link.exe). Since the command line overrides the
LIBRARY statement, it seems a bit useless from the libtool p.o.v. as
libtool is always providing the library name on the command line. No?

To me, this is only about libtool recognizing preexisting .def files
that are written without libtool in mind (or at least, not with only
libtool in mind), and not about supporting constructs in .def that are
actually needed by libtool. From the libtool side, the .def file needs
to (currently) start with EXPORTS, and since LIBRARY (and NAME)
statements are of no use to libtool they might just as well be zapped
so that EXPORTS actually is first. But if you want to use the same .def
file from a non-libtool setting, you might have some very good reason
to include LIBRARY (or NAME) in it, and then you'd want to have that
as the first statement (according to MSDN). But that kills things in
libtool, since it then prepends a faulty EXPORTS to the .def file (it's
wrongly assuming that the perfectly fine .def file is a plain symbol
list when the file doesn't start with EXPORTS).

I might easily be missing something...

Cheers,
Peter

Message #14 received at 13414 <at> debbugs.gnu.org (full text, mbox):

From: Earnie Boyd <earnie <at> users.sourceforge.net>
To: Peter Rosin <peda <at> lysator.liu.se>
Cc: 13414 <at> debbugs.gnu.org
Subject: Re: bug#13414: Valid DLL def file mangled by libtool
Date: Wed, 16 Jan 2013 10:03:23 -0500

On Mon, Jan 14, 2013 at 9:13 AM, Peter Rosin wrote:
> On 2013-01-13 16:56, Earnie Boyd wrote:
>> On Fri, Jan 11, 2013 at 7:26 PM, Peter Rosin wrote:
>>>         $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...)
>>
>> Does GCC DTRT with LIBRARY?  Or is anyone using libtool with MSVC?
>
> A short while binutils required "LIBRARY", if present, to be the first
> statement in the .def file (which is a requirement consistent with
> MSDN). I believe this requirement has been lifted from binutils.
>

Yes, based on the documentation LIBRARY should be the first line of
the file and the name is optional.

> I'm using libtool with MSVC, but I have never used a LIBRARY statement
> myself.
>

This alone is enough for libtool to consider it.

>> I.E.: The file containing LIBRARY tells the link command to create a
>> DLL and the import library file (unless a .exp file is also used) but
>> only if the /DLL switch is used.
>
> I don't understand this, I thought the /DLL switch accomplished most of
> that by itself? I thought LIBRARY only provided the library name, which
> can also be specified on the command line (using the -Fe option to cl.exe
> or the -OUT option to link.exe). Since the command line overrides the
> LIBRARY statement, it seems a bit useless from the libtool p.o.v. as
> libtool is always providing the library name on the command line. No?
>

So even though it exists it should be pretty much meaningless to libtool.

> To me, this is only about libtool recognizing preexisting .def files
> that are written without libtool in mind (or at least, not with only
> libtool in mind), and not about supporting constructs in .def that are
> actually needed by libtool. From the libtool side, the .def file needs
> to (currently) start with EXPORTS, and since LIBRARY (and NAME)
> statements are of no use to libtool they might just as well be zapped
> so that EXPORTS actually is first. But if you want to use the same .def
> file from a non-libtool setting, you might have some very good reason
> to include LIBRARY (or NAME) in it, and then you'd want to have that
> as the first statement (according to MSDN). But that kills things in
> libtool, since it then prepends a faulty EXPORTS to the .def file (it's
> wrongly assuming that the perfectly fine .def file is a plain symbol
> list when the file doesn't start with EXPORTS).

There can be only one LIBRARY statement and it must be on the first
non-empty line of the file.

However from http://msdn.microsoft.com/en-us/library/hyx1zcd3(v=vs.71).aspx
we see:

The EXPORTS statement introduces a section of one or more definitions
that are exported functions or data. Each definition must be on a
separate line. The EXPORTS keyword can be on the same line as the
first definition or on a preceding line. The .def file can contain one
or more EXPORTS statements.

Notice the last sentence of the quote.  Also notice that the first
definition can be on the same line as the EXPORTS keyword.

-- 
Earnie
-- https://sites.google.com/site/earnieboyd

Message #17 received at 13414 <at> debbugs.gnu.org (full text, mbox):

From: Peter Rosin <peda <at> lysator.liu.se>
To: Earnie Boyd <earnie <at> users.sourceforge.net>
Cc: 13414 <at> debbugs.gnu.org
Subject: Re: bug#13414: Valid DLL def file mangled by libtool
Date: Fri, 18 Jan 2013 11:29:43 +0100

On 2013-01-16 16:03, Earnie Boyd wrote:
> On Mon, Jan 14, 2013 at 9:13 AM, Peter Rosin wrote:
>> On 2013-01-13 16:56, Earnie Boyd wrote:
>>> On Fri, Jan 11, 2013 at 7:26 PM, Peter Rosin wrote:
>>>>         $SED -n \
>>>>             -e '/^[     ]*//' \
>>>>             -e '/^;/D' \
>>>>             -e '/^$/D' \
>>>>             -e 's/^EXPORTS.*/DEF/p' \
>>>>             -e 's/^LIBRARY.*/DEF/p' \
>>>>             -e q \
>>>>             $export_symbols

After some experimenting, I now have:

	$SED -n \
	    -e 's/^[ 	]*//' \
	    -e '/^\(;.*\)*$/d' \
	    -e 's/^\(EXPORTS\|LIBRARY\)\([ 	].*\)*$/DEF/p' \
	    -e q \
	    $export_symbols


>> I'm using libtool with MSVC, but I have never used a LIBRARY statement
>> myself.
>>
> 
> This alone is enough for libtool to consider it.

Consider what? Did you forget a negation?

>>> I.E.: The file containing LIBRARY tells the link command to create a
>>> DLL and the import library file (unless a .exp file is also used) but
>>> only if the /DLL switch is used.
>>
>> I don't understand this, I thought the /DLL switch accomplished most of
>> that by itself? I thought LIBRARY only provided the library name, which
>> can also be specified on the command line (using the -Fe option to cl.exe
>> or the -OUT option to link.exe). Since the command line overrides the
>> LIBRARY statement, it seems a bit useless from the libtool p.o.v. as
>> libtool is always providing the library name on the command line. No?
>>
> 
> So even though it exists it should be pretty much meaningless to libtool.

I did some tests to see how LIBRARY affects things and it turns out it
is not meaningless. What the MSDN documentation appears to mean is that
if you do not specify any library name on the command line, the LIBRARY
statements set the name of the DLL file. But the name referred to inside
the import library will always be the name provided with the LIBRARY
statement, regardless of any command line options.

I.e., when libtool is called like this:

	./libtool --mode=link ./compile cl foo.lo -o foo.la \
	-no-undefined -rpath /nowhere

the relevant parts (after going through a bunch of layers) with a
libtool configured for MSVC is:

	cl .libs/foo.obj -Fe.libs/foo-0.dll \
	-link -dll -implib:.libs/foo.dll.lib

(which means, link foo.obj into a -dll named foo-0.dll and also generate
an import library named foo.dll.lib)

If you then mix in a .def file starting with

	LIBRARY bar

you will get the same names of the files (foo-0.dll and foo.dll.lib), but
executables linked with foo.dll.lib will require the non-existing bar.dll
at runtime.

Similarly, the relevant parts with a libtool configured for GNU is:

	gcc -shared .libs/a.o -o .libs/cyga-0.dll \
	-Xlinker --out-implib -Xlinker .libs/liba.dll.a

and mixing in a .def file starting with

	LIBRARY bar

seems to have the same effect here, namely still create a cyga-0.dll
and an import lib liba.dll.a, but executables linked with liba.dll.a
will request bar.dll at runtime.

So, the LIBRARY statement does have an effect (not that you can currently
use it with libtool, I had to patch things to make it work for the
above tests) but I'm not sure how you can make any sane use of the
feature. I mean, whats the point of referring to a non-existant dll?
I guess you can rename the .dll file manually as a post-processing
step so that the import library is pointing to something that exists,
but that seems a bit convoluted.

>> To me, this is only about libtool recognizing preexisting .def files
>> that are written without libtool in mind (or at least, not with only
>> libtool in mind), and not about supporting constructs in .def that are
>> actually needed by libtool. From the libtool side, the .def file needs
>> to (currently) start with EXPORTS, and since LIBRARY (and NAME)
>> statements are of no use to libtool they might just as well be zapped
>> so that EXPORTS actually is first. But if you want to use the same .def
>> file from a non-libtool setting, you might have some very good reason
>> to include LIBRARY (or NAME) in it, and then you'd want to have that
>> as the first statement (according to MSDN). But that kills things in
>> libtool, since it then prepends a faulty EXPORTS to the .def file (it's
>> wrongly assuming that the perfectly fine .def file is a plain symbol
>> list when the file doesn't start with EXPORTS).
> 
> There can be only one LIBRARY statement and it must be on the first
> non-empty line of the file.
> 
> However from http://msdn.microsoft.com/en-us/library/hyx1zcd3(v=vs.71).aspx
> we see:
> 
> The EXPORTS statement introduces a section of one or more definitions
> that are exported functions or data. Each definition must be on a
> separate line. The EXPORTS keyword can be on the same line as the
> first definition or on a preceding line. The .def file can contain one
> or more EXPORTS statements.

This .def file seems to work just fine to export a "v1" data item and
a "v2" function using GNU tools:

	EXPORT v1 DATA v2

But the MSVC linker barf and wants one symbol per line, e.g. like this

	EXPORT v1 DATA
	v2

When reading the MSDN about .def files, I agree with the GNU interpretation,
but I have found MSDN to be lacking in a great many places, so one should
never put more than one symbol on one line I suppose...

> Notice the last sentence of the quote.  Also notice that the first
> definition can be on the same line as the EXPORTS keyword.

Yes, I saw that.

Cheers,
Peter

Message #20 received at 13414 <at> debbugs.gnu.org (full text, mbox):

From: Peter Rosin <peda <at> lysator.liu.se>
To: Martin Doucha <doucha <at> integri.cz>
Cc: erik-gnu <at> vanpienbroek.nl, 13414 <at> debbugs.gnu.org,
	Libtool Patches List <libtool-patches <at> gnu.org>
Subject: Re: bug#13414: Valid DLL def file mangled by libtool
Date: Fri, 18 Jan 2013 23:55:29 +0100

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

Message #23 received at 13414 <at> debbugs.gnu.org (full text, mbox):

From: Peter Rosin <peda <at> lysator.liu.se>
To: Martin Doucha <doucha <at> integri.cz>
Cc: 13414 <at> debbugs.gnu.org, erik-gnu <at> vanpienbroek.nl,
	Libtool Patches List <libtool-patches <at> gnu.org>
Subject: [PATCH 1/2] libtool: allow tabs in $cmds variables
Date: Fri, 18 Jan 2013 23:57:26 +0100

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 <peda <at> lysator.liu.se>
---
 build-aux/ltmain.in |    8 ++-
 m4/libtool.m4       |  170 +++++++++++++++++++++++++-------------------------
 2 files changed, 91 insertions(+), 87 deletions(-)

diff --git a/build-aux/ltmain.in b/build-aux/ltmain.in
index c8cdb9c..eb224e3 100644
--- a/build-aux/ltmain.in
+++ b/build-aux/ltmain.in
@@ -656,8 +656,10 @@ func_execute_cmds ()
 
     save_ifs=$IFS; IFS='~'
     for cmd in $1; do
-      IFS=$save_ifs
+      IFS=' ''
+'
       eval cmd=\"$cmd\"
+      IFS=$save_ifs
       func_show_eval "$cmd" "${2-:}"
     done
     IFS=$save_ifs
@@ -7964,8 +7966,10 @@ EOF
 
 	save_ifs=$IFS; IFS='~'
 	for cmd in $cmds; do
-	  IFS=$save_ifs
+	  IFS=' ''
+'
 	  eval cmd=\"$cmd\"
+	  IFS=$save_ifs
 	  $opt_quiet || {
 	    func_quote_for_expand "$cmd"
 	    eval "func_echo $func_quote_for_expand_result"
diff --git a/m4/libtool.m4 b/m4/libtool.m4
index eb44de6..4bc9e98 100644
--- a/m4/libtool.m4
+++ b/m4/libtool.m4
@@ -4785,12 +4785,12 @@ _LT_EOF
 	# If the export-symbols file already is a .def file (1st line
 	# is EXPORTS), use it as is; otherwise, prepend...
 	_LT_TAGVAR(archive_expsym_cmds, $1)='if test EXPORTS = "`$SED 1q $export_symbols`"; then
-	  cp $export_symbols $output_objdir/$soname.def;
-	else
-	  echo EXPORTS > $output_objdir/$soname.def;
-	  cat $export_symbols >> $output_objdir/$soname.def;
-	fi~
-	$CC -shared $output_objdir/$soname.def $libobjs $deplibs $compiler_flags -o $output_objdir/$soname $wl--enable-auto-image-base -Xlinker --out-implib -Xlinker $lib'
+          cp $export_symbols $output_objdir/$soname.def;
+        else
+          echo EXPORTS > $output_objdir/$soname.def;
+          cat $export_symbols >> $output_objdir/$soname.def;
+        fi~
+        $CC -shared $output_objdir/$soname.def $libobjs $deplibs $compiler_flags -o $output_objdir/$soname $wl--enable-auto-image-base -Xlinker --out-implib -Xlinker $lib'
       else
 	_LT_TAGVAR(ld_shlibs, $1)=no
       fi
@@ -4868,9 +4868,9 @@ _LT_EOF
 
         if test yes = "$supports_anon_versioning"; then
           _LT_TAGVAR(archive_expsym_cmds, $1)='echo "{ global:" > $output_objdir/$libname.ver~
-	    cat $export_symbols | sed -e "s/\(.*\)/\1;/" >> $output_objdir/$libname.ver~
-	    echo "local: *; };" >> $output_objdir/$libname.ver~
-	    $CC '"$tmp_sharedflag""$tmp_addflag"' $libobjs $deplibs $compiler_flags $wl-soname $wl$soname $wl-version-script $wl$output_objdir/$libname.ver -o $lib'
+            cat $export_symbols | sed -e "s/\(.*\)/\1;/" >> $output_objdir/$libname.ver~
+            echo "local: *; };" >> $output_objdir/$libname.ver~
+            $CC '"$tmp_sharedflag""$tmp_addflag"' $libobjs $deplibs $compiler_flags $wl-soname $wl$soname $wl-version-script $wl$output_objdir/$libname.ver -o $lib'
         fi
 
 	case $cc_basename in
@@ -4881,9 +4881,9 @@ _LT_EOF
 	  _LT_TAGVAR(archive_cmds, $1)='$LD -shared $libobjs $deplibs $linker_flags -soname $soname -o $lib'
 	  if test yes = "$supports_anon_versioning"; then
 	    _LT_TAGVAR(archive_expsym_cmds, $1)='echo "{ global:" > $output_objdir/$libname.ver~
-	      cat $export_symbols | sed -e "s/\(.*\)/\1;/" >> $output_objdir/$libname.ver~
-	      echo "local: *; };" >> $output_objdir/$libname.ver~
-	      $LD -shared $libobjs $deplibs $linker_flags -soname $soname -version-script $output_objdir/$libname.ver -o $lib'
+              cat $export_symbols | sed -e "s/\(.*\)/\1;/" >> $output_objdir/$libname.ver~
+              echo "local: *; };" >> $output_objdir/$libname.ver~
+              $LD -shared $libobjs $deplibs $linker_flags -soname $soname -version-script $output_objdir/$libname.ver -o $lib'
 	  fi
 	  ;;
 	esac
@@ -5163,13 +5163,13 @@ _LT_EOF
 	# FIXME: Setting linknames here is a bad hack.
 	_LT_TAGVAR(archive_cmds, $1)='$CC -o $output_objdir/$soname $libobjs $compiler_flags $deplibs -Wl,-DLL,-IMPLIB:"$tool_output_objdir$libname.dll.lib"~linknames='
 	_LT_TAGVAR(archive_expsym_cmds, $1)='if test EXPORTS = "`$SED 1q $export_symbols`"; then
-	    cp "$export_symbols" "$output_objdir/$soname.def";
-	    echo "$tool_output_objdir$soname.def" > "$output_objdir/$soname.exp";
-	  else
-	    $SED -e '\''s/^/-link -EXPORT:/'\'' < $export_symbols > $output_objdir/$soname.exp;
-	  fi~
-	  $CC -o $tool_output_objdir$soname $libobjs $compiler_flags $deplibs "@$tool_output_objdir$soname.exp" -Wl,-DLL,-IMPLIB:"$tool_output_objdir$libname.dll.lib"~
-	  linknames='
+            cp "$export_symbols" "$output_objdir/$soname.def";
+            echo "$tool_output_objdir$soname.def" > "$output_objdir/$soname.exp";
+          else
+            $SED -e '\''s/^/-link -EXPORT:/'\'' < $export_symbols > $output_objdir/$soname.exp;
+          fi~
+          $CC -o $tool_output_objdir$soname $libobjs $compiler_flags $deplibs "@$tool_output_objdir$soname.exp" -Wl,-DLL,-IMPLIB:"$tool_output_objdir$libname.dll.lib"~
+          linknames='
 	# The linker will not automatically build a static lib if we build a DLL.
 	# _LT_TAGVAR(old_archive_from_new_cmds, $1)='true'
 	_LT_TAGVAR(enable_shared_with_static_runtimes, $1)=yes
@@ -5178,18 +5178,18 @@ _LT_EOF
 	# Don't use ranlib
 	_LT_TAGVAR(old_postinstall_cmds, $1)='chmod 644 $oldlib'
 	_LT_TAGVAR(postlink_cmds, $1)='lt_outputfile="@OUTPUT@"~
-	  lt_tool_outputfile="@TOOL_OUTPUT@"~
-	  case $lt_outputfile in
-	    *.exe|*.EXE) ;;
-	    *)
-	      lt_outputfile=$lt_outputfile.exe
-	      lt_tool_outputfile=$lt_tool_outputfile.exe
-	      ;;
-	  esac~
-	  if test : != "$MANIFEST_TOOL" && test -f "$lt_outputfile.manifest"; then
-	    $MANIFEST_TOOL -manifest "$lt_tool_outputfile.manifest" -outputresource:"$lt_tool_outputfile" || exit 1;
-	    $RM "$lt_outputfile.manifest";
-	  fi'
+          lt_tool_outputfile="@TOOL_OUTPUT@"~
+          case $lt_outputfile in
+            *.exe|*.EXE) ;;
+            *)
+              lt_outputfile=$lt_outputfile.exe
+              lt_tool_outputfile=$lt_tool_outputfile.exe
+              ;;
+          esac~
+          if test : != "$MANIFEST_TOOL" && test -f "$lt_outputfile.manifest"; then
+            $MANIFEST_TOOL -manifest "$lt_tool_outputfile.manifest" -outputresource:"$lt_tool_outputfile" || exit 1;
+            $RM "$lt_outputfile.manifest";
+          fi'
 	;;
       *)
 	# Assume MSVC wrapper
@@ -5445,7 +5445,7 @@ _LT_EOF
 	_LT_TAGVAR(allow_undefined_flag, $1)=' -expect_unresolved \*'
 	_LT_TAGVAR(archive_cmds, $1)='$CC -shared$allow_undefined_flag $libobjs $deplibs $compiler_flags -msym -soname $soname `test -n "$verstring" && func_echo_all "-set_version $verstring"` -update_registry $output_objdir/so_locations -o $lib'
 	_LT_TAGVAR(archive_expsym_cmds, $1)='for i in `cat $export_symbols`; do printf "%s %s\\n" -exported_symbol "\$i" >> $lib.exp; done; printf "%s\\n" "-hidden">> $lib.exp~
-	$CC -shared$allow_undefined_flag $wl-input $wl$lib.exp $compiler_flags $libobjs $deplibs -soname $soname `test -n "$verstring" && $ECHO "-set_version $verstring"` -update_registry $output_objdir/so_locations -o $lib~$RM $lib.exp'
+          $CC -shared$allow_undefined_flag $wl-input $wl$lib.exp $compiler_flags $libobjs $deplibs -soname $soname `test -n "$verstring" && $ECHO "-set_version $verstring"` -update_registry $output_objdir/so_locations -o $lib~$RM $lib.exp'
 
 	# Both c and cxx compiler support -rpath directly
 	_LT_TAGVAR(hardcode_libdir_flag_spec, $1)='-rpath $libdir'
@@ -5460,20 +5460,20 @@ _LT_EOF
 	wlarc='$wl'
 	_LT_TAGVAR(archive_cmds, $1)='$CC -shared $pic_flag $wl-z ${wl}text $wl-h $wl$soname -o $lib $libobjs $deplibs $compiler_flags'
 	_LT_TAGVAR(archive_expsym_cmds, $1)='echo "{ global:" > $lib.exp~cat $export_symbols | $SED -e "s/\(.*\)/\1;/" >> $lib.exp~echo "local: *; };" >> $lib.exp~
-	  $CC -shared $pic_flag $wl-z ${wl}text $wl-M $wl$lib.exp $wl-h $wl$soname -o $lib $libobjs $deplibs $compiler_flags~$RM $lib.exp'
+          $CC -shared $pic_flag $wl-z ${wl}text $wl-M $wl$lib.exp $wl-h $wl$soname -o $lib $libobjs $deplibs $compiler_flags~$RM $lib.exp'
       else
 	case `$CC -V 2>&1` in
 	*"Compilers 5.0"*)
 	  wlarc=''
 	  _LT_TAGVAR(archive_cmds, $1)='$LD -G$allow_undefined_flag -h $soname -o $lib $libobjs $deplibs $linker_flags'
 	  _LT_TAGVAR(archive_expsym_cmds, $1)='echo "{ global:" > $lib.exp~cat $export_symbols | $SED -e "s/\(.*\)/\1;/" >> $lib.exp~echo "local: *; };" >> $lib.exp~
-	  $LD -G$allow_undefined_flag -M $lib.exp -h $soname -o $lib $libobjs $deplibs $linker_flags~$RM $lib.exp'
+            $LD -G$allow_undefined_flag -M $lib.exp -h $soname -o $lib $libobjs $deplibs $linker_flags~$RM $lib.exp'
 	  ;;
 	*)
 	  wlarc='$wl'
 	  _LT_TAGVAR(archive_cmds, $1)='$CC -G$allow_undefined_flag -h $soname -o $lib $libobjs $deplibs $compiler_flags'
 	  _LT_TAGVAR(archive_expsym_cmds, $1)='echo "{ global:" > $lib.exp~cat $export_symbols | $SED -e "s/\(.*\)/\1;/" >> $lib.exp~echo "local: *; };" >> $lib.exp~
-	  $CC -G$allow_undefined_flag -M $lib.exp -h $soname -o $lib $libobjs $deplibs $compiler_flags~$RM $lib.exp'
+            $CC -G$allow_undefined_flag -M $lib.exp -h $soname -o $lib $libobjs $deplibs $compiler_flags~$RM $lib.exp'
 	  ;;
 	esac
       fi
@@ -6155,32 +6155,32 @@ if test yes != "$_lt_caught_CXX_error"; then
 	  # FIXME: Setting linknames here is a bad hack.
 	  _LT_TAGVAR(archive_cmds, $1)='$CC -o $output_objdir/$soname $libobjs $compiler_flags $deplibs -Wl,-DLL,-IMPLIB:"$tool_output_objdir$libname.dll.lib"~linknames='
 	  _LT_TAGVAR(archive_expsym_cmds, $1)='if test EXPORTS = "`$SED 1q $export_symbols`"; then
-	      cp "$export_symbols" "$output_objdir/$soname.def";
-	      echo "$tool_output_objdir$soname.def" > "$output_objdir/$soname.exp";
-	    else
-	      $SED -e '\''s/^/-link -EXPORT:/'\'' < $export_symbols > $output_objdir/$soname.exp;
-	    fi~
-	    $CC -o $tool_output_objdir$soname $libobjs $compiler_flags $deplibs "@$tool_output_objdir$soname.exp" -Wl,-DLL,-IMPLIB:"$tool_output_objdir$libname.dll.lib"~
-	    linknames='
+              cp "$export_symbols" "$output_objdir/$soname.def";
+              echo "$tool_output_objdir$soname.def" > "$output_objdir/$soname.exp";
+            else
+              $SED -e '\''s/^/-link -EXPORT:/'\'' < $export_symbols > $output_objdir/$soname.exp;
+            fi~
+            $CC -o $tool_output_objdir$soname $libobjs $compiler_flags $deplibs "@$tool_output_objdir$soname.exp" -Wl,-DLL,-IMPLIB:"$tool_output_objdir$libname.dll.lib"~
+            linknames='
 	  # The linker will not automatically build a static lib if we build a DLL.
 	  # _LT_TAGVAR(old_archive_from_new_cmds, $1)='true'
 	  _LT_TAGVAR(enable_shared_with_static_runtimes, $1)=yes
 	  # Don't use ranlib
 	  _LT_TAGVAR(old_postinstall_cmds, $1)='chmod 644 $oldlib'
 	  _LT_TAGVAR(postlink_cmds, $1)='lt_outputfile="@OUTPUT@"~
-	    lt_tool_outputfile="@TOOL_OUTPUT@"~
-	    case $lt_outputfile in
-	      *.exe|*.EXE) ;;
-	      *)
-		lt_outputfile=$lt_outputfile.exe
-		lt_tool_outputfile=$lt_tool_outputfile.exe
-		;;
-	    esac~
-	    func_to_tool_file "$lt_outputfile"~
-	    if test : != "$MANIFEST_TOOL" && test -f "$lt_outputfile.manifest"; then
-	      $MANIFEST_TOOL -manifest "$lt_tool_outputfile.manifest" -outputresource:"$lt_tool_outputfile" || exit 1;
-	      $RM "$lt_outputfile.manifest";
-	    fi'
+            lt_tool_outputfile="@TOOL_OUTPUT@"~
+            case $lt_outputfile in
+              *.exe|*.EXE) ;;
+              *)
+                lt_outputfile=$lt_outputfile.exe
+                lt_tool_outputfile=$lt_tool_outputfile.exe
+                ;;
+            esac~
+            func_to_tool_file "$lt_outputfile"~
+            if test : != "$MANIFEST_TOOL" && test -f "$lt_outputfile.manifest"; then
+              $MANIFEST_TOOL -manifest "$lt_tool_outputfile.manifest" -outputresource:"$lt_tool_outputfile" || exit 1;
+              $RM "$lt_outputfile.manifest";
+            fi'
 	  ;;
 	*)
 	  # g++
@@ -6197,12 +6197,12 @@ if test yes != "$_lt_caught_CXX_error"; then
 	    # 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 -nostdlib $output_objdir/$soname.def $predep_objects $libobjs $deplibs $postdep_objects $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 -nostdlib $output_objdir/$soname.def $predep_objects $libobjs $deplibs $postdep_objects $compiler_flags -o $output_objdir/$soname $wl--enable-auto-image-base -Xlinker --out-implib -Xlinker $lib'
 	  else
 	    _LT_TAGVAR(ld_shlibs, $1)=no
 	  fi
@@ -6465,22 +6465,22 @@ if test yes != "$_lt_caught_CXX_error"; then
 	    case `$CC -V` in
 	    *pgCC\ [[1-5]].* | *pgcpp\ [[1-5]].*)
 	      _LT_TAGVAR(prelink_cmds, $1)='tpldir=Template.dir~
-		rm -rf $tpldir~
-		$CC --prelink_objects --instantiation_dir $tpldir $objs $libobjs $compile_deplibs~
-		compile_command="$compile_command `find $tpldir -name \*.o | sort | $NL2SP`"'
+               rm -rf $tpldir~
+               $CC --prelink_objects --instantiation_dir $tpldir $objs $libobjs $compile_deplibs~
+               compile_command="$compile_command `find $tpldir -name \*.o | sort | $NL2SP`"'
 	      _LT_TAGVAR(old_archive_cmds, $1)='tpldir=Template.dir~
-		rm -rf $tpldir~
-		$CC --prelink_objects --instantiation_dir $tpldir $oldobjs$old_deplibs~
-		$AR $AR_FLAGS $oldlib$oldobjs$old_deplibs `find $tpldir -name \*.o | sort | $NL2SP`~
-		$RANLIB $oldlib'
+                rm -rf $tpldir~
+                $CC --prelink_objects --instantiation_dir $tpldir $oldobjs$old_deplibs~
+                $AR $AR_FLAGS $oldlib$oldobjs$old_deplibs `find $tpldir -name \*.o | sort | $NL2SP`~
+                $RANLIB $oldlib'
 	      _LT_TAGVAR(archive_cmds, $1)='tpldir=Template.dir~
-		rm -rf $tpldir~
-		$CC --prelink_objects --instantiation_dir $tpldir $predep_objects $libobjs $deplibs $convenience $postdep_objects~
-		$CC -shared $pic_flag $predep_objects $libobjs $deplibs `find $tpldir -name \*.o | sort | $NL2SP` $postdep_objects $compiler_flags $wl-soname $wl$soname -o $lib'
+                rm -rf $tpldir~
+                $CC --prelink_objects --instantiation_dir $tpldir $predep_objects $libobjs $deplibs $convenience $postdep_objects~
+                $CC -shared $pic_flag $predep_objects $libobjs $deplibs `find $tpldir -name \*.o | sort | $NL2SP` $postdep_objects $compiler_flags $wl-soname $wl$soname -o $lib'
 	      _LT_TAGVAR(archive_expsym_cmds, $1)='tpldir=Template.dir~
-		rm -rf $tpldir~
-		$CC --prelink_objects --instantiation_dir $tpldir $predep_objects $libobjs $deplibs $convenience $postdep_objects~
-		$CC -shared $pic_flag $predep_objects $libobjs $deplibs `find $tpldir -name \*.o | sort | $NL2SP` $postdep_objects $compiler_flags $wl-soname $wl$soname $wl-retain-symbols-file $wl$export_symbols -o $lib'
+                rm -rf $tpldir~
+                $CC --prelink_objects --instantiation_dir $tpldir $predep_objects $libobjs $deplibs $convenience $postdep_objects~
+                $CC -shared $pic_flag $predep_objects $libobjs $deplibs `find $tpldir -name \*.o | sort | $NL2SP` $postdep_objects $compiler_flags $wl-soname $wl$soname $wl-retain-symbols-file $wl$export_symbols -o $lib'
 	      ;;
 	    *) # Version 6 and above use weak symbols
 	      _LT_TAGVAR(archive_cmds, $1)='$CC -shared $pic_flag $predep_objects $libobjs $deplibs $postdep_objects $compiler_flags $wl-soname $wl$soname -o $lib'
@@ -6518,9 +6518,9 @@ if test yes != "$_lt_caught_CXX_error"; then
 	    _LT_TAGVAR(archive_cmds, $1)='$CC -qmkshrobj $libobjs $deplibs $compiler_flags $wl-soname $wl$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~
-		$CC -qmkshrobj $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 -qmkshrobj $libobjs $deplibs $compiler_flags $wl-soname $wl$soname $wl-version-script $wl$output_objdir/$libname.ver -o $lib'
 	    fi
 	    ;;
 	  *)
@@ -6643,9 +6643,9 @@ if test yes != "$_lt_caught_CXX_error"; then
 	        _LT_TAGVAR(allow_undefined_flag, $1)=' -expect_unresolved \*'
 	        _LT_TAGVAR(archive_cmds, $1)='$CC -shared$allow_undefined_flag $predep_objects $libobjs $deplibs $postdep_objects $compiler_flags -msym -soname $soname `test -n "$verstring" && func_echo_all "-set_version $verstring"` -update_registry $output_objdir/so_locations -o $lib'
 	        _LT_TAGVAR(archive_expsym_cmds, $1)='for i in `cat $export_symbols`; do printf "%s %s\\n" -exported_symbol "\$i" >> $lib.exp; done~
-	          echo "-hidden">> $lib.exp~
-	          $CC -shared$allow_undefined_flag $predep_objects $libobjs $deplibs $postdep_objects $compiler_flags -msym -soname $soname $wl-input $wl$lib.exp  `test -n "$verstring" && $ECHO "-set_version $verstring"` -update_registry $output_objdir/so_locations -o $lib~
-	          $RM $lib.exp'
+                  echo "-hidden">> $lib.exp~
+                  $CC -shared$allow_undefined_flag $predep_objects $libobjs $deplibs $postdep_objects $compiler_flags -msym -soname $soname $wl-input $wl$lib.exp  `test -n "$verstring" && $ECHO "-set_version $verstring"` -update_registry $output_objdir/so_locations -o $lib~
+                  $RM $lib.exp'
 	        _LT_TAGVAR(hardcode_libdir_flag_spec, $1)='-rpath $libdir'
 		;;
 	    esac
@@ -6722,7 +6722,7 @@ if test yes != "$_lt_caught_CXX_error"; then
 	    _LT_TAGVAR(no_undefined_flag, $1)=' -zdefs'
 	    _LT_TAGVAR(archive_cmds, $1)='$CC -G$allow_undefined_flag -h$soname -o $lib $predep_objects $libobjs $deplibs $postdep_objects $compiler_flags'
 	    _LT_TAGVAR(archive_expsym_cmds, $1)='echo "{ global:" > $lib.exp~cat $export_symbols | $SED -e "s/\(.*\)/\1;/" >> $lib.exp~echo "local: *; };" >> $lib.exp~
-	      $CC -G$allow_undefined_flag $wl-M $wl$lib.exp -h$soname -o $lib $predep_objects $libobjs $deplibs $postdep_objects $compiler_flags~$RM $lib.exp'
+              $CC -G$allow_undefined_flag $wl-M $wl$lib.exp -h$soname -o $lib $predep_objects $libobjs $deplibs $postdep_objects $compiler_flags~$RM $lib.exp'
 
 	    _LT_TAGVAR(hardcode_libdir_flag_spec, $1)='-R$libdir'
 	    _LT_TAGVAR(hardcode_shlibpath_var, $1)=no
@@ -6759,7 +6759,7 @@ if test yes != "$_lt_caught_CXX_error"; then
 	      if $CC --version | $GREP -v '^2\.7' > /dev/null; then
 	        _LT_TAGVAR(archive_cmds, $1)='$CC -shared $pic_flag -nostdlib $predep_objects $libobjs $deplibs $postdep_objects $compiler_flags $wl-h $wl$soname -o $lib'
 	        _LT_TAGVAR(archive_expsym_cmds, $1)='echo "{ global:" > $lib.exp~cat $export_symbols | $SED -e "s/\(.*\)/\1;/" >> $lib.exp~echo "local: *; };" >> $lib.exp~
-		  $CC -shared $pic_flag -nostdlib $wl-M $wl$lib.exp $wl-h $wl$soname -o $lib $predep_objects $libobjs $deplibs $postdep_objects $compiler_flags~$RM $lib.exp'
+                  $CC -shared $pic_flag -nostdlib $wl-M $wl$lib.exp $wl-h $wl$soname -o $lib $predep_objects $libobjs $deplibs $postdep_objects $compiler_flags~$RM $lib.exp'
 
 	        # Commands to make compiler produce verbose output that lists
 	        # what "hidden" libraries, object files and flags are used when
@@ -6770,7 +6770,7 @@ if test yes != "$_lt_caught_CXX_error"; then
 	        # platform.
 	        _LT_TAGVAR(archive_cmds, $1)='$CC -G -nostdlib $predep_objects $libobjs $deplibs $postdep_objects $compiler_flags $wl-h $wl$soname -o $lib'
 	        _LT_TAGVAR(archive_expsym_cmds, $1)='echo "{ global:" > $lib.exp~cat $export_symbols | $SED -e "s/\(.*\)/\1;/" >> $lib.exp~echo "local: *; };" >> $lib.exp~
-		  $CC -G -nostdlib $wl-M $wl$lib.exp $wl-h $wl$soname -o $lib $predep_objects $libobjs $deplibs $postdep_objects $compiler_flags~$RM $lib.exp'
+                  $CC -G -nostdlib $wl-M $wl$lib.exp $wl-h $wl$soname -o $lib $predep_objects $libobjs $deplibs $postdep_objects $compiler_flags~$RM $lib.exp'
 
 	        # Commands to make compiler produce verbose output that lists
 	        # what "hidden" libraries, object files and flags are used when
@@ -6830,9 +6830,9 @@ if test yes != "$_lt_caught_CXX_error"; then
 	    _LT_TAGVAR(archive_cmds, $1)='$CC -G $wl-h,$soname -o $lib $libobjs $deplibs $compiler_flags'
 	    _LT_TAGVAR(archive_expsym_cmds, $1)='$CC -G $wl-Bexport:$export_symbols $wl-h,$soname -o $lib $libobjs $deplibs $compiler_flags'
 	    _LT_TAGVAR(old_archive_cmds, $1)='$CC -Tprelink_objects $oldobjs~
-	      '"$_LT_TAGVAR(old_archive_cmds, $1)"
+              '"$_LT_TAGVAR(old_archive_cmds, $1)"
 	    _LT_TAGVAR(reload_cmds, $1)='$CC -Tprelink_objects $reload_objs~
-	      '"$_LT_TAGVAR(reload_cmds, $1)"
+              '"$_LT_TAGVAR(reload_cmds, $1)"
 	    ;;
 	  *)
 	    _LT_TAGVAR(archive_cmds, $1)='$CC -shared $wl-h,$soname -o $lib $libobjs $deplibs $compiler_flags'
-- 
1.7.9

Message #26 received at 13414 <at> debbugs.gnu.org (full text, mbox):

From: Peter Rosin <peda <at> lysator.liu.se>
To: Martin Doucha <doucha <at> integri.cz>
Cc: 13414 <at> debbugs.gnu.org, erik-gnu <at> vanpienbroek.nl,
	Libtool Patches List <libtool-patches <at> gnu.org>
Subject: [PATCH 2/2] libtool: factor out the dll .def file test and improve it
Date: Fri, 18 Jan 2013 23:58:30 +0100

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

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

Signed-off-by: Peter Rosin <peda <at> lysator.liu.se>

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

diff --git a/Makefile.am b/Makefile.am
index a3e3c7d..e5f3805 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -627,6 +627,7 @@ TESTSUITE_AT	= tests/testsuite.at \
 		  tests/runpath-in-lalib.at \
 		  tests/static.at \
 		  tests/export.at \
+		  tests/export-def.at \
 		  tests/search-path.at \
 		  tests/indirect_deps.at \
 		  tests/archive-in-archive.at \
diff --git a/NEWS b/NEWS
index c202c43..514768b 100644
--- a/NEWS
+++ b/NEWS
@@ -66,6 +66,9 @@ NEWS - list of user-visible changes between releases of GNU Libtool
     the Microsoft Visual C/C++ linker via the -export-symbols argument to
     the libtool script, thus matching how .def files are handled when
     using GNU tools.
+  - Recognize more variants (e.g. those starting with a LIBRARY statement)
+    of module-definitions (.def) files when using them instead of a raw
+    list of symbols to export.
 
 ** Important incompatible changes:
 
diff --git a/THANKS b/THANKS
index d4c1f1b..92e6dff 100644
--- a/THANKS
+++ b/THANKS
@@ -98,6 +98,7 @@
   Edouard G. Parmelan		Edouard.Parmelan <at> France.NCR.COM
   Erez Zadok			ezk <at> shekel.mcl.cs.columbia.edu
   Eric Estievenart		eric <at> via.ecp.fr
+  Erik van Pienbroek		erik-gnu <at> vanpienbroek.nl
   Ethan Mallove			ethan.mallove <at> sun.com
   Frank Ch. Eigler		fche <at> cygnus.com
   Fred Cox			sailorfred <at> yahoo.com
@@ -140,6 +141,7 @@
   Marcel Loose			loose <at> astron.nl
   Mark Kettenis			kettenis <at> phys.uva.nl
   Markus Duft			markus.duft <at> salomon.at
+  Martin Doucha			doucha <at> integri.cz
   Matthijs Kooijman		matthijs <at> stdin.nl
   Micheal E. Faenza		mfaenza <at> mitre.org
   Michael Haubenwallner		michael.haubenwallner <at> salomon.at
diff --git a/build-aux/ltmain.in b/build-aux/ltmain.in
index eb224e3..f0168da 100644
--- a/build-aux/ltmain.in
+++ b/build-aux/ltmain.in
@@ -1316,6 +1316,23 @@ func_convert_path_nix_to_cygwin ()
 # end func_convert_path_nix_to_cygwin
 
 
+# func_dll_def_p FILE
+# True iff FILE is a Windows DLL '.def' file.
+# Keep in sync with _LT_DLL_DEF_P in libtool.m4
+func_dll_def_p ()
+{
+  $debug_cmd
+
+  func_dll_def_p_tmp=`$SED -n \
+    -e 's/^[ 	]*//' \
+    -e '/^\(;.*\)*$/d' \
+    -e 's/^\(EXPORTS\|LIBRARY\)\([ 	].*\)*$/DEF/p' \
+    -e q \
+    "$1"`
+  test DEF = "$func_dll_def_p_tmp"
+}
+
+
 # func_mode_compile arg...
 func_mode_compile ()
 {
@@ -7572,7 +7589,7 @@ EOF
 	cygwin* | mingw* | cegcc*)
 	  if test -n "$export_symbols" && test -z "$export_symbols_regex"; then
 	    # exporting using user supplied symfile
-	    if test EXPORTS != "`$SED 1q $export_symbols`"; then
+	    if ! func_dll_def_p "$export_symbols"; then
 	      # and it's NOT already a .def file. Must figure out
 	      # which of the given symbols are data symbols and tag
 	      # them as such. So, trigger use of export_symbols_cmds.
diff --git a/m4/libtool.m4 b/m4/libtool.m4
index 4bc9e98..0a6c334 100644
--- a/m4/libtool.m4
+++ b/m4/libtool.m4
@@ -3530,6 +3530,21 @@ _LT_DECL([], [MANIFEST_TOOL], [1], [Manifest tool])dnl
 ])# _LT_PATH_MANIFEST_TOOL
 
 
+# _LT_DLL_DEF_P([FILE])
+# ---------------------
+# True iff FILE is a Windows DLL '.def' file.
+# Keep in sync with func_dll_def_p in the libtool script
+AC_DEFUN([_LT_DLL_DEF_P],
+[dnl
+  test DEF = "`$SED -n dnl
+    -e '\''s/^[[ 	]]*//'\'' dnl Strip leading whitespace
+    -e '\''/^\(;.*\)*$/d'\'' dnl      Delete empty lines and comments
+    -e '\''s/^\(EXPORTS\|LIBRARY\)\([[ 	]].*\)*$/DEF/p'\'' dnl
+    -e q dnl                          Only consider the first "real" line
+    $1`" dnl
+])# _LT_DLL_DEF_P
+
+
 # LT_LIB_M
 # --------
 # check for math library
@@ -4782,9 +4797,9 @@ _LT_EOF
 
       if $LD --help 2>&1 | $GREP 'auto-import' > /dev/null; then
         _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 (1st line
-	# is EXPORTS), use it as is; otherwise, prepend...
-	_LT_TAGVAR(archive_expsym_cmds, $1)='if test EXPORTS = "`$SED 1q $export_symbols`"; then
+	# 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
           cp $export_symbols $output_objdir/$soname.def;
         else
           echo EXPORTS > $output_objdir/$soname.def;
@@ -5162,7 +5177,7 @@ _LT_EOF
 	shrext_cmds=.dll
 	# 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
+	_LT_TAGVAR(archive_expsym_cmds, $1)='if _LT_DLL_DEF_P([$export_symbols]); then
             cp "$export_symbols" "$output_objdir/$soname.def";
             echo "$tool_output_objdir$soname.def" > "$output_objdir/$soname.exp";
           else
@@ -6154,7 +6169,7 @@ if test yes != "$_lt_caught_CXX_error"; then
 	  shrext_cmds=.dll
 	  # 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
+	  _LT_TAGVAR(archive_expsym_cmds, $1)='if _LT_DLL_DEF_P([$export_symbols]); then
               cp "$export_symbols" "$output_objdir/$soname.def";
               echo "$tool_output_objdir$soname.def" > "$output_objdir/$soname.exp";
             else
@@ -6194,9 +6209,9 @@ if test yes != "$_lt_caught_CXX_error"; then
 
 	  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'
-	    # 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
+	    # 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
               cp $export_symbols $output_objdir/$soname.def;
             else
               echo EXPORTS > $output_objdir/$soname.def;
diff --git a/tests/export-def.at b/tests/export-def.at
new file mode 100755
index 0000000..b8dfa55
--- /dev/null
+++ b/tests/export-def.at
@@ -0,0 +1,139 @@
+# export-def.at -- test module-definition files              -*- Autotest -*-
+
+#   Copyright (C) 2007-2008, 2011-2013 Free Software Foundation, Inc.
+#   Written by Peter Rosin, 2013
+#
+#   This file is part of GNU Libtool.
+#
+# GNU Libtool is free software; you can redistribute it and/or
+# modify it under the terms of the GNU General Public License as
+# published by the Free Software Foundation; either version 2 of
+# the License, or (at your option) any later version.
+#
+# GNU Libtool is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with GNU Libtool; see the file COPYING.  If not, a copy
+# can be downloaded from  http://www.gnu.org/licenses/gpl.html,
+# or obtained by writing to the Free Software Foundation, Inc.,
+# 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
+####
+
+AT_SETUP([export from a DLL with a .def file])
+AT_KEYWORDS([libtool])
+
+AT_CHECK([$LIBTOOL --features | grep 'disable shared libraries' && (exit 77)],
+	 [1], [ignore])
+eval `$LIBTOOL --config | $EGREP '^(shrext_cmds|libname_spec|soname_spec)='`
+
+eval shared_ext=\"$shrext_cmds\"
+
+# skip if not building a .dll
+AT_CHECK([test .dll = "$shared_ext" || (exit 77)])
+
+LDFLAGS="$LDFLAGS -no-undefined"
+libdir=`pwd`/inst/lib
+mkdir inst inst/lib
+
+AT_DATA([a.c],
+[[/* a */
+#ifdef __cplusplus
+extern "C" {
+#endif
+
+int v1 = -1;
+int v2 (void) { return -2; }
+
+#ifdef __cplusplus
+}
+#endif
+]])
+
+AT_DATA([syms],
+[[v1
+v2
+]])
+
+AT_DATA([def1],
+[[EXPORTS
+v1 DATA
+v2
+]])
+
+AT_DATA([def2],
+[[; Def file
+    ; with some very important comments
+EXPORTS
+v1 DATA
+v2
+]])
+
+AT_DATA([def3],
+[[
+   EXPORTS v1 DATA
+   v2
+]])
+
+AT_DATA([def4],
+[[	LIBRARY %soname%
+EXPORTS
+v1 DATA
+v2
+]])
+
+AT_DATA([main.c],
+[[
+/* w32 fun.  With GCC, you can have auto-import, which will work for
+ * functions and non-const variables.  With MSVC, you have to explicitly
+ * import all variables.
+ *
+ * For users, it's best to realize that they should not provide any
+ * non-function API at all.
+ */
+#if defined LIBA_DLL_IMPORT
+#  if defined _WIN32 && defined _MSC_VER
+#    define LIBA_SCOPE_VAR extern __declspec(dllimport)
+#  endif
+#endif
+#if !defined LIBA_SCOPE_VAR
+#  define LIBA_SCOPE_VAR extern
+#endif
+#ifdef __cplusplus
+extern "C" {
+#endif
+LIBA_SCOPE_VAR int v1;
+extern int v2(void);
+#ifdef __cplusplus
+}
+#endif
+
+int main (void)
+{
+  return v1 + v2() + 3;
+}
+]])
+
+name=a
+eval libname=\"$libname_spec\"
+major=0
+versuffix=-$major
+eval soname=\"$soname_spec\"
+
+AT_CHECK([$LIBTOOL --mode=compile $CC $CPPFLAGS $CFLAGS -c a.c],[0],[ignore],[ignore])
+AT_CHECK([$CC $CPPFLAGS -DLIBA_DLL_IMPORT $CFLAGS -c main.c],[0],[ignore],[ignore])
+
+for exportsyms in syms def1 def2 def3 def4
+do
+  $SED "s/%soname%/$soname/" -i $exportsyms
+
+  LT_AT_CHECK([eval '$LIBTOOL --mode=link $CC $CFLAGS $LDFLAGS -o liba.la a.lo \
+	       -rpath $libdir' -export-symbols $exportsyms], [], [ignore], [ignore])
+  AT_CHECK([$LIBTOOL --mode=link $CC $CFLAGS $LDFLAGS -o main$EXEEXT main.$OBJEXT liba.la],
+	   [], [ignore], [ignore])
+  LT_AT_EXEC_CHECK([./main])
+done
+
+AT_CLEANUP
-- 
1.7.9

Message #29 received at 13414 <at> debbugs.gnu.org (full text, mbox):

From: "Gary V. Vaughan" <gary <at> gnu.org>
To: Peter Rosin <peda <at> lysator.liu.se>
Cc: "erik-gnu <at> vanpienbroek.nl" <erik-gnu <at> vanpienbroek.nl>,
	Martin Doucha <doucha <at> integri.cz>,
	"13414 <at> debbugs.gnu.org" <13414 <at> debbugs.gnu.org>,
	Libtool Patches List <libtool-patches <at> gnu.org>
Subject: Re: bug#13414: Valid DLL def file mangled by libtool
Date: Sat, 19 Jan 2013 12:12:22 +0700

Hi Peter,

Thanks for working on this.

On 19 Jan 2013, at 05:55, Peter Rosin <peda <at> lysator.liu.se> wrote:
> On 2013-01-12 01:26, Peter Rosin wrote:
>> On 2013-01-11 12:34, Martin Doucha wrote:
>>> I'd like to report a bug in libtool 2.4 (including the latest git revision) which mangles valid DLL def files under MinGW and makes the linker barf.
>> 
>> This issue has been reported before [1].
> 
> So, as hinted above, I'm following up with a pair of patches that
> appear to mend this.
> 
> Ok to push?

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

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.

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

Cheers,
-- 
Gary V. Vaughan (gary AT gnu DOT org)

Message #32 received at 13414 <at> debbugs.gnu.org (full text, mbox):

From: Peter Rosin <peda <at> lysator.liu.se>
To: "Gary V. Vaughan" <gary <at> gnu.org>
Cc: "erik-gnu <at> vanpienbroek.nl" <erik-gnu <at> vanpienbroek.nl>,
	Martin Doucha <doucha <at> integri.cz>,
	"13414 <at> debbugs.gnu.org" <13414 <at> debbugs.gnu.org>,
	Libtool Patches List <libtool-patches <at> gnu.org>
Subject: Re: bug#13414: Valid DLL def file mangled by libtool
Date: Sun, 20 Jan 2013 08:32:41 +0100

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 <peda <at> lysator.liu.se> wrote:
>> On 2013-01-12 01:26, Peter Rosin wrote:
>>> On 2013-01-11 12:34, Martin Doucha wrote:
>>>> I'd like to report a bug in libtool 2.4 (including the latest git revision) which mangles valid DLL def files under MinGW and makes the linker barf.
>>>
>>> This issue has been reported before [1].
>>
>> So, as hinted above, I'm following up with a pair of patches that
>> appear to mend this.
>>
>> Ok to push?
> 
> By inspection, these patches look good to me - presuming there are no regressions, please go ahead.

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

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

Done.

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

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

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

Cheers,
Peter

Message #35 received at 13414 <at> debbugs.gnu.org (full text, mbox):

From: Erik van Pienbroek <erik <at> vanpienbroek.nl>
To: Peter Rosin <peda <at> lysator.liu.se>
Cc: Martin Doucha <doucha <at> integri.cz>,
	"13414 <at> debbugs.gnu.org" <13414 <at> debbugs.gnu.org>,
	Libtool Patches List <libtool-patches <at> gnu.org>,
	"Gary V. Vaughan" <gary <at> gnu.org>
Subject: Re: bug#13414: Valid DLL def file mangled by libtool
Date: Sun, 20 Jan 2013 15:54:33 +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.

Kind regards,

Erik van Pienbroek
Fedora MinGW SIG

Message #38 received at 13414 <at> debbugs.gnu.org (full text, mbox):

From: Erik van Pienbroek <erik <at> vanpienbroek.nl>
To: Peter Rosin <peda <at> lysator.liu.se>
Cc: Martin Doucha <doucha <at> integri.cz>,
	"13414 <at> debbugs.gnu.org" <13414 <at> debbugs.gnu.org>,
	Libtool Patches List <libtool-patches <at> gnu.org>,
	"Gary V. Vaughan" <gary <at> gnu.org>
Subject: Re: bug#13414: Valid DLL def file mangled by libtool
Date: Tue, 22 Jan 2013 19:45:52 +0100

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.

Hi,

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.

Regards,

Erik van Pienbroek
Fedora MinGW SIG

Message #41 received at 13414 <at> debbugs.gnu.org (full text, mbox):

From: Peter Rosin <peda <at> lysator.liu.se>
To: Erik van Pienbroek <erik <at> vanpienbroek.nl>
Cc: Martin Doucha <doucha <at> integri.cz>,
	"13414 <at> debbugs.gnu.org" <13414 <at> debbugs.gnu.org>,
	Libtool Patches List <libtool-patches <at> gnu.org>
Subject: Re: bug#13414: Valid DLL def file mangled by libtool
Date: Tue, 22 Jan 2013 23:29:41 +0100

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

Message #44 received at 13414 <at> debbugs.gnu.org (full text, mbox):

From: Daniel Kahn Gillmor <dkg <at> fifthhorseman.net>
To: 13414 <at> debbugs.gnu.org, control <at> bugs.debian.org, 814951 <at> bugs.debian.org
Subject: [Werner Koch] Re: [pkg-gnupg-maint] Bug#814951: libassuan: add
 libassuan-mingw-w64-dev for cross-building to Windows targets
Date: Sat, 20 Feb 2016 14:29:47 -0500

[Message part 1 (text/plain, inline)]

# for the debian BTS, hopefully this doesn't cause problems for the GNU BTS)
clone 814951 -1
reassign -1 libtool
retitle -1 libtool fails to detect DLL .def file
forwarded -1 https://debbugs.gnu.org/13414
tags -1 = patch upstream
thanks

Over on https://bugs.debian.org/814951, Werner Koch and i are discussing
how https://debbugs.gnu.org/13414 is still a problem with libtool.  In
particular, GNU libtool can't seem to detect that a .def file is valid
unless EXPORT is the literal first line in the file (it chokes when
blank lines or comments precede EXPORT).

Werner supplied the patch below to fix libtool.  The upstream bug
appears to have a rather different set of patches.  Either way, the
problem should be cleaned up in libtool, as it's causing a series of
workarounds for cross-building things on debian for the Windows
platform.

Is there some reason for the delay upstream besides lack of time to work
on it?  Should debian go ahead and apply one of the proposed patches
downstream in the meantime?

    --dkg

[Message part 2 (message/rfc822, inline)]

From: Werner Koch <wk <at> gnupg.org>
To: Daniel Kahn Gillmor <dkg <at> fifthhorseman.net>
Cc: 814951 <at> bugs.debian.org
Subject: Re: [pkg-gnupg-maint] Bug#814951: libassuan: add libassuan-mingw-w64-dev for cross-building to Windows targets
Date: Wed, 17 Feb 2016 09:22:05 +0100

On Wed, 17 Feb 2016 00:11, dkg <at> fifthhorseman.net said:

> ++++ b/src/libassuan.def
> +@@ -1,3 +1,4 @@
> ++EXPORTS
> + ; assuan.def - List of symbols to export.

That is for sure a bug in libtool.  I fixed that years ago but it didn't
made into into libtool upstream because they where revamping the entire
thing.  Seems this or a new bug is still present.  Find below for
reference the patch used for libgpg-error which has also been ported to
all GnuPG related libraries.  FWIW, I have also another libtool fix to
support Android.


Salam-Shalom,

   Werner


--8<---------------cut here---------------start------------->8---
commit dd05f3790e536dec6ed56087780a1065ca66371e
Author: Werner Koch <wk <at> gnupg.org>
Date:   Thu Apr 18 14:40:43 2013 +0200

    Fix libtool 2.4.2 to correctly detect .def files.
    
    * ltmain.sh (sed_uncomment_deffile): New.
    (orig_export_symbols): Uncomment def file before testing for EXPORTS.
    * m4/libtool.m4: Do the same for the generated code.
    --
    
    The old code was not correct in that it only looked at the first line
    and puts an EXPORTS keyword in front if missing.  Binutils 2.22
    accepted a duplicated EXPORTS keyword but at least 2.23.2 is more
    stringent and bails out without this fix.
    
    There is no need to send this upstream.  Upstream's git master has a
    lot of changes including a similar fix for this problems.  There are
    no signs that a libtool 2.4.3 will be released to fix this problem and
    thus we need to stick to our copy of 2.4.2 along with this patch.
    
    Signed-off-by: Werner Koch <wk <at> gnupg.org>

diff --git a/ltmain.sh b/ltmain.sh
index c7d06c3..24e3fd3 100644
--- a/ltmain.sh
+++ b/ltmain.sh
@@ -411,6 +411,10 @@ sed_make_literal_regex='s,[].[^$\\*\/],\\&,g'
 # (escaped) backslashes.  A very naive implementation.
 lt_sed_naive_backslashify='s|\\\\*|\\|g;s|/|\\|g;s|\\|\\\\|g'
 
+# Sed substitution to remove simple comments and empty
+# lines from a Windows .def file.
+sed_uncomment_deffile='/^;/d; /^[ ]*$/d'
+
 # Re-`\' parameter expansions in output of double_quote_subst that were
 # `\'-ed in input to the same.  If an odd number of `\' preceded a '$'
 # in input to double_quote_subst, that '$' was protected from expansion.
@@ -8143,7 +8147,7 @@ EOF
 	cygwin* | mingw* | cegcc*)
 	  if test -n "$export_symbols" && test -z "$export_symbols_regex"; then
 	    # exporting using user supplied symfile
-	    if test "x`$SED 1q $export_symbols`" != xEXPORTS; then
+	    if test "x`$SED "$sed_uncomment_deffile" $export_symbols | $SED 1q`" != xEXPORTS; 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 4bedbd3..ff871a0 100644
--- a/m4/libtool.m4
+++ b/m4/libtool.m4
@@ -4773,7 +4773,7 @@ _LT_EOF
         _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 (1st line
 	# is EXPORTS), use it as is; otherwise, prepend...
-	_LT_TAGVAR(archive_expsym_cmds, $1)='if test "x`$SED 1q $export_symbols`" = xEXPORTS; then
+	_LT_TAGVAR(archive_expsym_cmds, $1)='if test "x`$SED \"$sed_uncomment_deffile\" $export_symbols | $SED 1q`" = xEXPORTS; then
 	  cp $export_symbols $output_objdir/$soname.def;
 	else
 	  echo EXPORTS > $output_objdir/$soname.def;
@@ -5150,7 +5150,7 @@ _LT_EOF
 	shrext_cmds=".dll"
 	# FIXME: Setting linknames here is a bad hack.
 	_LT_TAGVAR(archive_cmds, $1)='$CC -o $output_objdir/$soname $libobjs $compiler_flags $deplibs -Wl,-dll~linknames='
-	_LT_TAGVAR(archive_expsym_cmds, $1)='if test "x`$SED 1q $export_symbols`" = xEXPORTS; then
+	_LT_TAGVAR(archive_expsym_cmds, $1)='if test "x`$SED \"$sed_uncomment_deffile\" $export_symbols | $SED 1q`" = xEXPORTS; then
 	    sed -n -e 's/\\\\\\\(.*\\\\\\\)/-link\\\ -EXPORT:\\\\\\\1/' -e '1\\\!p' < $export_symbols > $output_objdir/$soname.exp;
 	  else
 	    sed -e 's/\\\\\\\(.*\\\\\\\)/-link\\\ -EXPORT:\\\\\\\1/' < $export_symbols > $output_objdir/$soname.exp;
@@ -6149,7 +6149,7 @@ if test "$_lt_caught_CXX_error" != yes; then
 	  shrext_cmds=".dll"
 	  # FIXME: Setting linknames here is a bad hack.
 	  _LT_TAGVAR(archive_cmds, $1)='$CC -o $output_objdir/$soname $libobjs $compiler_flags $deplibs -Wl,-dll~linknames='
-	  _LT_TAGVAR(archive_expsym_cmds, $1)='if test "x`$SED 1q $export_symbols`" = xEXPORTS; then
+	  _LT_TAGVAR(archive_expsym_cmds, $1)='if test "x`$SED \"$sed_uncomment_deffile\" $export_symbols | $SED 1q`" = xEXPORTS; then
 	      $SED -n -e 's/\\\\\\\(.*\\\\\\\)/-link\\\ -EXPORT:\\\\\\\1/' -e '1\\\!p' < $export_symbols > $output_objdir/$soname.exp;
 	    else
 	      $SED -e 's/\\\\\\\(.*\\\\\\\)/-link\\\ -EXPORT:\\\\\\\1/' < $export_symbols > $output_objdir/$soname.exp;
@@ -6190,7 +6190,7 @@ if test "$_lt_caught_CXX_error" != yes; 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'
 	    # 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 "x`$SED 1q $export_symbols`" = xEXPORTS; then
+	    _LT_TAGVAR(archive_expsym_cmds, $1)='if test "x`$SED \"$sed_uncomment_deffile\" $export_symbols | $SED 1q`" = xEXPORTS; then
 	      cp $export_symbols $output_objdir/$soname.def;
 	    else
 	      echo EXPORTS > $output_objdir/$soname.def;
--8<---------------cut here---------------end--------------->8---


-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.

[signature.asc (application/pgp-signature, inline)]

Message #47 received at 13414 <at> debbugs.gnu.org (full text, mbox):

From: Pavel Raiskup <praiskup <at> redhat.com>
To: bug-libtool <at> gnu.org
Cc: 13414 <at> debbugs.gnu.org, control <at> bugs.debian.org,
 Daniel Kahn Gillmor <dkg <at> fifthhorseman.net>, 814951 <at> bugs.debian.org
Subject: Re: bug#13414: [Werner Koch] Re: [pkg-gnupg-maint] Bug#814951:
 libassuan: add libassuan-mingw-w64-dev for cross-building to Windows targets
Date: Mon, 22 Feb 2016 12:44:47 +0100

Hi Daniel,

On Saturday 20 of February 2016 14:29:47 Daniel Kahn Gillmor wrote:
> Over on https://bugs.debian.org/814951, Werner Koch and i are discussing
> how https://debbugs.gnu.org/13414 is still a problem with libtool.  In
> particular, GNU libtool can't seem to detect that a .def file is valid
> unless EXPORT is the literal first line in the file (it chokes when
> blank lines or comments precede EXPORT).
> 
> Werner supplied the patch below to fix libtool.  The upstream bug
> appears to have a rather different set of patches.  Either way, the
> problem should be cleaned up in libtool, as it's causing a series of
> workarounds for cross-building things on debian for the Windows
> platform.
> 
> Is there some reason for the delay upstream besides lack of time to work
> on it?  Should debian go ahead and apply one of the proposed patches
> downstream in the meantime?

From the patch itself:

    There is no need to send this upstream.  Upstream's git master has a
    lot of changes including a similar fix for this problems.  There are
    no signs that a libtool 2.4.3 will be released to fix this problem and
    thus we need to stick to our copy of 2.4.2 along with this patch.

It is quite some time libtool 2.4.3 was released, the latest release is 2.4.6
now.  Can you check that update helps?

Pavel

Message #53 received at 13414 <at> debbugs.gnu.org (full text, mbox):

From: Peter Rosin <peda <at> lysator.liu.se>
To: Pavel Raiskup <praiskup <at> redhat.com>, 13414 <at> debbugs.gnu.org
Cc: dkg <at> fifthhorseman.net, 814951 <at> bugs.debian.org, control <at> bugs.debian.org
Subject: Re: bug#13414: [Werner Koch] Re: [pkg-gnupg-maint] Bug#814951:
 libassuan:
 add libassuan-mingw-w64-dev for cross-building to Windows targets
Date: Mon, 22 Feb 2016 22:03:49 +0100

On 2016-02-22 12:44, Pavel Raiskup wrote:
> Hi Daniel,
> 
> On Saturday 20 of February 2016 14:29:47 Daniel Kahn Gillmor wrote:
>> Over on https://bugs.debian.org/814951, Werner Koch and i are discussing
>> how https://debbugs.gnu.org/13414 is still a problem with libtool.  In
>> particular, GNU libtool can't seem to detect that a .def file is valid
>> unless EXPORT is the literal first line in the file (it chokes when
>> blank lines or comments precede EXPORT).
>>
>> Werner supplied the patch below to fix libtool.  The upstream bug
>> appears to have a rather different set of patches.  Either way, the
>> problem should be cleaned up in libtool, as it's causing a series of
>> workarounds for cross-building things on debian for the Windows
>> platform.
>>
>> Is there some reason for the delay upstream besides lack of time to work
>> on it?  Should debian go ahead and apply one of the proposed patches
>> downstream in the meantime?
> 
> From the patch itself:
> 
>     There is no need to send this upstream.  Upstream's git master has a
>     lot of changes including a similar fix for this problems.  There are
>     no signs that a libtool 2.4.3 will be released to fix this problem and
>     thus we need to stick to our copy of 2.4.2 along with this patch.
> 
> It is quite some time libtool 2.4.3 was released, the latest release is 2.4.6
> now.  Can you check that update helps?

Hi!

The libtool patch from https://debbugs.gnu.org/13414 is better than the
debian patch from https://bugs.debian.org/814951 in every aspect that I
can see and should indeed help.

For reference, the libtool patch was committed here
http://git.savannah.gnu.org/cgit/libtool.git/commit/?id=a5a4944fbb2bbd

(three years old, released one year ago in 2.4.3)

Cheers,
Peter

Message #56 received at 13414 <at> debbugs.gnu.org (full text, mbox):

From: Daniel Kahn Gillmor <dkg <at> fifthhorseman.net>
To: Peter Rosin <peda <at> lysator.liu.se>, Pavel Raiskup <praiskup <at> redhat.com>,
 13414 <at> debbugs.gnu.org
Cc: 814951 <at> bugs.debian.org
Subject: Re: bug#13414: [Werner Koch] Re: [pkg-gnupg-maint] Bug#814951:
 libassuan: add libassuan-mingw-w64-dev for cross-building to Windows targets
Date: Wed, 02 Mar 2016 08:23:14 +0100

[Message part 1 (text/plain, inline)]

On Mon 2016-02-22 22:03:49 +0100, Peter Rosin wrote:
> The libtool patch from https://debbugs.gnu.org/13414 is better than the
> debian patch from https://bugs.debian.org/814951 in every aspect that I
> can see and should indeed help.
>
> For reference, the libtool patch was committed here
> http://git.savannah.gnu.org/cgit/libtool.git/commit/?id=a5a4944fbb2bbd
>
> (three years old, released one year ago in 2.4.3)

It sounds like you're saying that the libtool patch should already be
committed and running effectively in libtool 2.4.3 or later.

however, debian had libtool 2.4.2-1.11 up until 2016-02-07, when
2.4.6-0.1 entered debian.  But Andreas's bug report of FTBFS on unstable
[0] came 12 days after 2.4.6 entered unstable and 6 days after 2.4.6
transitioned to testing [1].  So something in the libtool upstream
changes either didn't have the desired effect, or something else is
wrong in debian that i'm unaware of.

for now, i've gone ahead with the simple patch (moving EXPORTS to the
first line of the file) for libassuan, but i'll be happy to drop that
patch when libtool is effectively fixed :)

      --dkg

[0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=814954#10
[1] https://packages.qa.debian.org/libt/libtool/news/20160213T163908Z.html

[signature.asc (application/pgp-signature, inline)]

Message #59 received at 13414 <at> debbugs.gnu.org (full text, mbox):

From: Peter Rosin <peda <at> lysator.liu.se>
To: Daniel Kahn Gillmor <dkg <at> fifthhorseman.net>, 
 Pavel Raiskup <praiskup <at> redhat.com>, 13414 <at> debbugs.gnu.org
Cc: 814951 <at> bugs.debian.org
Subject: Re: bug#13414: [Werner Koch] Re: [pkg-gnupg-maint] Bug#814951:
 libassuan:
 add libassuan-mingw-w64-dev for cross-building to Windows targets
Date: Thu, 03 Mar 2016 22:41:58 +0100

Hi!

On 2016-03-02 08:23, Daniel Kahn Gillmor wrote:
> On Mon 2016-02-22 22:03:49 +0100, Peter Rosin wrote:
>> The libtool patch from https://debbugs.gnu.org/13414 is better than the
>> debian patch from https://bugs.debian.org/814951 in every aspect that I
>> can see and should indeed help.
>>
>> For reference, the libtool patch was committed here
>> http://git.savannah.gnu.org/cgit/libtool.git/commit/?id=a5a4944fbb2bbd
>>
>> (three years old, released one year ago in 2.4.3)
> 
> It sounds like you're saying that the libtool patch should already be
> committed and running effectively in libtool 2.4.3 or later.

Yes.

> however, debian had libtool 2.4.2-1.11 up until 2016-02-07, when
> 2.4.6-0.1 entered debian.  But Andreas's bug report of FTBFS on unstable
> [0] came 12 days after 2.4.6 entered unstable and 6 days after 2.4.6
> transitioned to testing [1].  So something in the libtool upstream
> changes either didn't have the desired effect, or something else is
> wrong in debian that i'm unaware of.

Have you checked if libassuan has been libtoolized with 2.4.6? Mind you,
that is not automatically the case just because debian ships 2.4.6. Most
libraries carry a bundled copy of the libtool version they were
libtoolized with by the library maintainer prior to the library release.
Some distributions automatically relibtoolizes its packages, some don't.

> for now, i've gone ahead with the simple patch (moving EXPORTS to the
> first line of the file) for libassuan, but i'll be happy to drop that
> patch when libtool is effectively fixed :)

Please check the libtool version in the relevant version of libassuan.

Cheers,
Peter

Message #62 received at 13414 <at> debbugs.gnu.org (full text, mbox):

From: Daniel Kahn Gillmor <dkg <at> fifthhorseman.net>
To: Peter Rosin <peda <at> lysator.liu.se>, Pavel Raiskup <praiskup <at> redhat.com>,
 13414 <at> debbugs.gnu.org
Cc: 814951 <at> bugs.debian.org
Subject: Re: bug#13414: [Werner Koch] Re: [pkg-gnupg-maint] Bug#814951:
 libassuan: add libassuan-mingw-w64-dev for cross-building to Windows targets
Date: Sun, 06 Mar 2016 14:27:44 -0500

Hi Peter--

On Thu 2016-03-03 16:41:58 -0500, Peter Rosin <peda <at> lysator.liu.se> wrote:
> Have you checked if libassuan has been libtoolized with 2.4.6? Mind you,
> that is not automatically the case just because debian ships 2.4.6. Most
> libraries carry a bundled copy of the libtool version they were
> libtoolized with by the library maintainer prior to the library release.
> Some distributions automatically relibtoolizes its packages, some don't.

the debian packaging for libassuan uses dh_autoreconf, which
automatically libretoolizes.

              --dkg

Message #65 received at 13414 <at> debbugs.gnu.org (full text, mbox):

From: Peter Rosin <peda <at> lysator.liu.se>
To: Daniel Kahn Gillmor <dkg <at> fifthhorseman.net>, 
 Pavel Raiskup <praiskup <at> redhat.com>, 13414 <at> debbugs.gnu.org
Cc: 814951 <at> bugs.debian.org
Subject: Re: bug#13414: [Werner Koch] Re: [pkg-gnupg-maint] Bug#814951:
 libassuan:
 add libassuan-mingw-w64-dev for cross-building to Windows targets
Date: Mon, 07 Mar 2016 08:36:12 +0100

Hi!

On 2016-03-06 20:27, Daniel Kahn Gillmor wrote:
> Hi Peter--
> 
> On Thu 2016-03-03 16:41:58 -0500, Peter Rosin <peda <at> lysator.liu.se> wrote:
>> Have you checked if libassuan has been libtoolized with 2.4.6? Mind you,
>> that is not automatically the case just because debian ships 2.4.6. Most
>> libraries carry a bundled copy of the libtool version they were
>> libtoolized with by the library maintainer prior to the library release.
>> Some distributions automatically relibtoolizes its packages, some don't.
> 
> the debian packaging for libassuan uses dh_autoreconf, which
> automatically libretoolizes.

Then it must be something fiddly going on, the def file looks simple enough...

Maybe your .def file is infested with CR/NL line-endings, does the below patch
(untested) help?

Cheers,
Peter

diff --git a/build-aux/ltmain.in b/build-aux/ltmain.in
index 2601564..e323165 100644
--- a/build-aux/ltmain.in
+++ b/build-aux/ltmain.in
@@ -1358,12 +1358,11 @@ func_dll_def_p ()
 {
   $debug_cmd
 
-  func_dll_def_p_tmp=`$SED -n \
+  func_dll_def_p_tmp=`tr -d '\015' < "$1" | $SED -n \
     -e 's/^[	 ]*//' \
     -e '/^\(;.*\)*$/d' \
     -e 's/^\(EXPORTS\|LIBRARY\)\([	 ].*\)*$/DEF/p' \
-    -e q \
-    "$1"`
+    -e q`
   test DEF = "$func_dll_def_p_tmp"
 }
 
diff --git a/m4/libtool.m4 b/m4/libtool.m4
index ee292af..7b33d6a 100644
--- a/m4/libtool.m4
+++ b/m4/libtool.m4
@@ -3847,12 +3847,11 @@ _LT_DECL([], [MANIFEST_TOOL], [1], [Manifest tool])dnl
 # Keep in sync with func_dll_def_p in the libtool script
 AC_DEFUN([_LT_DLL_DEF_P],
 [dnl
-  test DEF = "`$SED -n dnl
+  test DEF = "`tr -d '\''\015'\'' < $1 | $SED -n dnl
     -e '\''s/^[[	 ]]*//'\'' dnl Strip leading whitespace
     -e '\''/^\(;.*\)*$/d'\'' dnl      Delete empty lines and comments
     -e '\''s/^\(EXPORTS\|LIBRARY\)\([[	 ]].*\)*$/DEF/p'\'' dnl
-    -e q dnl                          Only consider the first "real" line
-    $1`" dnl
+    -e q`" dnl                        Only consider the first "real" line
 ])# _LT_DLL_DEF_P
 
 

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.