bug-libtool
[Top][All Lists]
Advanced

[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






reply via email to

[Prev in Thread] Current Thread [Next in Thread]