Hi David, > Am 02.02.2021 um 12:29 schrieb David Chisnall <gnus...@theravensnest.org>: > >>>> lld-link: error: relocation against symbol in discarded section: >>>> __start_.objcrt$SEL >>>> >>> referenced by C:\msys64\tmp\conftest-78a937.o:(.objc_init) >>>> This is reproducible when building a file that calls ObjC runtime >>>> functions but doesn’t actually contain any ObjC code. Not sure if that’s >>>> expected behavior or bug. >>> >>> I think this is a bug, probably a clang bug (and probably my fault) >> Should I open an LLVM issue for this? > > Yes please. There was an identical bug on ELF platforms, I may have failed > to fix it for Windows.
Here you go, please let me know if you need any other info: https://bugs.llvm.org/show_bug.cgi?id=49681 >>> Awesome work, and it makes me much happier than trying to support MinGW. >> Thank you, glad you like it! This is also exciting to us because it should >> e.g. allow us to use recent Windows technologies like the C++/WinRT language >> projection from ObjC++ which are not compatible with MinGW. >> That being said, I would still very much like to get libobjc2 working with >> MinGW as well, as it would allow people currently using GNUstep with GCC in >> a MinGW environment to switch to Clang/libobjc2, should result in a more >> streamlined setup experience with all dependencies being available via MinGW >> packages and everything being built in one shell, and allow for existing >> MinGW-based software to be used. >> I’ll try to get you those instructions for building LLVM with the MinGW >> patches in the next couple weeks. > > I'll try to find some time to work on it. I’ve finally found steps to reproduce the issues with MinGW using a "normal" (non-MinGW) LLDB build using a CMake toolchain file: https://github.com/gnustep/libobjc2/pull/190#issuecomment-792676170 Hopefully that will be sufficient to look into these at some point. Thanks! Frederik
