libtool
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Bernhard Reutner-Fischer
Subject: Re: [sr #107959] Libtool generates invalid .def files
Date: Tue, 21 Feb 2012 20:36:55 +0100

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

Rehi peda :)

> > 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…
>
> 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


reply via email to

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