Hi Martin, Erik, On 2013-01-12 01:26, Peter Rosin wrote: > Hi Martin, > > Thanks for the report. > > On 2013-01-11 12:34, Martin Doucha wrote: >> Hi, >> I'd like to report a bug in libtool 2.4 (including the latest git revision) >> which mangles valid DLL def files under MinGW and makes the linker barf. >> >> The bug is caused by incorect check for "EXPORTS" keyword in the def file >> which libtool does this way: >> if test "x`$SED 1q $export_symbols`" != xEXPORTS; then ... [add another >> "EXPORTS" line at the beginning of file] >> >> This test is incorrect because the "EXPORTS" keyword does not have to appear >> on the very first line. You should replace the test with this: >> if test "x`$GREP EXPORTS $export_symbols`" != xEXPORTS; then ... >> >> Also note that this test appears on several places throughout libtool >> sources (both as "xEXPORTS" and just "EXPORTS") so you need to fix all of >> them. > > This issue has been reported before [1]. > > It's been on my back burner for a while, but I've been held up by > build system issues. At least, that's my excuse :-) > > Anyway, I think your suggested alternative with grep is a bit too > relaxed, as any symbol involving the substring "EXPORTS" would > trigger it. Also, it scans the whole file, which is suboptimal. > > I'm looking into a patch that uses > > $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...) > > [1] http://lists.gnu.org/archive/html/libtool/2012-02/msg00023.html > [2] http://msdn.microsoft.com/en-us/library/h41zhe21(v=vs.110).aspx
I'm back, with suggested changes against latest git, and I'm curious if it is enough to solve your problem? If you are not able to check for some reason, it might be possible for you to provide the .def file you had the problem with? (this question was mainly for Martin, Erik had enough specifics in his report) Also, while I recognize that my evaluation of Martin's patch was flawed in that his grep-based patch doesn't trigger on any symbol with EXPORTS as a substring (which I stated, I was using the mental model of my patch on his code, and stumbled), it still reads the whole .def file and doesn't catch .def files with a symbol on the same line as the EXPORTS keyword... So, as hinted above, I'm following up with a pair of patches that appear to mend this. Ok to push? Or are the white-space changes in the first patch too intrusive? Cheers, Peter
