https://bugs.winehq.org/show_bug.cgi?id=54940
Jacek Caban jacek@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jacek@codeweavers.com
--- Comment #4 from Jacek Caban jacek@codeweavers.com --- Ideally, importlibs should not need assembler at all. There is a separated format for COFF import libs, which is simple enough that we could just generate it ourselves (ideally dlltool would use that instead; llvm-dlltool, llvm-lib and MSVC lib.exe do). When such import libs are used, it's linker's responsibility to generate thunks, importlibs shouldn't contain any actual code.
While the above would probably be fine with ld.bfd for regular imports, it wouldn't work for delay load imports. ld.bfd just doesn't support delay loads at all, that's why the hack in dlltool exists in the first place. If someone is willing to work on improving binutils, I suggest starting with linker support for delay loads and getting rid of dependency on the hack.
BTW, for ELF target binutils developers decided that it's better to reimplement the linker in form of gold instead of trying to improve ld.bfd. The same is likely true for COFF targets and I see little point in reimplementing it again when lld-link exists. GCC also supports -fuse-ld=lld, it should be possible to make it work that way.