[Bug ld/25374] linking to msvc import library results in invalid IDT entry
https://sourceware.org/bugzilla/show_bug.cgi?id=25374 Mateusz Mikuła changed: What|Removed |Added CC||mati865 at gmail dot com -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/25374] linking to msvc import library results in invalid IDT entry
https://sourceware.org/bugzilla/show_bug.cgi?id=25374 --- Comment #4 from Martin Storsjö --- The issue shown in the reproduction sample posted by Petteri seems to have been caused by a regression in binutils 2.34, that was fixed again in binutils 2.35. The commit that caused the breakage was this one: https://sourceware.org/git/?p=binutils-gdb.git;a=commitdiff;h=90d92a632aaf75ce698335efeb383ddf785c12d8 The issue was resolved later by this commit: https://sourceware.org/git/?p=binutils-gdb.git;a=commitdiff;h=5e365e474b7561318ddb1a107f05cf0c002e8284 It's possible that this also was the same issue that this bug was filed about, but it could also maybe have been a different issue. I'm not able to reproduce any bug similar to this with current versions of binutils though. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/25374] linking to msvc import library results in invalid IDT entry
https://sourceware.org/bugzilla/show_bug.cgi?id=25374
--- Comment #3 from Dan Raymond ---
Created attachment 13425
--> https://sourceware.org/bugzilla/attachment.cgi?id=13425=edit
script to convert import library from MSVC-style to MinGW-style
Until this bug is fixed one way to work around it is to convert the import
library from MSVC style ("short form") to MinGW style ("long form"). The
attached Python script will do this.
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug ld/25374] linking to msvc import library results in invalid IDT entry
https://sourceware.org/bugzilla/show_bug.cgi?id=25374 Felix Schwarz changed: What|Removed |Added CC||felix.schwarz at oss dot schwarz.e ||u -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/25374] linking to msvc import library results in invalid IDT entry
https://sourceware.org/bugzilla/show_bug.cgi?id=25374 Petteri Aimonen changed: What|Removed |Added CC||jpa at sourceware dot mail.kapsi.f ||i --- Comment #2 from Petteri Aimonen --- I think I hit the same problem, initially commented on this mingw64 bug report: https://sourceforge.net/p/mingw-w64/bugs/831/ In case it helps tracking the bug down, here is a self-contained test case: https://jpa.kapsi.fi/stuff/other/mingw-bug-831.tar.gz -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/25374] linking to msvc import library results in invalid IDT entry
https://sourceware.org/bugzilla/show_bug.cgi?id=25374 Martin Storsjö changed: What|Removed |Added CC||martin at martin dot st --- Comment #1 from Martin Storsjö --- (In reply to Dan Raymond from comment #0) > Examination of the .idata section in the MinGW DLL revealed that ILT and IAT > tables were present for both the MSVC DLL and EXE. The IDT entry (which > contains pointers to the ILT and IAT) was correct for the MSVC DLL. The IDT > entry for the MSVC EXE, however, was incorrect. The ILT and IAT pointers > pointed to the NULL entries at the end of the tables rather than the first > entries. I was able to reproduce a similar issue when linking against two import libraries for two DLLs (without involving the concept of EXEs exporting symbols and import libraries for them). My suspicion is that the synthesized import table chunks (when using msvc style import libraries, where the linker needs to synthesize the import table contents) aren't sorted correctly if there's more than one msvc style import library involved. -- You are receiving this mail because: You are on the CC list for the bug.
