bug#13414: Valid DLL def file mangled by libtool

[Earnie Boyd]

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