search

msys2 / MINGW-packages

Package scripts for MinGW-w64 targets to build under MSYS2.
https://packages.msys2.org
BSD 3-Clause "New" or "Revised" License
2.29k stars 1.22k forks source link

libusb broken exports #9706

Closed revelator closed 3 years ago

revelator commented 3 years ago

not sure if this only happens with clang but libusb seems to have broken exports. mingw-w64-virt-viewer is broken because of this as it complains about these.

revelator commented 3 years ago

yep the dll is broken :S i just linked to the static version of the library and it works with that.

jeremyd2019 commented 3 years ago

Yeah, think I've seen this in #9626, but haven't had time to investigate it. Initial guess is it's from lack of --add-stdcall-alias support, but not sure.

revelator commented 3 years ago

oh yeah that would explain it :S

revelator commented 3 years ago

yep same export gets reported as missing here, so that seems to be the problem.

jeremyd2019 commented 3 years ago

It seems like --add-stdcall-alias shouldn't even be needed now that --enable-stdcall-fixup is available (https://reviews.llvm.org/D104532), but something must be going wrong, because it manages to link, but fail at runtime. @mstorsjo any thoughts? (quick recap: libusb exports stdcall-mangled names, but somehow we're getting runtime missing export errors on non-mangled names, which indeed do not exist).

jeremyd2019 commented 3 years ago

oops, it looks like libusb regenerates its import lib from a shipped def file, but lets libtool do whatever magic it does to generate the dll, so that's how it can wind up being mismatched and link but not run.

revelator commented 3 years ago

from what i can glean of libusb-compat it seems to need undecorated exports from libusb eg. no @number so im experimenting with --kill-at.

Alexpux commented 3 years ago

Well I do previously hacks on some libs to get proper undecorated symbols. Look at https://github.com/msys2/MINGW-packages/blob/3429e73950f14cefa5efcbaa6a6dac8f6da92174/mingw-w64-vulkan-loader/PKGBUILD#L69

revelator commented 3 years ago

hmm not sure, --kill-at is allready used by dlltool but does not seem to undecorate the symbols from the def. might be better just rewriting this to use ld and some of the same options used in libusb-win32.

like this which fixed building it with clang ->

DLL_LDFLAGS = -s -shared \
    -Wl,--kill-at \
    -Wl,--out-implib,$(LIB_TARGET).a \
    -Wl,--enable-stdcall-fixup
jeremyd2019 commented 3 years ago

I think I've got something working. Bit more testing and I'll make a PR

revelator commented 3 years ago

great :) though i noticed something rather fubar clangs dlltool actually supports --add-stdcall-alias but the linker does not xD

jeremyd2019 commented 3 years ago

I don't think llvm's dlltool does support that. At least it's not in its --help output.

revelator commented 3 years ago

aye many options are not, but yeah it seems to do, atleast it does not complain about this flag but you can not use it with -Wl, because that would pass it onto the linker as well and that unfortunatly does not support it.

revelator commented 3 years ago

your fix works fine btw :)