Bug 13710 - [Regression] .def files containing LIBRARY statement can't be parsed any more
Summary: [Regression] .def files containing LIBRARY statement can't be parsed any more
Alias: None
Product: binutils
Classification: Unclassified
Component: ld (show other bugs)
Version: 2.24
: P2 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
Depends on:
Reported: 2012-02-19 22:30 UTC by Erik van Pienbroek
Modified: 2014-05-28 19:46 UTC (History)
2 users (show)

See Also:
Target: i686-w64-mingw32, x86_64-w64-mingw32
Last reconfirmed:


Note You need to log in before you can comment on or make changes to this bug.
Description Erik van Pienbroek 2012-02-19 22:30:44 UTC
In the last couple of days a change was applied to binutils which makes the behaviour of the processing of .def files more strict. Due to this change some libraries fail to compile, for example cairo.

The .def file which is used by cairo contains something along the lines of this:

LIBRARY mylib.dll

This used to work fine with binutils, but when using binutils this results in the following error:

/usr/lib64/gcc/i686-w64-mingw32/4.7.0/../../../../i686-w64-mingw32/bin/ld: a.def:3: syntax error
/usr/lib64/gcc/i686-w64-mingw32/4.7.0/../../../../i686-w64-mingw32/bin/ld:a.def: file format not recognized; treating as linker script
/usr/lib64/gcc/i686-w64-mingw32/4.7.0/../../../../i686-w64-mingw32/bin/ld:a.def:2: syntax error
collect2: error: ld returned 1 exit status

After some discussion with Kai Tietz we came to the conclusion that these type of .def files are invalid according to MSDN: http://msdn.microsoft.com/en-us/library/d91k01sh%28v=vs.80%29.aspx

This documentation indicates that .def files must start with the 'LIBRARY xxx.dll' statement followed by the 'EXPORTS' statement, so in this regard the more strict behaviour of binutils is correct.

So I tried fixing cairo so that it uses a .def file which looks like this:

LIBRARY mylib.dll

While doing so I noticed that libtool also tries to do some funny things with the .def file:

libtool: link: if test "x`/bin/sed 1q .libs/libcairo.def`" = xEXPORTS; then cp .libs/libcairo.def .libs/libcairo-2.dll.def; else echo EXPORTS > .libs/libcairo-2.dll.def; cat .libs/libcairo.def >> .libs/libcairo-2.dll.def; fi

It looks like libtool always checks the first line of the given .def file. If this first line isn't 'EXPORTS' then it will be automatically added to the resulting .def file. Given the .def file above, the resulting .def file will become:

LIBRARY mylib.dll

This .def file isn't accepted by binutils as well.

So to fix all this, changes have to be applied to both cairo and libtool. However, the annoying thing with libtool is that every libtool-using piece of software is bundling their own copy of libtool so it will take quite some time before a patched version of libtool is really in use. While I agree that binutils should be as compliant and strict as possible I think that the damage here is worse than the benefits. So I would like to suggest that this change in behaviour in binutils is reverted to the old behaviour (for now) and that we also try to get this fixed properly in libtool, cairo and perhaps several other pieces of software.
Comment 1 Erik van Pienbroek 2012-02-19 22:46:44 UTC
Filed bugs for libtool and cairo:
libtool: https://savannah.gnu.org/support/index.php?107959
cairo: https://bugs.freedesktop.org/show_bug.cgi?id=46299
Comment 2 cvs-commit@gcc.gnu.org 2012-02-24 14:20:27 UTC
CVSROOT:	/cvs/src
Module name:	src
Changes by:	ktietz@sourceware.org	2012-02-24 14:20:19

Modified files:
	binutils       : ChangeLog defparse.y 
	binutils/doc   : binutils.texi 
	ld             : ChangeLog deffilep.y 

Log message:
	PR binutils/13710
	* defparse.y (keyword_as_name): Disable LIBRARY
	* doc/binutils.texi: Document LIBRARY exception.
	PR binutils/13710
	* deffilep.y (keyword_as_name): Disable LIBRARY

Comment 3 Kai Tietz 2012-02-24 14:24:53 UTC
Comment 4 Jackie Rosen 2014-02-16 17:50:37 UTC
*** Bug 260998 has been marked as a duplicate of this bug. ***
Seen from the domain http://volichat.com
Page where seen: http://volichat.com/adult-chat-rooms
Marked for reference. Resolved as fixed @bugzilla.