Re: [sr #107959] Libtool generates invalid .def files

[peda]

> On Feb 21, 2012 5:30 PM, <address@hidden> wrote:
>>
>> > URL:
>> >   <http://savannah.gnu.org/support/?107959>
>> >
>> *snip*
>
> Rehi peda :)

Hi, long time no see! :-)

>> > Details:
>> >
>> > This is a follow-up from
>> > http://sourceware.org/bugzilla/show_bug.cgi?id=13710
>> >
>> > In the latest binutils snapshots, a change was applied which makes the
>> > processing of .def files for the win32/win64 targets more strict.
>> > According to
>> > the MSDN documentation at
>> > http://msdn.microsoft.com/en-us/library/d91k01sh%28v=vs.80%29.aspx all
>> > .def
>> > files must start with 'LIBRARY mylib.dll' followed by 'EXPORTS'.
>>
>> Anyone using the MSDN as a reference in subtle matters such as this
>> must bring a fair bit of salt.  If you instead look at this
>>
>> http://msdn.microsoft.com/en-us/library/30fw19zw%28v=vs.80%29.aspx
>
> I.e.: -e /LIBRARY/d
> Before that. But wouldn't that break named libraries, after all?
> If it would I'd tend to switch that hunk to awk, short of a grep ||
>
> Just my 2¢, without having the chance to look at the actual M$ behaviour…

I probably overreacted a bit as I read into the report that binutils
required a LIBRARY line, but on re-reading I can see that it
actually doesn't say if binutils now requires a LIBRARY line, or
if the requirement simply is that if such a line exists it has to
be the first line.

So, I guess the question is what breaks if cairo simply drops
the LIBRARY line?

BTW, I can't look up the Microsoft bahavior either, not until next
week anyway as I'm off skiing.

>> it is not needed to have any LIBRARY statement AT ALL.  And the MS
>> tools don't need any LIBRARY statement.  Breaking stuff arbitrarily
>> in binutils, using a weak MSDN reference as defence, is just crazy.
>>
>> > Let's take this simple .def file for example:
>> >
>> > LIBRARY mylib.dll
>> > EXPORTS
>> > my_func
>> >
>> > If this .def file is processed by libtool then it automatically
>> performs
>> this
>> > set of commands:
>> >
>> > 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
>> >
>> > This set of commands check if the first line of the .def file contains
>> > 'EXPORTS' and if this isn't the case, it automatically adds it.
>>
>> That's not a completely accurate description, libtool is using the
>> EXPORTS header in the list of exported symbols as a key that this
>> is not a raw exports list, but instead a handwritten .def file.  So,
>> if libtool doesn't find EXPORTS on the first line it assumes that
>> the file is a raw list of exported symbols, which on windows means
>> that it will have to be modified into a .def file (by adding a line
>> with the EXPORTS header).
>>
>> So, the fix in libtool is fairly straight-forward, but the case for
>> needing the LIBRARY line in the .def file is non-existant if you ask
>> me.
>>
>> > Given the example .def file I mentioned earlier this will end up in:
>> >
>> > EXPORTS
>> > LIBRARY mylib.dll
>> > EXPORTS
>> > my_func
>> >
>> > This obviously is incorrect and can't be processed by binutils.
>> >
>> > Can libtool be changed so that it can process these kind of situations
>> > more properly?
>>
>> Yes, of course it /can/, but IMHO it is binutils that needs to be
> un-broken.
>>
>> Cheers,
>> Peter
>>
>>
>>
>> _______________________________________________
>> https://lists.gnu.org/mailman/listinfo/libtool
>