On Feb 21, 2012 5:30 PM, <p...@lysator.liu.se> 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
_______________________________________________ https://lists.gnu.org/mailman/listinfo/libtool
