Home Page Forums MAME MAME Look like Mingw is broken.

D:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/11.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe and some other messages on the mame,exe building.
I closed the Malwarebytes program and it still coming up with the ld.exe issues. So I don't know why it showing these issues. lol

msys64-2022-01-12.exe

If there a update on this piece of tool. Please let me know.

Compiling resources generated/resource/mame_mame_vers.rc...
39132 driver(s) found
Compiling generated/mame/mame/drivlist.cpp...
Linking mame.exe...
D:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/11.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: ../../../../mingw-gcc/bin/x64/Release/libemu.a(emumem_aspace.o):emumem_aspace.:(.text+0x85a): undefined reference to `vtable for address_space'
D:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/11.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: ../../../../mingw-gcc/bin/x64/Release/libemu.a(emumem_aspace.o):emumem_aspace.:(.text+0x8e7): undefined reference to `vtable for std::_Sp_counted_ptr_inplace<int, std::allocator<int>, (__gnu_cxx::_Lock_policy)2>'
D:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/11.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: ../../../../mingw-gcc/bin/x64/Release/libemu.a(emumem_aspace.o):emumem_aspace.:(.text+0x18fd): undefined reference to `vtable for address_space'
D:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/11.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: ../../../../mingw-gcc/bin/x64/Release/libemu.a(emumem_aspace.o):emumem_aspace.:(.text+0x1bb6): undefined reference to `vtable for std::_Sp_counted_ptr_inplace<emu::detail::memory_passthrough_handler_impl, std::allocator<emu::detail::memory_passthrough_handler_impl>, (__gnu_cxx::_Lock_policy)2>'

........ Skip the rest to here below.

D:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/11.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: ../../../../mingw-gcc/bin/x64/Release/libemu.a(emumem_aspace.o):emumem_aspace.:(.rdata$_ZTVSt23_Sp_counted_ptr_inplaceIN3emu6detail31memory_passthrough_handler_implESaIS2_ELN9__gnu_cxx12_Lock_policyE2EE+0x8): undefined reference to `typeinfo for std::_Sp_counted_ptr_inplace<emu::detail::memory_passthrough_handler_impl, std::allocator<emu::detail::memory_passthrough_handler_impl>, (__gnu_cxx::_Lock_policy)2>'
D:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/11.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: ../../../../mingw-gcc/bin/x64/Release/libemu.a(emumem_aspace.o):emumem_aspace.:(.rdata$_ZTVSt23_Sp_counted_ptr_inplaceIiSaIiELN9__gnu_cxx12_Lock_policyE2EE+0x8): undefined reference to `typeinfo for std::_Sp_counted_ptr_inplace<int, std::allocator<int>, (__gnu_cxx::_Lock_policy)2>'
collect2.exe: error: ld returned 1 exit status
mame.make:270: recipe for target '../../../../../mame.exe' failed
make[2]: *** [../../../../../mame.exe] Error 1
makefile:1099: recipe for target 'mame' failed
make[1]: *** [mame] Error 2
makefile:1118: recipe for target 'windows_x64' failed
make: *** [windows_x64] Error 2

Works fine on Ubuntu. No problem there.

Use lld until the issue with GNU ld is resolved.

I rename ld.exe to ld-saved.exe

Copied lld.exe and then rename it to ld.exe.

Hey it works. Thanks for pointing at lld.exe.

Why don’t you just follow the instructions for using lld? Why do people insist on doing things wrong?
https://docs.mamedev.org/initialsetup/compilingmame.html#linking-using-the-llvm-linker

I didn't know what file this need to be on. -fuse-ld=lld I already look at it earlier. Just confused.

Took the shortcut.

To be fair, the documentation (as of today) doesn't say anything about GNU ld being broken/unusable, only slower than lld. It should maybe be worded differently if using GNU ld is wrong.

make -j8 ARCHOPTS="-fuse-ld=lld" REGENIE=1

worked for me. I had to look up how to pass the -fuse-ld=lld parameter.

GNU ld wasn't broken until 2 days ago, and it may not be permanently broken (we need OG back in France to find out though).

Thanks for the command. I will revert the files back now.

I'm of the opinion that this is a major enough issue affecting enough people who use the 100% mamedev.org approved/published tool package in Windows that code reverting or placing in a branch would be a great option until such time work can be done to address the issue. The response has been, in my opinion, lackadaisical. It didn't affect the more prominent developers, so there has been little effort put in to make it better for those who are struggling to find a solution. For my circumstances, LLD is not an option due to issues related to using RAMDISK as the storage for compiling (saving on hardware thrashing) and not being handled properly by the linker. I will be exploring this further to see if either a cutting edge LLD or something prior to the version issued around the time the compile package was assembled.

Anyway, until things square away, my testing efforts will be at a minimum or not nearly at all as my local machine struggles to compile, especially since CPU-base Video is my only choice meaning that I can do literally nothing else while compiling for 1-2 hours. If OG will be gone for more than a couple days, please consider stowing the changes away for now. The last couple days have been pretty discouraging.