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

From: Peter Rosin <[email-masked]>
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