[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#13414: Valid DLL def file mangled by libtool
From: |
Peter Rosin |
Subject: |
bug#13414: Valid DLL def file mangled by libtool |
Date: |
Mon, 14 Jan 2013 15:13:37 +0100 |
User-agent: |
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 |
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
- bug#13414: Valid DLL def file mangled by libtool, Martin Doucha, 2013/01/11
- bug#13414: Valid DLL def file mangled by libtool, Peter Rosin, 2013/01/18
- bug#13414: [PATCH 1/2] libtool: allow tabs in $cmds variables, Peter Rosin, 2013/01/18
- bug#13414: [PATCH 2/2] libtool: factor out the dll .def file test and improve it, Peter Rosin, 2013/01/18
- bug#13414: Valid DLL def file mangled by libtool, Gary V. Vaughan, 2013/01/19
- bug#13414: Valid DLL def file mangled by libtool, Peter Rosin, 2013/01/20
- bug#13414: Valid DLL def file mangled by libtool, Erik van Pienbroek, 2013/01/20
- bug#13414: Valid DLL def file mangled by libtool, Erik van Pienbroek, 2013/01/22
- bug#13414: Valid DLL def file mangled by libtool, Peter Rosin, 2013/01/22