Thanks David!
After a couple of PRs we’re now down to a linker issue regarding exception
handling on Windows. Details and steps to reproduce here:
https://github.com/gnustep/libobjc2/issues/187
> These are pretty-much unavoidable on Windows. In C/C++, you typically use a
> macro to control dlimport / dlexport of various things depending on whether
> you’re building the library or building something using the library. You can
> do this in Objective-C now, but it requires annotating all of the classes in
> -base, -gui. I think both of these projects already provide a macro that
> tells you that you’re building the library itself, so maybe it’s not too
> painful.
Good to know, thanks. I can take a look once we get this to work.
> Yup, these were missing their OBJC_PUBLIC things. Actually, your PR put them
> on the definitions, which might not be right - they probably should go in the
> .h so that they become dlimport when not building libobjc2.
Yes this is solved now. The PR put the macro in both the .c and .h, which I
think is correct?
> Neither am I. These are used for DWARF exception handling, which we
> shouldn’t be doing on Windows. It may be that we get them from using a MinGW
> or Cygwin target triple when building GNUstep?
Some of these were also resolved by the PR (all the ones using OBJC_HOOK), so
we’re just left with the exception handling ones (see above). Clang should be
using SEH exception handling (not DWARF) according to verbose output, so it’s
all pretty strange to me.
With the fixes in Make and Base it’s now also no longer necessary to manually
provide header/library search paths, or to copy objc.dll.
The only extra thing required for building Make is specifying LLD as the
linker, which we could probably select automatically when using the 2.0 runtime
(see also the discussion in https://github.com/gnustep/tools-make/pull/4):
./configure --prefix=/c/GNUstep/x86 --with-library-combo=ng-gnu-gnu
--with-runtime-abi=gnustep-2.0 LDFLAGS="-fuse-ld=lld"
Thanks,
Frederik
