Re: Building GUI with libobjc2 for Windows MSVC

[David Chisnall]

On 27/10/2021 11:39, Frederik Seiffert wrote:
> So I tested this some more, and after rebuilding libs-base as a whole (I had 
> previously only rebuilt the relevant files) I’m getting the following linker 
> errors:
>
> > lld-link: error: <root>: undefined symbol: Q^?LL}
> > lld-link: error: <root>: undefined symbol: ^{autorelease_array_list}II[0☺]}
> > lld-link: error: <root>: undefined symbol: 
> > ^{_NSZone}QQ^{_GSIMapBucket}^{_GSIMapNode}Q^^{_GSIMapNode}Q}
> > lld-link: error: <root>: undefined symbol: ciiC[38C]}
> > lld-link: error: <root>: undefined symbol: {_RTL_SRWLOCK=^v}ALIi}
> > lld-link: error: <root>: undefined symbol: ^v}
> > lld-link: error: <root>: undefined symbol: ^?^?^?^?^?^?^?Q☺^{_NSZone}}
> > lld-link: error: <root>: undefined symbol: 
> > ^{_NSNotificationQueueRegistration}^{_NSNotificationQueueRegistration}}
> > lld-link: error: <root>: undefined symbol: ☺I^☺ii}
> > lld-link: error: <root>: undefined symbol: i☺☺}
> > lld-link: error: <root>: undefined symbol: 
> > [16{_SETJMP_FLOAT128=[2Q]}]^{_NSHandler}☺}
> > lld-link: error: <root>: undefined symbol: QQ}
> > lld-link: error: <root>: undefined symbol: 
> > ^{_xmlDoc}^{_xmlDtd}^{_xmlEntity}^{_xmlNode})
> > lld-link: error: <root>: undefined symbol: ☺☺{?=b0I1b1I31}}
> > lld-link: error: <root>: undefined symbol: b0I1b1I1b2I1b3I1b4I1b5I1b6I1b7I1b8I1}
>
>
> I’m not sure if they indicate an issue with the patch, or if it’s rather an 
> issue e.g. with how I built Clang or how I’m using the custom build? I used the 
> LLVM_ENABLE_PROJECTS=clang CMake option to build Clang, but maybe I need to 
> enable other LLVM projects like lld, libcxx or others too?

These look as if they're still clang bugs.  All of these look like they 
are fragments of Objective-C type encodings. The second one, for 
example, is a pointer to a *almost* all of the type of the 
autorelease_array_list structure: the next pointer, the size, the count, 
and a zero-sized array of the rest.  It's missing the open brace and the 
name of the structure though.

Since all of them end with a close brace, I suspect that there's 
something in the field names that isn't a valid PE/COFF symbol name (at 
least for dllexported things, not sure if the restrictions are different 
here).  The second one was the easiest to find, since only one class in 
GNUstep looks like it implements this (note: *something* is wrong in 
your build environment because I don't think we should be seeing that 
version when targeting an ARC-enabled runtime and the one fourth from 
the button looks as if it's trying to use the old NeXT-style exceptions 
rather than SEH, but it helps find the bug so let's leave it for now).

The generated variable should be:

__objc_ivar_offset_NSAutoreleasePool._release.^{autorelease_array_list=^{autorelease_array_list}II[0\01]}

So it looks as if it's being truncated at the first equals sign?  I 
wonder if equals is not permitted in dllexported symbols?  This doesn't 
seem to cause problems for DLL-local symbols on Windows.

In clang/lib/CodeGen/CGObjCGNU.cpp, you'll see this line:

    // Prevent the @ from being interpreted as a symbol version.
    std::replace(TypeEncoding.begin(), TypeEncoding.end(),
      '@', '\1');

Underneath it, can you add this:

    std::replace(TypeEncoding.begin(), TypeEncoding.end(),
      '=', '\2');

Let me know if that fixes things.  If so, it's an ABI break on Windows, 
so it probably needs to be guarded on whether the symbol is dllexported 
and may need an explicit opt-in flag.

Alternatively, it may be an lld bug - if you use link.exe instead of 
lld, does it work?  Most of my Windows testing was done with link.exe 
(with incremental linking disabled).

David