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