[Bug binutils/13682] New: delay-load doesn't work for target x86_64-w64-mingw32

2012-02-11 Thread erik-sources-redhat-bugzilla at vanpienbroek dot nl
http://sourceware.org/bugzilla/show_bug.cgi?id=13682

 Bug #: 13682
   Summary: delay-load doesn't work for target x86_64-w64-mingw32
   Product: binutils
   Version: 2.23 (HEAD)
Status: NEW
  Severity: normal
  Priority: P2
 Component: binutils
AssignedTo: unassig...@sourceware.org
ReportedBy: erik-sources-redhat-bugzi...@vanpienbroek.nl
CC: ktiet...@googlemail.com
Classification: Unclassified


Generating a delay-load import library using dlltool fails to work for the
x86_64-w64-mingw32 target:

$ cat mylib.def 
LIBRARY mylib.dll
EXPORTS
my_func

$ x86_64-w64-mingw32-dlltool --def mylib.def --kill-at --output-delaylib
mylib.dll.a -n
dxeuh.s: Assembler messages:
dxeuh.s:5: Error: invalid instruction suffix for `push'
dxeuh.s:6: Error: invalid instruction suffix for `push'
dxeuh.s:7: Error: invalid instruction suffix for `push'
dxeuh.s:8: Error: invalid instruction suffix for `push'
dxeuh.s:10: Error: invalid instruction suffix for `pop'
dxeuh.s:11: Error: invalid instruction suffix for `pop'
dxeuh.s:12: Error: operand type mismatch for `jmp'
x86_64-w64-mingw32-dlltool: x86_64-w64-mingw32-as exited with status 1
x86_64-w64-mingw32-dlltool: failed to open temporary head file: dxeuh.o: No
such file or directory

$ cat dxeuh.s 
# Import trampoline
.section.text
.global__tailMerge_mylib_dll_a
__tailMerge_mylib_dll_a:
pushl %ecx
pushl %edx
pushl %eax
pushl $__DELAY_IMPORT_DESCRIPTOR_mylib_dll_a
call ___delayLoadHelper2@8
popl %edx
popl %ecx
jmp *%eax

# DELAY_IMPORT_DESCRIPTOR
.section.text$2
.global __DELAY_IMPORT_DESCRIPTOR_mylib_dll_a
__DELAY_IMPORT_DESCRIPTOR_mylib_dll_a:
.long 1# grAttrs
.rva__mylib_dll_a_iname# rvaDLLName
.rva__DLL_HANDLE_mylib_dll_a# rvaHmod
.rva__IAT_mylib_dll_a# rvaIAT
.rva__INT_mylib_dll_a# rvaINT
.long0# rvaBoundIAT
.long0# rvaUnloadIAT
.long0# dwTimeStamp

.section .data
__DLL_HANDLE_mylib_dll_a:
.long0# Handle

#Stuff for compatibility
.section.idata$5
.long0
.long0
__IAT_mylib_dll_a:
.section.idata$4
.long0
.section.idata$4
__INT_mylib_dll_a:
.section.idata$2


If the same command is tried using i686-w64-mingw32-dlltool then the import
library is generated without problems.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils


[Bug ld/13710] New: [Regression] .def files containing LIBRARY statement can't be parsed any more

2012-02-19 Thread erik-sources-redhat-bugzilla at vanpienbroek dot nl
http://sourceware.org/bugzilla/show_bug.cgi?id=13710

 Bug #: 13710
   Summary: [Regression] .def files containing LIBRARY statement
can't be parsed any more
   Product: binutils
   Version: 2.23 (HEAD)
Status: NEW
  Severity: normal
  Priority: P2
 Component: ld
AssignedTo: unassig...@sourceware.org
ReportedBy: erik-sources-redhat-bugzi...@vanpienbroek.nl
CC: ktiet...@googlemail.com
Classification: Unclassified
Target: i686-w64-mingw32, x86_64-w64-mingw32


In the last couple of days a change was applied to binutils which makes the
behaviour of the processing of .def files more strict. Due to this change some
libraries fail to compile, for example cairo.

The .def file which is used by cairo contains something along the lines of
this:

EXPORTS
my_func
LIBRARY mylib.dll

This used to work fine with binutils 2.22.51.20120113, but when using binutils
2.22.52.20120216 this results in the following error:

/usr/lib64/gcc/i686-w64-mingw32/4.7.0/../../../../i686-w64-mingw32/bin/ld:
a.def:3: syntax error
/usr/lib64/gcc/i686-w64-mingw32/4.7.0/../../../../i686-w64-mingw32/bin/ld:a.def:
file format not recognized; treating as linker script
/usr/lib64/gcc/i686-w64-mingw32/4.7.0/../../../../i686-w64-mingw32/bin/ld:a.def:2:
syntax error
collect2: error: ld returned 1 exit status

After some discussion with Kai Tietz we came to the conclusion that these type
of .def files are invalid according to MSDN:
http://msdn.microsoft.com/en-us/library/d91k01sh%28v=vs.80%29.aspx

This documentation indicates that .def files must start with the 'LIBRARY
xxx.dll' statement followed by the 'EXPORTS' statement, so in this regard the
more strict behaviour of binutils is correct.

So I tried fixing cairo so that it uses a .def file which looks like this:

LIBRARY mylib.dll
EXPORTS
my_func

While doing so I noticed that libtool also tries to do some funny things with
the .def file:

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

It looks like libtool always checks the first line of the given .def file. If
this first line isn't 'EXPORTS' then it will be automatically added to the
resulting .def file. Given the .def file above, the resulting .def file will
become:

EXPORTS
LIBRARY mylib.dll
EXPORTS
my_func

This .def file isn't accepted by binutils as well.

So to fix all this, changes have to be applied to both cairo and libtool.
However, the annoying thing with libtool is that every libtool-using piece of
software is bundling their own copy of libtool so it will take quite some time
before a patched version of libtool is really in use. While I agree that
binutils should be as compliant and strict as possible I think that the damage
here is worse than the benefits. So I would like to suggest that this change in
behaviour in binutils is reverted to the old behaviour (for now) and that we
also try to get this fixed properly in libtool, cairo and perhaps several other
pieces of software.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils


[Bug ld/13710] [Regression] .def files containing LIBRARY statement can't be parsed any more

2012-02-19 Thread erik-sources-redhat-bugzilla at vanpienbroek dot nl
http://sourceware.org/bugzilla/show_bug.cgi?id=13710

--- Comment #1 from Erik van Pienbroek  2012-02-19 22:46:44 UTC ---
Filed bugs for libtool and cairo:
libtool: https://savannah.gnu.org/support/index.php?107959
cairo: https://bugs.freedesktop.org/show_bug.cgi?id=46299

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils