Hi David, > Am 19.01.2021 um 18:40 schrieb David Chisnall <gnus...@theravensnest.org>: > > On ELF platforms, there were some issues with the ld -r invocation that -base > Additions did. Can you try just adding the .m files from Additions directly > to the -base project and see if that makes the problem go away? I don't > think that PE/COFF linkage really has any concept that maps to how we do the > subproject thing in -make.
I’m using "ar cr ..." instead of "ld -r" as the subproject merge command, as that’s what the MinGW targets were using with Clang. I can also see all the NS*.m.o object files of the various classes that I’m getting errors for being passed directly to the linker, so I’m guessing that’s not it. I can see with nm that the object files contain the relevant symbols, but the generated gnustep-base.lib does not (not sure about the DLL). I’m wondering if these symbols need to be specially marked to be exported or I’m missing some linker flag? With MinGW we’re passing the object files between --whole-archive / --no-whole-archive, but that flag isn’t recognized by lld-link. This is the (abbreviated) linker invocation I have right now: clang -Wl,-dll -Wl,-export-all-symbols -fuse-ld=lld -Wl,/subsystem:console -o ./obj/gnustep-base-1_27.dll obj/libgnustep-base.obj/GSArray.m.o <all-other-object-files> Additions/obj/subproject.o win32/obj/subproject.o -lffi -lWs2_32 -lpthread -ladvapi32 -luser32 -lshell32 -lnetapi32 -lobjc Thanks! Frederik
