Re: Building GNUstep for Windows using Clang

[Frederik Seiffert]

Hi David,

> Am 21.01.2021 um 15:00 schrieb David Chisnall :
> 
> It looks as if you are missing the dllimport attribute on the classes that 
> you're referencing from another DLL.

Thanks so much, that was indeed it! My little DLL test setup is working now. I 
thought I had tried that before, but apparently not (correctly). This also 
removes the need for a module definition file. I’ll annotate all the classes in 
GNUstep with something like "GS_EXPORT_CLASS".

I did a first build of the GNUstep Base DLL with a couple classes annotated 
like this, but just got various crashes trying to use it in a test program so 
far. I’ll dig into those further next week.

Meanwhile on the MinGW side I’m also still working on creating steps for you to 
build Clang with the MinGW patches and will let you know when I have those 
ready.

Thanks again and have a good weekend.

Frederik

Re: Building GNUstep for Windows using Clang

[David Chisnall]

Hi,


On 20/01/2021 20:30, Frederik Seiffert wrote:

There’s one more issue though: both [Test class] and [Test new] (with "Test" 
being defined in the DLL) only return null pointers in my testing. However subclassing 
the Test root class locally works fine and allows instantiating the subclass, as does a 
locally defined root class (same implementation as Test).

The following code (with "Sub" being a subclass of "Test"):

printf("%p %p\n", [Test class], [Test new]);
printf("%p %p\n", [Sub class], [Sub new]);

Prints:

 
7FF73EDB0080 0291D99247A8


Any idea? All other things I tried so far seemed to be working fine, though I’m 
sure this won’t be the last of my questions...


I think I misrememberd some details of the Windows ABI.  I wrote a 
little test compilation unit to look at it:


```obj-c
__attribute__((dllimport))
@interface Test
+ (id)new;
@end

@interface Sub : Test @end

@implementation Sub
+ (id)new
{
return (void*)1;
}
@end

int main(void)
{
[Test new];
[Sub new];
}
```

And compiled it with:

clang11  -S -fobjc-runtime=gnustep-2.0 -target x86_64-pc-windows-msvc 
-O1 -o - msg.m  -emit-llvm


This generates a global like this:

```llvm
@"$_OBJC_CLASS_Test" = external dllimport global i8*
```

This is a dllimport'd global, so one that can be referenced in the 
instruction stream and will have relocations applied.  It can't be 
referenced in a global and so there's an `.objc_early_init` function 
generated that initialises the isa pointer of the `Sub` class.


The message sends both directly load from the `_REF_` class pointer, 
which is declared like this:


```llvm
@"$_OBJC_REF_CLASS_Test" = external dllimport local_unnamed_addr global i8*
```

So this has a canonical home in the DLL that owns the class and every 
other message send must indirect via that.  Without the dllimport 
qualifier, clang generates:


```llvm
@"$_OBJC_CLASS_Test" = external global i8*
@"$_OBJC_REF_CLASS_Test" = external local_unnamed_addr global i8*
```

These are both local to the DLL or EXE that contains them and won't be 
correctly initialised.


It looks as if you are missing the dllimport attribute on the classes 
that you're referencing from another DLL.


In WinObjC, all of the classes are decorated with a macro that does the 
normal Windows dance of expanding to dllimport normally and dllexport 
when you are building the DLL that they come from.  These are missing 
from GNUstep, I'm not sure if you added them in your branch.


David

Re: Building GNUstep for Windows using Clang

[Frederik Seiffert]

Hi David,

> Am 20.01.2021 um 18:15 schrieb David Chisnall :
> 
> For reference, the $_OBJC_CLASS symbols are meant to be exported from a DLL, 
> they are the canonical pointers to the classes.  The $_OBJC_REF_CLASS 
> pointers are private to a library and are the pointer that code should use 
> for references to a given class.  These are initialised to the corresponding 
> $_OBJC_CLASS variables and the runtime can update them to something different 
> if we change the structure of the class structure in a future ABI.

Thanks for the clarification, that’s helpful. I tried defining the symbols as 
"constant" in the module definition file, and that somehow fixed the linker 
error:

EXPORTS
$_OBJC_CLASS_Test CONSTANT
$_OBJC_REF_CLASS_Test CONSTANT

This was totally by chance, but if I understand it correctly this means an 
undecorated version (without "_imp_" prefix) is emitted to the import library:
https://docs.microsoft.com/en-us/cpp/build/importing-using-def-files?view=msvc-160


There’s one more issue though: both [Test class] and [Test new] (with "Test" 
being defined in the DLL) only return null pointers in my testing. However 
subclassing the Test root class locally works fine and allows instantiating the 
subclass, as does a locally defined root class (same implementation as Test).

The following code (with "Sub" being a subclass of "Test"):

printf("%p %p\n", [Test class], [Test new]);
printf("%p %p\n", [Sub class], [Sub new]);

Prints:

 
7FF73EDB0080 0291D99247A8


Any idea? All other things I tried so far seemed to be working fine, though I’m 
sure this won’t be the last of my questions...

Frederik

Re: Building GNUstep for Windows using Clang

[David Chisnall]

On 20/01/2021 15:54, Frederik Seiffert wrote:
I confirmed with dumpbin /exports that the .lib and DLL both contain 
these $_OBJC_REF_CLASS_ symbols, so I really don’t understand why it’s 
not found.


For reference, the $_OBJC_CLASS symbols are meant to be exported from a 
DLL, they are the canonical pointers to the classes.  The 
$_OBJC_REF_CLASS pointers are private to a library and are the pointer 
that code should use for references to a given class.  These are 
initialised to the corresponding $_OBJC_CLASS variables and the runtime 
can update them to something different if we change the structure of the 
class structure in a future ABI.


I don't know if anything in your build is confusing that?

David

Re: Building GNUstep for Windows using Clang

[Frederik Seiffert]

So it seems that we need to generate a module definition (.def) file in order 
to have all the ObjC class symbols exported in the DLL. This is also what 
WinObjC is doing, I’ll try to come up with a script to generate this file from 
the object file symbols.
https://github.com/microsoft/WinObjC/blob/develop/build/Foundation/dll/Foundation.def
 



However after manually creating a .def file with a few relevant symbols I still 
get the following linker error, which happens for any referenced Foundation 
class (NSArray is just an example):

> lld-link: error: undefined symbol: $_OBJC_REF_CLASS_NSArray
> >>> referenced by test.m:16
> >>>   C:\msys64\tmp\test-b84674.o:(WinMain)


I confirmed with dumpbin /exports that the .lib and DLL both contain these 
$_OBJC_REF_CLASS_ symbols, so I really don’t understand why it’s not found.


I’ve reproduced the issue from scratch using only libobjc2 and have written 
down the steps to reproduce here:
https://github.com/gnustep/libobjc2/issues/191 


Hopefully I’m just missing some flag somewhere when creating the DLL. I’d 
appreciate any thoughts.


Thanks!
Frederik



> Am 19.01.2021 um 20:50 schrieb Frederik Seiffert :
> 
> Hi David,
> 
>> Am 19.01.2021 um 18:40 schrieb David Chisnall > >:
>> 
>> 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 
>  Additions/obj/subproject.o win32/obj/subproject.o 
> -lffi -lWs2_32 -lpthread -ladvapi32 -luser32 -lshell32 -lnetapi32 -lobjc 
> 
> Thanks!
> 
> Frederik
> 

Re: Building GNUstep for Windows using Clang

[Frederik Seiffert]

Hi David,

> Am 19.01.2021 um 18:40 schrieb David Chisnall :
> 
> 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 
 Additions/obj/subproject.o win32/obj/subproject.o 
-lffi -lWs2_32 -lpthread -ladvapi32 -luser32 -lshell32 -lnetapi32 -lobjc 

Thanks!

Frederik

Re: Building GNUstep for Windows using Clang

[David Chisnall]

Hi,

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.


David

On 19/01/2021 14:53, Frederik Seiffert wrote:

Hi all,

Another update on the Clang MSVC ABI support front (which I’m trying to get to 
work in addition to MinGW + Clang)...

I’ve been making some good progress and was able to build Base as a DLL with 
this setup. The necessary build system changes are on the following branches 
(work in progress), which I will clean up and submit as PRs when this is 
working:
https://github.com/gnustep/tools-make/tree/clang-msvc-support
https://github.com/gnustep/libs-base/tree/clang-msvc-support


However it seems that the generated gnustep-base.lib does not contain symbols 
for the ObjC classes. I’m getting linker errors for each ObjC class I am 
referencing in a test program:


lld-link: error: undefined symbol: $_OBJC_REF_CLASS_NSArray

referenced by C:\Dev\tools-android\test.m:16
   C:\msys64\tmp\test-aef6cd.o:(WinMain)


lld-link: error: undefined symbol: __declspec(dllimport) 
$_OBJC_CLASS_NSConstantString

referenced by C:\msys64\tmp\test-aef6cd.o:(.objc_early_init)


Is there some flag I need to pass to lld-link to ensure these are exported? I 
currently have -dll and -export-all-symbols. I also tried adding 
__declspec(dllexport) to the @interface declaration of these classes to no 
avail.


Regarding the previous issue:


However, it fails checking for objc_sync_enter with the following linker errors 
– any ideas what these could be about?


I am guessing these somehow happen because referencing ObjC built-ins in a C 
file doesn’t work on Windows. I’m planning to skip these config checks when 
using this setup.


Thanks,
Frederik



Am 12.01.2021 um 21:47 schrieb Frederik Seiffert :

Hi all,

As a second option I’ve been working on trying to build using the MSVC ABI 
(i.e. without MinGW).

Using the latest Clang 11 from the LLVM website and Pthreads-win32, plus 
removing -lm from target.make, I was able to get quite a bit further running 
Base configure.

However, it fails checking for objc_sync_enter with the following linker errors 
– any ideas what these could be about?


configure:8038: checking for objc_sync_enter
configure:8038: /C/LLVM/bin/clang -o conftest.exe -g  -I/c/GNUstep/MSVC/x64/include 
-I/c/GNUstep/MSVC/x64/include -I/c/GNUstep/MSVC/x64/include 
-I/c/GNUstep/MSVC/x64/include  -x objective-c -fuse-ld=lld -L/c/GNUstep/MSVC/x64/lib 
-L/c/GNUstep/MSVC/x64/lib -L/c/GNUstep/MSVC/x64/lib -L/c/GNUstep/MSVC/x64/lib 
conftest.c  -lpthread -fuse-ld=lld -pthread -fexceptions -fobjc-runtime=gnustep-2.0 
-fblocks -L/home/Frederik -LSeiffert/GNUstep/Library/Libraries 
-L/c/GNUstep/MSVC/x64/lib -lobjc >&5
conftest.c:119:6: warning: incompatible redeclaration of library function 
'objc_sync_enter' [-Wincompatible-library-redeclaration]
char objc_sync_enter ();
 ^
conftest.c:119:6: note: 'objc_sync_enter' is a builtin with type 'int (id)'
1 warning generated.
lld-link: error: relocation against symbol in discarded section: 
__start_.objcrt$SEL

referenced by C:\tmp\conftest-78a937.o:(.objc_init)


lld-link: error: relocation against symbol in discarded section: 
__stop.objcrt$SEL

referenced by C:\tmp\conftest-78a937.o:(.objc_init)


lld-link: error: relocation against symbol in discarded section: 
__start_.objcrt$CLS

referenced by C:\tmp\conftest-78a937.o:(.objc_init)


lld-link: error: relocation against symbol in discarded section: 
__stop.objcrt$CLS

referenced by C:\tmp\conftest-78a937.o:(.objc_init)


lld-link: error: relocation against symbol in discarded section: 
__start_.objcrt$CLR

referenced by C:\tmp\conftest-78a937.o:(.objc_init)


lld-link: error: relocation against symbol in discarded section: 
__stop.objcrt$CLR

referenced by C:\tmp\conftest-78a937.o:(.objc_init)


lld-link: error: relocation against symbol in discarded section: 
__start_.objcrt$CAT

referenced by C:\tmp\conftest-78a937.o:(.objc_init)


lld-link: error: relocation against symbol in discarded section: 
__stop.objcrt$CAT

referenced by C:\tmp\conftest-78a937.o:(.objc_init)


lld-link: error: relocation against symbol in discarded section: 
__start_.objcrt$PCL

referenced by C:\tmp\conftest-78a937.o:(.objc_init)


lld-link: error: relocation against symbol in discarded section: 
__stop.objcrt$PCL

referenced by C:\tmp\conftest-78a937.o:(.objc_init)


lld-link: error: relocation against symbol in discarded section: 
__start_.objcrt$PCR

referenced by C:\tmp\conftest-78a937.o:(.objc_init)


lld-link: error: relocation against symbol in discarded section: 
__stop.objcrt$PCR

referenced by C:\tmp\conftest-78a937.o:(.objc_init)


lld-link: error: relocation against symbol in discarded section: 
__start_.objcrt$CAL

Re: Building GNUstep for Windows using Clang

[Frederik Seiffert]

Hi all,

Another update on the Clang MSVC ABI support front (which I’m trying to get to 
work in addition to MinGW + Clang)...

I’ve been making some good progress and was able to build Base as a DLL with 
this setup. The necessary build system changes are on the following branches 
(work in progress), which I will clean up and submit as PRs when this is 
working:
https://github.com/gnustep/tools-make/tree/clang-msvc-support
https://github.com/gnustep/libs-base/tree/clang-msvc-support


However it seems that the generated gnustep-base.lib does not contain symbols 
for the ObjC classes. I’m getting linker errors for each ObjC class I am 
referencing in a test program:

> lld-link: error: undefined symbol: $_OBJC_REF_CLASS_NSArray
> >>> referenced by C:\Dev\tools-android\test.m:16
> >>>   C:\msys64\tmp\test-aef6cd.o:(WinMain)
> 
> lld-link: error: undefined symbol: __declspec(dllimport) 
> $_OBJC_CLASS_NSConstantString
> >>> referenced by C:\msys64\tmp\test-aef6cd.o:(.objc_early_init)

Is there some flag I need to pass to lld-link to ensure these are exported? I 
currently have -dll and -export-all-symbols. I also tried adding 
__declspec(dllexport) to the @interface declaration of these classes to no 
avail.


Regarding the previous issue:

> However, it fails checking for objc_sync_enter with the following linker 
> errors – any ideas what these could be about?

I am guessing these somehow happen because referencing ObjC built-ins in a C 
file doesn’t work on Windows. I’m planning to skip these config checks when 
using this setup.


Thanks,
Frederik


> Am 12.01.2021 um 21:47 schrieb Frederik Seiffert :
> 
> Hi all,
> 
> As a second option I’ve been working on trying to build using the MSVC ABI 
> (i.e. without MinGW).
> 
> Using the latest Clang 11 from the LLVM website and Pthreads-win32, plus 
> removing -lm from target.make, I was able to get quite a bit further running 
> Base configure.
> 
> However, it fails checking for objc_sync_enter with the following linker 
> errors – any ideas what these could be about?
> 
>> configure:8038: checking for objc_sync_enter
>> configure:8038: /C/LLVM/bin/clang -o conftest.exe -g  
>> -I/c/GNUstep/MSVC/x64/include -I/c/GNUstep/MSVC/x64/include 
>> -I/c/GNUstep/MSVC/x64/include -I/c/GNUstep/MSVC/x64/include  -x objective-c 
>> -fuse-ld=lld -L/c/GNUstep/MSVC/x64/lib -L/c/GNUstep/MSVC/x64/lib 
>> -L/c/GNUstep/MSVC/x64/lib -L/c/GNUstep/MSVC/x64/lib conftest.c  -lpthread 
>> -fuse-ld=lld -pthread -fexceptions -fobjc-runtime=gnustep-2.0 -fblocks 
>> -L/home/Frederik -LSeiffert/GNUstep/Library/Libraries 
>> -L/c/GNUstep/MSVC/x64/lib -lobjc >&5
>> conftest.c:119:6: warning: incompatible redeclaration of library function 
>> 'objc_sync_enter' [-Wincompatible-library-redeclaration]
>> char objc_sync_enter ();
>> ^
>> conftest.c:119:6: note: 'objc_sync_enter' is a builtin with type 'int (id)'
>> 1 warning generated.
>> lld-link: error: relocation against symbol in discarded section: 
>> __start_.objcrt$SEL
> referenced by C:\tmp\conftest-78a937.o:(.objc_init)
>> 
>> lld-link: error: relocation against symbol in discarded section: 
>> __stop.objcrt$SEL
> referenced by C:\tmp\conftest-78a937.o:(.objc_init)
>> 
>> lld-link: error: relocation against symbol in discarded section: 
>> __start_.objcrt$CLS
> referenced by C:\tmp\conftest-78a937.o:(.objc_init)
>> 
>> lld-link: error: relocation against symbol in discarded section: 
>> __stop.objcrt$CLS
> referenced by C:\tmp\conftest-78a937.o:(.objc_init)
>> 
>> lld-link: error: relocation against symbol in discarded section: 
>> __start_.objcrt$CLR
> referenced by C:\tmp\conftest-78a937.o:(.objc_init)
>> 
>> lld-link: error: relocation against symbol in discarded section: 
>> __stop.objcrt$CLR
> referenced by C:\tmp\conftest-78a937.o:(.objc_init)
>> 
>> lld-link: error: relocation against symbol in discarded section: 
>> __start_.objcrt$CAT
> referenced by C:\tmp\conftest-78a937.o:(.objc_init)
>> 
>> lld-link: error: relocation against symbol in discarded section: 
>> __stop.objcrt$CAT
> referenced by C:\tmp\conftest-78a937.o:(.objc_init)
>> 
>> lld-link: error: relocation against symbol in discarded section: 
>> __start_.objcrt$PCL
> referenced by C:\tmp\conftest-78a937.o:(.objc_init)
>> 
>> lld-link: error: relocation against symbol in discarded section: 
>> __stop.objcrt$PCL
> referenced by C:\tmp\conftest-78a937.o:(.objc_init)
>> 
>> lld-link: error: relocation against symbol in discarded section: 
>> __start_.objcrt$PCR
> referenced by C:\tmp\conftest-78a937.o:(.objc_init)
>> 
>> lld-link: error: relocation against symbol in discarded section: 
>> __stop.objcrt$PCR
> referenced by C:\tmp\conftest-78a937.o:(.objc_init)
>> 
>> lld-link: error: relocation against symbol in discarded section: 
>> __start_.objcrt$CAL
> referenced by C:\tmp\conftest-78a937.o:(.objc_init)
>> 
>> lld-link: error: relocation against symbol in discarded section: 
>> 

Re: Building GNUstep for Windows using Clang

[Frederik Seiffert]

Hi all,

As a second option I’ve been working on trying to build using the MSVC ABI 
(i.e. without MinGW).

Using the latest Clang 11 from the LLVM website and Pthreads-win32, plus 
removing -lm from target.make, I was able to get quite a bit further running 
Base configure.

However, it fails checking for objc_sync_enter with the following linker errors 
– any ideas what these could be about?

> configure:8038: checking for objc_sync_enter
> configure:8038: /C/LLVM/bin/clang -o conftest.exe -g  
> -I/c/GNUstep/MSVC/x64/include -I/c/GNUstep/MSVC/x64/include 
> -I/c/GNUstep/MSVC/x64/include -I/c/GNUstep/MSVC/x64/include  -x objective-c 
> -fuse-ld=lld -L/c/GNUstep/MSVC/x64/lib -L/c/GNUstep/MSVC/x64/lib 
> -L/c/GNUstep/MSVC/x64/lib -L/c/GNUstep/MSVC/x64/lib conftest.c  -lpthread 
> -fuse-ld=lld -pthread -fexceptions -fobjc-runtime=gnustep-2.0 -fblocks 
> -L/home/Frederik -LSeiffert/GNUstep/Library/Libraries 
> -L/c/GNUstep/MSVC/x64/lib -lobjc >&5
> conftest.c:119:6: warning: incompatible redeclaration of library function 
> 'objc_sync_enter' [-Wincompatible-library-redeclaration]
> char objc_sync_enter ();
>  ^
> conftest.c:119:6: note: 'objc_sync_enter' is a builtin with type 'int (id)'
> 1 warning generated.
> lld-link: error: relocation against symbol in discarded section: 
> __start_.objcrt$SEL
> >>> referenced by C:\tmp\conftest-78a937.o:(.objc_init)
> 
> lld-link: error: relocation against symbol in discarded section: 
> __stop.objcrt$SEL
> >>> referenced by C:\tmp\conftest-78a937.o:(.objc_init)
> 
> lld-link: error: relocation against symbol in discarded section: 
> __start_.objcrt$CLS
> >>> referenced by C:\tmp\conftest-78a937.o:(.objc_init)
> 
> lld-link: error: relocation against symbol in discarded section: 
> __stop.objcrt$CLS
> >>> referenced by C:\tmp\conftest-78a937.o:(.objc_init)
> 
> lld-link: error: relocation against symbol in discarded section: 
> __start_.objcrt$CLR
> >>> referenced by C:\tmp\conftest-78a937.o:(.objc_init)
> 
> lld-link: error: relocation against symbol in discarded section: 
> __stop.objcrt$CLR
> >>> referenced by C:\tmp\conftest-78a937.o:(.objc_init)
> 
> lld-link: error: relocation against symbol in discarded section: 
> __start_.objcrt$CAT
> >>> referenced by C:\tmp\conftest-78a937.o:(.objc_init)
> 
> lld-link: error: relocation against symbol in discarded section: 
> __stop.objcrt$CAT
> >>> referenced by C:\tmp\conftest-78a937.o:(.objc_init)
> 
> lld-link: error: relocation against symbol in discarded section: 
> __start_.objcrt$PCL
> >>> referenced by C:\tmp\conftest-78a937.o:(.objc_init)
> 
> lld-link: error: relocation against symbol in discarded section: 
> __stop.objcrt$PCL
> >>> referenced by C:\tmp\conftest-78a937.o:(.objc_init)
> 
> lld-link: error: relocation against symbol in discarded section: 
> __start_.objcrt$PCR
> >>> referenced by C:\tmp\conftest-78a937.o:(.objc_init)
> 
> lld-link: error: relocation against symbol in discarded section: 
> __stop.objcrt$PCR
> >>> referenced by C:\tmp\conftest-78a937.o:(.objc_init)
> 
> lld-link: error: relocation against symbol in discarded section: 
> __start_.objcrt$CAL
> >>> referenced by C:\tmp\conftest-78a937.o:(.objc_init)
> 
> lld-link: error: relocation against symbol in discarded section: 
> __stop.objcrt$CAL
> >>> referenced by C:\tmp\conftest-78a937.o:(.objc_init)
> 
> lld-link: error: relocation against symbol in discarded section: 
> __start_.objcrt$STR
> >>> referenced by C:\tmp\conftest-78a937.o:(.objc_init)
> 
> lld-link: error: relocation against symbol in discarded section: 
> __stop.objcrt$STR
> >>> referenced by C:\tmp\conftest-78a937.o:(.objc_init)
> PLEASE submit a bug report to https://bugs.llvm.org/ and include the crash 
> backtrace.
> 0.Program arguments: C:\LLVM\bin\lld-link -out:conftest.exe 
> -defaultlib:libcmt -libpath:C:\Program Files (x86)\Microsoft Visual 
> Studio\2019\Professional\VC\Tools\MSVC\14.28.29333\lib\x64 
> -libpath:C:\Program Files (x86)\Microsoft Visual 
> Studio\2019\Professional\VC\Tools\MSVC\14.28.29333\atlmfc\lib\x64 
> -libpath:C:\Program Files (x86)\Windows Kits\10\Lib\10.0.18362.0\ucrt\x64 
> -libpath:C:\Program Files (x86)\Windows Kits\10\Lib\10.0.18362.0\um\x64 
> -libpath:C:\LLVM\lib\clang\11.0.0\lib\windows 
> -libpath:C:/GNUstep/MSVC/x64/lib -libpath:C:/GNUstep/MSVC/x64/lib 
> -libpath:C:/GNUstep/MSVC/x64/lib -libpath:C:/GNUstep/MSVC/x64/lib 
> -libpath:C:/msys64/home/Frederik -libpath:Seiffert/GNUstep/Library/Libraries 
> -libpath:C:/GNUstep/MSVC/x64/lib -nologo -debug C:\tmp\conftest-76158a.o 
> pthread.lib objc.lib 


> configure:8038: result: no
> configure:8052: error: The objc runtime library does not appear to have 
> synchronisation support.  Try re-configuring gnustep-make with a CPPFLAGS 
> variable containing a -L point to specify the directory containing the 
> correct libobjc, or using the --with-objc-lib-flag=... option.


Thanks,
Frederik

Re: Building GNUstep for Windows using Clang

[Frederik Seiffert]

Hi all,

I’ve made a bit of progress getting libobjc2 working under MinGW, including 
adding it to the CI test matrix (currently using stock Clang). Here’s the PR in 
case anyone wants to follow along on GitHub:
https://github.com/gnustep/libobjc2/pull/190

I tried building it with a patched Clang to use SEH, but unfortunately this 
doesn’t fully resolve the issues as outlined in the PR (I probably didn’t fully 
understand what exactly needs to be patched). At this point I’d very much 
appreciate your input David.

Once we have a functional Clang patch I can upload the packages (not to the 
repo but externally) and we can use them in CI until there is a new LLVM 
release.

Thanks!
Frederik

Re: Building GNUstep for Windows using Clang

[Riccardo Mottola]

Hi,

On 12/2/20 5:07 PM, Gregory Casamento wrote:
Just a suggestion.  Could you commit the binary resulting from the 
build?  While David might disagree, this is a very heavyweight and 
difficult build process.  I would prefer to spare others from having 
to go through it.  If someone else doesn't commit it, I will go 
through the process and do it myself.




please don't commit it. Also, "official binaries" should be built with 
releases and blessed etc etc, we aren't yet prepared that.


We could however put it in the releases of the repository.


-R

Re: Building GNUstep for Windows using Clang

[Ivan Vučica]

I am not in favor of committing binaries into otherwise highly compressible
repositories, those containing primarily source code.

Clone operations become heavyweight and eliminating the binary from history
is, like any other file, difficult.

If we start to commit binaries, can it be in separate optional
repositories, please?

sent from phone

On Wed 2 Dec 2020, 16:08 Gregory Casamento, 
wrote:

> Just a suggestion.  Could you commit the binary resulting from the build?
> While David might disagree, this is a very heavyweight and difficult build
> process.  I would prefer to spare others from having to go through it.  If
> someone else doesn't commit it, I will go through the process and do it
> myself.
>
> GC
>
>
> On Wed, Dec 2, 2020 at 7:24 AM Frederik Seiffert 
> wrote:
>
>>
>> Am 02.12.2020 um 10:50 schrieb David Chisnall > >:
>>
>> You should be able to just do a Windows build with the VS command prompt
>> and CMake.  I normally build clang with CMake + Ninja + either Visual
>> Studio or an existing LLVM install on Windows.  There are no other
>> dependencies.
>>
>>
>> Thanks, it’s building now, fans spinning. :)
>>
>> Frederik
>>
>>
>
> --
> Gregory Casamento
> GNUstep Lead Developer / OLC, Principal Consultant
> http://www.gnustep.org - http://heronsperch.blogspot.com
> https://www.patreon.com/bePatron?u=352392 - Become a Patron
> https://gf.me/u/x8m3sx - My GNUstep GoFundMe
> https://teespring.com/stores/gnustep - Store
>

Re: Building GNUstep for Windows using Clang

[Frederik Seiffert]

Hi David,

> Am 29.12.2020 um 15:57 schrieb David Chisnall :
> 
> Hi all,
> 
> Sorry for the delayed response, I’ve now had time to do a little bit of 
> digging to understand what’s needed here.

Thank you very much, this is super helpful.

>> 1. Support building GNUstep with MSVC
> 
> To clarify:
> 
> This is proposing building GNUstep with the MSVC C++ ABI.  This is now well 
> supported by clang (Chrome uses it on Windows, for example).  I had assumed 
> that MinGW used it with the clang toolchains but apparently it doesn’t.  

Yes exactly, thank you for the clarification.

>>  - Dependencies: all dependencies would have to be built using MSVC as well. 
>> I did a quick search and this seems to be possible e.g. for libxml2, 
>> libxslt, libffi, and ICU, although some of the build instructions to do so 
>> seem pretty involved (esp. for ICU). In contrast to MinGW where these 
>> dependencies can simply be installed via Pacman, I don’t think there are 
>> pre-built packages of these dependencies built with MSVC, so this adds a 
>> significant hurdle to building GNUstep as a whole.
> 
> MSVC or Clang with the MSVC ABI.  If they are available as NuGet packages, 
> then this is easy (ICU is, for example: 
> https://www.nuget.org/packages/icu4c.v140/ 
> ), just install it with NuGet and 
> point the GNUstep build system at it.

That’s great, thanks for the pointer! I looks like NuGet actually has all of 
the dependencies listed above. Some of them are pretty old (e.g. the newest 
libxml2 is from 2013), but I guess that may be ok.

>>  - Build system / Autoconf: I don’t think we’d be able to use Autoconf and 
>> Make, so we’d have to look into supporting e.g. CMake, which is probably a 
>> significant undertaking.
> 
> I’m not 100% sure that this is the case.  Clang can target the MSVC ABI when 
> invoked with either the gcc- or cl.exe-compatible driver, so you can still 
> use clang.exe (not clang-cl.exe) to drive the build.  I have no idea how well 
> autoconf in bash on Windows without MinGW though.

Yeah good point. I did manage to build Make for the MSVC ABI using the 
pre-built Clang release from the LLVM website, which defaults to the 
x86_64-pc-windows-msvc target. Building Base failed expectedly due to missing 
pthreads, but maybe this is still a good starting point for option 1.

>>  - Windows toolchain support in GNUstep sources: no idea what would be 
>> needed here, but I assume that some code relying on MinGW toolchain 
>> headers/libraries would need to be updated to use Windows APIs.
> 
> This may be non-trivial, though the Min in MinGW may help here: it largely 
> just provides its own headers for Windows DLLs.  I think we’re using Windows 
> APIs for a bunch of things already.  I believe that we use a pthreads 
> compatibility layer on Windows, so these things would need to be modified to 
> use the native Windows calls.  If no one cares about Windows XP anymore, we 
> could probably get some nice improvements by using SlimRW locks for NSLock.

Yeah replacing pthreads would probably be a bit of work. I just found 
pthreads-win32 (http://www.sourceware.org/pthreads-win32/, also available via 
NuGet), which may be a good shortcut at least for a proof of concept and to see 
what else is missing.


>> 2. Support MinGW-style exception handling in libobjc2
>> 
>>  I don’t have any idea how involved this would be to support in libobjc2, 
>> but using GNUstep in a MinGW environment is how it worked in the past on 
>> Windows (with GCC), and so this would probably be what most users would 
>> expect to work with Clang as well. (As a bonus it would be nice if libobjc2 
>> could support being built from a MinGW shell, so that everything can be 
>> built in the same environment.)
> 
> There are two bits here, supporting it in the runtime and supporting it in 
> the compiler.  I believe that both are actually fairly easy.  It appears that 
> MinGW comes with an adaptor that translates from SEH-style exceptions to 
> MinGW-style exceptions, so we just need to build the Itanium version and a 
> tiny wrapper function that calls _GCC_specific_handler and passes it the 
> GNUstep runtime’s personality function.
> 
> The clang changes are probably of a similar size.

Thanks, I’ll try to take a stab at the required changes you sent me, which at 
least on the surface seem pretty straightforward. I’ll keep you posted.


> I suspect the hardest part of Option 2 will also be the build system, because 
> the runtime will need to depend on MinGW and I’ve never built anything with 
> MinGW before...

After installing MSYS2 and the necessary toolchain bits using Pacman (which 
should be mingw-w64-$(Arch)-cmake, mingw-w64-$(Arch)-clang, and 
mingw-w64-$(Arch)-lld), I’m hoping it will just require replacing some Win32 
checks in CMakeLists with MSVC or checking explicitly for "MINGW", but we’ll 
see...


Thanks again,
Frederik

Re: Building GNUstep for Windows using Clang

[David Chisnall]

Hi all,

Sorry for the delayed response, I’ve now had time to do a little bit of digging 
to understand what’s needed here.

> On 22 Dec 2020, at 11:39, Frederik Seiffert  wrote:
> 
> Hi David and all,
> 
>> Am 02.12.2020 um 20:20 schrieb David Chisnall :
>> 
>> I am not sure if there is a good way of fixing this other than to use a MSVC 
>> target triple.  C++ EH interop almost certainly won't work if MinGW is 
>> targeting the Itanium ABI for C++ and I really don't want to support the 
>> horrible 'let's try to layer Itanium-style unwinding on top of SEH, what's 
>> the worst that can happen?' approach that MinGW uses.
> 
> I’ve been thinking about this some more, and it seems like there are two 
> (non-exclusive) ways forward with this:
> 
> 
> 1. Support building GNUstep with MSVC

To clarify:

This is proposing building GNUstep with the MSVC C++ ABI.  This is now well 
supported by clang (Chrome uses it on Windows, for example).  I had assumed 
that MinGW used it with the clang toolchains but apparently it doesn’t.  

>   *I think* this would mean that we have to enable building GNUstep with a 
> native Windows toolchain, i.e. without MinGW (unless there‘s a way to use 
> MSVC in a MinGW environment, but even then the dependencies would also need 
> to be built with MSVC). This poses a couple of questions / challenges:

Exactly, though that toolchain could be clang + lld, rather than any part of 
MSVC.

> 
>   - Dependencies: all dependencies would have to be built using MSVC as well. 
> I did a quick search and this seems to be possible e.g. for libxml2, libxslt, 
> libffi, and ICU, although some of the build instructions to do so seem pretty 
> involved (esp. for ICU). In contrast to MinGW where these dependencies can 
> simply be installed via Pacman, I don’t think there are pre-built packages of 
> these dependencies built with MSVC, so this adds a significant hurdle to 
> building GNUstep as a whole.

MSVC or Clang with the MSVC ABI.  If they are available as NuGet packages, then 
this is easy (ICU is, for example: https://www.nuget.org/packages/icu4c.v140/), 
just install it with NuGet and point the GNUstep build system at it.

>   - Build system / Autoconf: I don’t think we’d be able to use Autoconf and 
> Make, so we’d have to look into supporting e.g. CMake, which is probably a 
> significant undertaking.

I’m not 100% sure that this is the case.  Clang can target the MSVC ABI when 
invoked with either the gcc- or cl.exe-compatible driver, so you can still use 
clang.exe (not clang-cl.exe) to drive the build.  I have no idea how well 
autoconf in bash on Windows without MinGW though.

>   - Windows toolchain support in GNUstep sources: no idea what would be 
> needed here, but I assume that some code relying on MinGW toolchain 
> headers/libraries would need to be updated to use Windows APIs.

This may be non-trivial, though the Min in MinGW may help here: it largely just 
provides its own headers for Windows DLLs.  I think we’re using Windows APIs 
for a bunch of things already.  I believe that we use a pthreads compatibility 
layer on Windows, so these things would need to be modified to use the native 
Windows calls.  If no one cares about Windows XP anymore, we could probably get 
some nice improvements by using SlimRW locks for NSLock.


> 2. Support MinGW-style exception handling in libobjc2
> 
>   I don’t have any idea how involved this would be to support in libobjc2, 
> but using GNUstep in a MinGW environment is how it worked in the past on 
> Windows (with GCC), and so this would probably be what most users would 
> expect to work with Clang as well. (As a bonus it would be nice if libobjc2 
> could support being built from a MinGW shell, so that everything can be built 
> in the same environment.)

There are two bits here, supporting it in the runtime and supporting it in the 
compiler.  I believe that both are actually fairly easy.  It appears that MinGW 
comes with an adaptor that translates from SEH-style exceptions to MinGW-style 
exceptions, so we just need to build the Itanium version and a tiny wrapper 
function that calls _GCC_specific_handler and passes it the GNUstep runtime’s 
personality function.

The clang changes are probably of a similar size.

> I think both options are worth exploring and I’d appreciate anyone’s thoughts 
> on the above. Ultimately it seems that even if we get option 1 to work, 
> option 2 would be much more straightforward to users given the pre-built 
> dependencies provided by MSYS2 packages.

My guess is that Option 2 is about two hours of writing the code and then a day 
or two of figuring out why it doesn’t work.  Option 1 is probably not too much 
work for the majority of the code but is likely to be a huge amount of effort 
for the build system: the GNUstep build system really doesn’t like non-GNU 
environments.

I suspect the hardest part of Option 2 will also be the build system, because 
the runtime will need to depend on MinGW and 

Re: Building GNUstep for Windows using Clang

[Frederik Seiffert]

Hi David and all,

> Am 02.12.2020 um 20:20 schrieb David Chisnall :
> 
> I am not sure if there is a good way of fixing this other than to use a MSVC 
> target triple.  C++ EH interop almost certainly won't work if MinGW is 
> targeting the Itanium ABI for C++ and I really don't want to support the 
> horrible 'let's try to layer Itanium-style unwinding on top of SEH, what's 
> the worst that can happen?' approach that MinGW uses.

I’ve been thinking about this some more, and it seems like there are two 
(non-exclusive) ways forward with this:


1. Support building GNUstep with MSVC

  *I think* this would mean that we have to enable building GNUstep with a 
native Windows toolchain, i.e. without MinGW (unless there‘s a way to use MSVC 
in a MinGW environment, but even then the dependencies would also need to be 
built with MSVC). This poses a couple of questions / challenges:

  - Dependencies: all dependencies would have to be built using MSVC as well. I 
did a quick search and this seems to be possible e.g. for libxml2, libxslt, 
libffi, and ICU, although some of the build instructions to do so seem pretty 
involved (esp. for ICU). In contrast to MinGW where these dependencies can 
simply be installed via Pacman, I don’t think there are pre-built packages of 
these dependencies built with MSVC, so this adds a significant hurdle to 
building GNUstep as a whole.

  - Build system / Autoconf: I don’t think we’d be able to use Autoconf and 
Make, so we’d have to look into supporting e.g. CMake, which is probably a 
significant undertaking.

  - Windows toolchain support in GNUstep sources: no idea what would be needed 
here, but I assume that some code relying on MinGW toolchain headers/libraries 
would need to be updated to use Windows APIs.


2. Support MinGW-style exception handling in libobjc2

  I don’t have any idea how involved this would be to support in libobjc2, but 
using GNUstep in a MinGW environment is how it worked in the past on Windows 
(with GCC), and so this would probably be what most users would expect to work 
with Clang as well. (As a bonus it would be nice if libobjc2 could support 
being built from a MinGW shell, so that everything can be built in the same 
environment.)


I think both options are worth exploring and I’d appreciate anyone’s thoughts 
on the above. Ultimately it seems that even if we get option 1 to work, option 
2 would be much more straightforward to users given the pre-built dependencies 
provided by MSYS2 packages.

Frederik

Re: Building GNUstep for Windows using Clang

[Frederik Seiffert]

And here are the MinGW-w64 Clang packages built with both of David’s patches in 
case anyone wants to play around with it:

https://algoriddim-djay.s3.us-east-1.amazonaws.com/tmp/mingw-w64-i686-clang-11.0.0-4-any.pkg.tar.zst
 

https://algoriddim-djay.s3.us-east-1.amazonaws.com/tmp/mingw-w64-x86_64-clang-11.0.0-4-any.pkg.tar.zst
 


Install with `pacman -U `.

Frederik

Re: Building GNUstep for Windows using Clang

[Frederik Seiffert]

> Am 02.12.2020 um 20:20 schrieb David Chisnall :
> 
> It looks as if the code to check which personality function is outside the 
> runtime-specific code.  The attached diff should fix that.

FYI these are the linker errors after building Clang with this patch added also:

> lld-link: error: undefined symbol: __CxxFrameHandler3
> >>> referenced by obj/libgnustep-base.obj/GSHTTPAuthentication.m.o:(.xdata)
> >>> referenced by obj/libgnustep-base.obj/GSHTTPAuthentication.m.o:(.xdata)
> >>> referenced by 
> >>> obj/libgnustep-base.obj/GSHTTPAuthentication.m.o:($ip2state$_c_GSHTTPAuthentication__authenticationWithCredential_inProtectionSpace_)
> >>> referenced 258 more times
> 
> lld-link: error: undefined symbol: vtable for __cxxabiv1::__class_type_info
> >>> referenced by obj/libgnustep-base.obj/GSHTTPAuthentication.m.o:(typeinfo 
> >>> for NSObject)
> >>> referenced by obj/libgnustep-base.obj/GSTimSort.m.o
> >>> referenced by obj/libgnustep-base.obj/GSTLS.m.o
> 
> lld-link: error: undefined symbol: vtable for __cxxabiv1::__si_class_type_info
> >>> referenced by obj/libgnustep-base.obj/GSHTTPAuthentication.m.o:(typeinfo 
> >>> for NSException)
> >>> referenced by obj/libgnustep-base.obj/GSTimSort.m.o
> >>> referenced by obj/libgnustep-base.obj/GSTLS.m.o
> 
> lld-link: error: undefined symbol: vtable for __cxxabiv1::__pointer_type_info
> >>> referenced by obj/libgnustep-base.obj/GSHTTPAuthentication.m.o:(typeinfo 
> >>> for NSException*)
> >>> referenced by obj/libgnustep-base.obj/GSTimSort.m.o
> >>> referenced by obj/libgnustep-base.obj/GSTLS.m.o


For now I might try disabling native exceptions (which looks like will require 
some changes in Make as it assumes libobjc2 supports them) to keep moving 
towards a Clang build of GNUstep on Windows.

That being said, it would be great to get a better idea of what needs to be 
done to get exception handling working with MinGW (in Clang and/or libobjc2). 
We’d be happy to support or sponsor required work in any way we can.

In the meantime, if there’s anything else I can try so we can get a better 
picture just let me know. :)

Thanks!
Frederik

Re: Building GNUstep for Windows using Clang

[Frederik Seiffert]

> Am 02.12.2020 um 20:20 schrieb David Chisnall :
> 
> It looks as if the code to check which personality function is outside the 
> runtime-specific code.  The attached diff should fix that.

Thanks! I will try that.

> This looks as if clang is still trying to use the Itanium C++ ABI.  When the 
> Objective-C code is targeting windows, it now asks for RTTI from the CXXABI 
> class, but somehow your target triple is asking for the Itanium ABI, so we 
> emit Itanium ABI C++ RTTI things and they then fail to link because they 
> refer to things that exist only on Itanium ABI C++ runtimes.
> 
> I am not sure if there is a good way of fixing this other than to use a MSVC 
> target triple.  C++ EH interop almost certainly won't work if MinGW is 
> targeting the Itanium ABI for C++ and I really don't want to support the 
> horrible 'let's try to layer Itanium-style unwinding on top of SEH, what's 
> the worst that can happen?' approach that MinGW uses.

I just don’t know how to use the MSVC triple with the MinGW toolchain, as using 
the x86_64-pc-windows-msvc triple seems to somehow remove Clang’s ability to 
find MinGW headers like stdio.h or pthread.h. Our discussion on GitHub has some 
more details of what I tried in that direction:
https://github.com/gnustep/libobjc2/pull/186#issuecomment-735449495 


I don’t really understand the interplay between target triples and toolchains, 
but I wonder whether your suggestion works here given that GNUstep requires 
MinGW.

Frederik

Re: Building GNUstep for Windows using Clang

[David Chisnall]

On 02/12/2020 19:01, Frederik Seiffert wrote:


Am 01.12.2020 um 15:42 schrieb David Chisnall 
mailto:gnus...@theravensnest.org>>:


Please can you try the attached patch?


So the patch resolves the objc_begin_catch/objc_end_catch undefined 
symbols, but it doesn’t resolve __gnustep_objc_personality_v0 and adds 
some new linker errors ones:



lld-link: error: undefined symbol: __gnustep_objc_personality_v0
>>> referenced by 
obj/libgnustep-base.obj/GSHTTPAuthentication.m.o:(.xdata)
>>> referenced by 
obj/libgnustep-base.obj/GSHTTPAuthentication.m.o:(GCC_except_table2)
>>> referenced by 
obj/libgnustep-base.obj/GSHTTPAuthentication.m.o:(GCC_except_table4)

>>> referenced 121 more times


It looks as if the code to check which personality function is outside 
the runtime-specific code.  The attached diff should fix that.




lld-link: error: undefined symbol: vtable for 
__cxxabiv1::__class_type_info
>>> referenced by 
obj/libgnustep-base.obj/GSHTTPAuthentication.m.o:(typeinfo for NSObject)

>>> referenced by obj/libgnustep-base.obj/GSTimSort.m.o
>>> referenced by obj/libgnustep-base.obj/GSTLS.m.o

lld-link: error: undefined symbol: vtable for 
__cxxabiv1::__si_class_type_info
>>> referenced by 
obj/libgnustep-base.obj/GSHTTPAuthentication.m.o:(typeinfo for 
NSException)

>>> referenced by obj/libgnustep-base.obj/GSTimSort.m.o
>>> referenced by obj/libgnustep-base.obj/GSTLS.m.o

lld-link: error: undefined symbol: vtable for 
__cxxabiv1::__pointer_type_info
>>> referenced by 
obj/libgnustep-base.obj/GSHTTPAuthentication.m.o:(typeinfo for 
NSException*)

>>> referenced by obj/libgnustep-base.obj/GSTimSort.m.o
>>> referenced by obj/libgnustep-base.obj/GSTLS.m.o


This looks as if clang is still trying to use the Itanium C++ ABI.  When 
the Objective-C code is targeting windows, it now asks for RTTI from the 
CXXABI class, but somehow your target triple is asking for the Itanium 
ABI, so we emit Itanium ABI C++ RTTI things and they then fail to link 
because they refer to things that exist only on Itanium ABI C++ runtimes.


I am not sure if there is a good way of fixing this other than to use a 
MSVC target triple.  C++ EH interop almost certainly won't work if MinGW 
is targeting the Itanium ABI for C++ and I really don't want to support 
the horrible 'let's try to layer Itanium-style unwinding on top of SEH, 
what's the worst that can happen?' approach that MinGW uses.


David

index bdf70252b5ad..5957b5fff0d5 100644
--- a/clang/lib/CodeGen/CGException.cpp
+++ b/clang/lib/CodeGen/CGException.cpp
@@ -141,7 +141,9 @@ static const EHPersonality (const 
TargetInfo ,

   case ObjCRuntime::iOS:
   case ObjCRuntime::WatchOS:
 return EHPersonality::NeXT_ObjC;
-  case ObjCRuntime::GNUstep:
+  case ObjCRuntime::GNUstep:
+if (L.SEHExceptions)
+  return EHPersonality::MSVC_CxxFrameHandler3;
 if (L.ObjCRuntime.getVersion() >= VersionTuple(1, 7))
   return EHPersonality::GNUstep_ObjC;
 LLVM_FALLTHROUGH;
@@ -194,6 +196,8 @@ static const EHPersonality 
(const TargetInfo ,

 return getObjCPersonality(Target, L);

   case ObjCRuntime::GNUstep:
+if (L.SEHExceptions)
+  return EHPersonality::MSVC_CxxFrameHandler3;
 return EHPersonality::GNU_ObjCXX;

   // The GCC runtime's personality function inherently doesn't support

Re: Building GNUstep for Windows using Clang

[Frederik Seiffert]

> Am 01.12.2020 um 15:42 schrieb David Chisnall :
> 
> Please can you try the attached patch?

So the patch resolves the objc_begin_catch/objc_end_catch undefined symbols, 
but it doesn’t resolve __gnustep_objc_personality_v0 and adds some new linker 
errors ones:

> lld-link: error: undefined symbol: __gnustep_objc_personality_v0
> >>> referenced by obj/libgnustep-base.obj/GSHTTPAuthentication.m.o:(.xdata)
> >>> referenced by 
> >>> obj/libgnustep-base.obj/GSHTTPAuthentication.m.o:(GCC_except_table2)
> >>> referenced by 
> >>> obj/libgnustep-base.obj/GSHTTPAuthentication.m.o:(GCC_except_table4)
> >>> referenced 121 more times
> 
> lld-link: error: undefined symbol: vtable for __cxxabiv1::__class_type_info
> >>> referenced by obj/libgnustep-base.obj/GSHTTPAuthentication.m.o:(typeinfo 
> >>> for NSObject)
> >>> referenced by obj/libgnustep-base.obj/GSTimSort.m.o
> >>> referenced by obj/libgnustep-base.obj/GSTLS.m.o
> 
> lld-link: error: undefined symbol: vtable for __cxxabiv1::__si_class_type_info
> >>> referenced by obj/libgnustep-base.obj/GSHTTPAuthentication.m.o:(typeinfo 
> >>> for NSException)
> >>> referenced by obj/libgnustep-base.obj/GSTimSort.m.o
> >>> referenced by obj/libgnustep-base.obj/GSTLS.m.o
> 
> lld-link: error: undefined symbol: vtable for __cxxabiv1::__pointer_type_info
> >>> referenced by obj/libgnustep-base.obj/GSHTTPAuthentication.m.o:(typeinfo 
> >>> for NSException*)
> >>> referenced by obj/libgnustep-base.obj/GSTimSort.m.o
> >>> referenced by obj/libgnustep-base.obj/GSTLS.m.o

Thoughts?

Thanks!
Frederik

Re: Building GNUstep for Windows using Clang

[Frederik Seiffert]

> Am 02.12.2020 um 17:07 schrieb Gregory Casamento :
> 
> Just a suggestion.  Could you commit the binary resulting from the build?  
> While David might disagree, this is a very heavyweight and difficult build 
> process.  I would prefer to spare others from having to go through it.  If 
> someone else doesn't commit it, I will go through the process and do it 
> myself.

Yeah good idea, I can upload the self-built MinGW Clang packages with David’s 
patch if all goes well here (still building, first try had tests hanging and 
makepkg nuked the results in a subsequent attempt without tests...).

I ended up adding the patch to the mingw-w64-clang package locally, so the 
resulting package should in theory be identical to the official MSYS2 packages 
in every other way.

Frederik

Re: Building GNUstep for Windows using Clang

[David Chisnall]

On 02/12/2020 16:24, David Wetzel wrote:
Wouldn’t it be better to have a windows build on the website to download 
as a binary?


There are Windows builds on the LLVM web site, you can install them via 
chocho on Windows.


David

Re: Building GNUstep for Windows using Clang

[David Wetzel]

Wouldn’t it be better to have a windows build on the website to download as a 
binary?
Binaries in a repository are painful. 

David 

> Am 2020-12-02 um 11:08 schrieb Gregory Casamento :
> 
> 
> Just a suggestion.  Could you commit the binary resulting from the build?  
> While David might disagree, this is a very heavyweight and difficult build 
> process.  I would prefer to spare others from having to go through it.  If 
> someone else doesn't commit it, I will go through the process and do it 
> myself.
> 
> GC
> 
> 
>> On Wed, Dec 2, 2020 at 7:24 AM Frederik Seiffert  
>> wrote:
>> 
>>> Am 02.12.2020 um 10:50 schrieb David Chisnall :
>>> 
>>> You should be able to just do a Windows build with the VS command prompt 
>>> and CMake.  I normally build clang with CMake + Ninja + either Visual 
>>> Studio or an existing LLVM install on Windows.  There are no other 
>>> dependencies.
>> 
>> Thanks, it’s building now, fans spinning. :)
>> 
>> Frederik
>> 
> 
> 
> -- 
> Gregory Casamento
> GNUstep Lead Developer / OLC, Principal Consultant
> http://www.gnustep.org - http://heronsperch.blogspot.com
> https://www.patreon.com/bePatron?u=352392 - Become a Patron
> https://gf.me/u/x8m3sx - My GNUstep GoFundMe
> https://teespring.com/stores/gnustep - Store

Re: Building GNUstep for Windows using Clang

[Gregory Casamento]

Just a suggestion.  Could you commit the binary resulting from the build?
While David might disagree, this is a very heavyweight and difficult build
process.  I would prefer to spare others from having to go through it.  If
someone else doesn't commit it, I will go through the process and do it
myself.

GC


On Wed, Dec 2, 2020 at 7:24 AM Frederik Seiffert 
wrote:

>
> Am 02.12.2020 um 10:50 schrieb David Chisnall :
>
> You should be able to just do a Windows build with the VS command prompt
> and CMake.  I normally build clang with CMake + Ninja + either Visual
> Studio or an existing LLVM install on Windows.  There are no other
> dependencies.
>
>
> Thanks, it’s building now, fans spinning. :)
>
> Frederik
>
>

-- 
Gregory Casamento
GNUstep Lead Developer / OLC, Principal Consultant
http://www.gnustep.org - http://heronsperch.blogspot.com
https://www.patreon.com/bePatron?u=352392 - Become a Patron
https://gf.me/u/x8m3sx - My GNUstep GoFundMe
https://teespring.com/stores/gnustep - Store

Re: Building GNUstep for Windows using Clang

[Frederik Seiffert]

> Am 02.12.2020 um 10:50 schrieb David Chisnall :
> 
> You should be able to just do a Windows build with the VS command prompt and 
> CMake.  I normally build clang with CMake + Ninja + either Visual Studio or 
> an existing LLVM install on Windows.  There are no other dependencies.

Thanks, it’s building now, fans spinning. :)

Frederik

Re: Building GNUstep for Windows using Clang

[Frederik Seiffert]

> Am 01.12.2020 um 15:42 schrieb David Chisnall :
> 
> Please can you try the attached patch?

That was quick, thank you very much! I’m having some trouble building Clang via 
MINGW-packages (https://github.com/msys2/MINGW-packages/issues/7369), but I’ll 
let you know as soon as I get that to work.

Frederik

Re: Building GNUstep for Windows using Clang

[David Chisnall]

On 02/12/2020 09:36, Frederik Seiffert wrote:

Am 01.12.2020 um 15:42 schrieb David Chisnall :

Please can you try the attached patch?


That was quick, thank you very much! I’m having some trouble building Clang via 
MINGW-packages (https://github.com/msys2/MINGW-packages/issues/7369), but I’ll 
let you know as soon as I get that to work.


You should be able to just do a Windows build with the VS command prompt 
and CMake.  I normally build clang with CMake + Ninja + either Visual 
Studio or an existing LLVM install on Windows.  There are no other 
dependencies.


David

Re: Building GNUstep for Windows using Clang

[Frederik Seiffert]

Hi Riccardo,

> Am 01.12.2020 um 16:27 schrieb Riccardo Mottola :
> 
> just as a note, I tried an update with current ming64 and gcc and things
> work as before (nothing broke!)
> Actually, there is an improvement, JPEG images work because I fixed it
> some weeks ago!

Nice, thanks!

> I noticed that we don't do CI build of mingw32 and ming64 with gcc
> though, so my test shows... no regression and small fixes.

We are doing CI builds for mingw32 and mingw64 with gcc (although a number of 
tests are still failing):
https://github.com/gnustep/libs-base/blob/1b7bf26beaaafb76325471780c55d36824a35889/.travis.yml#L26-L33

Or did you mean something else?

Frederik

Re: Building GNUstep for Windows using Clang

[Riccardo Mottola]

Hi,


Frederik Seiffert wrote:
> I took another stab at building for Windows, and using a fresh MSYS2
> installation and the latest dependencies and Clang version I was able
> to make a bit of progress and run into some new issues...

just as a note, I tried an update with current ming64 and gcc and things
work as before (nothing broke!)
Actually, there is an improvement, JPEG images work because I fixed it
some weeks ago!

I still have connection problems to SOAP services over HTTPS but did not
find the exact issue.

I noticed that we don't do CI build of mingw32 and ming64 with gcc
though, so my test shows... no regression and small fixes.

Riccardo

Re: Building GNUstep for Windows using Clang

[David Chisnall]

On 01/12/2020 12:40, Frederik Seiffert wrote:

Am 30.11.2020 um 17:59 schrieb David Chisnall :

I think this is a clang bug.  I am probably guarding this on an MSVC target 
triple and not on SEH exceptions.  Please can you file a clang bug and assign 
it to me?



https://bugs.llvm.org/show_bug.cgi?id=48348

I hope I summarized this somewhat correctly. Happy to try to build Clang from 
source once there is a patch.

I know it might not be your say, but if there is any way to still get this into 
a Clang 11 point release that would be very much appreciated. If there’s 
anything I can do to help make that happen please just let me know.


Please can you try the attached patch?

Thanks,

David

diff --git a/clang/lib/CodeGen/CGObjCGNU.cpp 
b/clang/lib/CodeGen/CGObjCGNU.cpp

index 9825d7bca18c..102da37a99e2 100644
--- a/clang/lib/CodeGen/CGObjCGNU.cpp
+++ b/clang/lib/CodeGen/CGObjCGNU.cpp
@@ -2134,8 +2134,7 @@ CGObjCGNU::CGObjCGNU(CodeGenModule , unsigned 
runtimeABIVersion,

 ProtocolVersion(protocolClassVersion), ClassABIVersion(classABI) {

   msgSendMDKind = VMContext.getMDKindID("GNUObjCMessageSend");
-  usesSEHExceptions =
- 
cgm.getContext().getTargetInfo().getTriple().isWindowsMSVCEnvironment();

+  usesSEHExceptions = cgm.getLangOpts().SEHExceptions;

   CodeGenTypes  = CGM.getTypes();
   IntTy = cast(

Re: Building GNUstep for Windows using Clang

[Frederik Seiffert]

> Am 30.11.2020 um 17:59 schrieb David Chisnall :
> 
> I think this is a clang bug.  I am probably guarding this on an MSVC target 
> triple and not on SEH exceptions.  Please can you file a clang bug and assign 
> it to me?


https://bugs.llvm.org/show_bug.cgi?id=48348

I hope I summarized this somewhat correctly. Happy to try to build Clang from 
source once there is a patch.

I know it might not be your say, but if there is any way to still get this into 
a Clang 11 point release that would be very much appreciated. If there’s 
anything I can do to help make that happen please just let me know.

Thanks!
Frederik

Re: Building GNUstep for Windows using Clang

[David Chisnall]

On 30/11/2020 16:52, Frederik Seiffert wrote:

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.


I think this is a clang bug.  I am probably guarding this on an MSVC 
target triple and not on SEH exceptions.  Please can you file a clang 
bug and assign it to me?


David

Re: Building GNUstep for Windows using Clang

[Frederik Seiffert]

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

Re: Building GNUstep for Windows using Clang

[David Chisnall]

Thanks,

It looks like you’ve already raised a PR to fix many of these.

> On 26 Nov 2020, at 12:18, Frederik Seiffert  wrote:
>>  Linking library libgnustep-base ...
>> lld-link: warning: obj/libgnustep-base.obj/GSLocale.m.o: locally defined 
>> symbol imported: $_OBJC_CLASS_NSConstantString (defined in 
>> obj/libgnustep-base.obj/GSString.m.o) [LNK4217]
>> ...
> 
> These warnings (a couple pages of them) are probably harmless but maybe 
> someone knows what they are about?

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.

> 
>> lld-link: error: undefined symbol: objc_skip_type_qualifiers
>> lld-link: error: undefined symbol: objc_skip_typespec
>> lld-link: error: undefined symbol: objc_alignof_type
>> lld-link: error: undefined symbol: objc_sizeof_type
>> lld-link: error: undefined symbol: objc_layout_structure
>> lld-link: error: undefined symbol: objc_layout_structure_next_member
>> lld-link: error: undefined symbol: objc_layout_structure_get_info
>> lld-link: error: undefined symbol: objc_get_type_qualifiers
>> lld-link: error: undefined symbol: objc_promoted_size
> 
> These were built as part of libobjc2 (encoding2.c), but they don’t seem to be 
> exported in the DLL. Is encoding.h missing some export statements?

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.

> 
>> lld-link: error: undefined symbol: __gnustep_objc_personality_v0
>> >>> referenced by obj/libgnustep-base.obj/GSICUString.m.o:(.xdata)
>> >>> referenced by obj/libgnustep-base.obj/NSRegularExpression.m.o:(.xdata)
>> >>> referenced by 
>> >>> obj/libgnustep-base.obj/NSRegularExpression.m.o:(GCC_except_table11)
>> 
>> lld-link: error: undefined symbol: __declspec(dllimport) 
>> _objc_class_for_boxing_foreign_exception
>> >>> referenced by 
>> >>> obj/libgnustep-base.obj/CXXException.m.o:(_c_CXXException__load)
>> 
>> lld-link: error: undefined symbol: __declspec(dllimport) _objc_weak_load
>> >>> referenced by obj/libgnustep-base.obj/NSObject.m.o:(_c_NSObject__load)
>> 
>> lld-link: error: undefined symbol: __declspec(dllimport) _objc_load_callback
>> >>> referenced by obj/libgnustep-base.obj/objc-load.m.o:(GSPrivateLoadModule)
> 
> Not sure about these…

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?

David

Re: Building GNUstep for Windows using Clang

[Frederik Seiffert]

Hi all,

I took another stab at building for Windows, and using a fresh MSYS2 
installation and the latest dependencies and Clang version I was able to make a 
bit of progress and run into some new issues...

After building libobjc2 in a Visual Studio prompt and getting Make to build 
(more on that below), I got Base building as well but it fails when linking:

>  Linking library libgnustep-base ...
> lld-link: warning: obj/libgnustep-base.obj/GSLocale.m.o: locally defined 
> symbol imported: $_OBJC_CLASS_NSConstantString (defined in 
> obj/libgnustep-base.obj/GSString.m.o) [LNK4217]
> ...

These warnings (a couple pages of them) are probably harmless but maybe someone 
knows what they are about?

> lld-link: error: undefined symbol: objc_skip_type_qualifiers
> lld-link: error: undefined symbol: objc_skip_typespec
> lld-link: error: undefined symbol: objc_alignof_type
> lld-link: error: undefined symbol: objc_sizeof_type
> lld-link: error: undefined symbol: objc_layout_structure
> lld-link: error: undefined symbol: objc_layout_structure_next_member
> lld-link: error: undefined symbol: objc_layout_structure_get_info
> lld-link: error: undefined symbol: objc_get_type_qualifiers
> lld-link: error: undefined symbol: objc_promoted_size

These were built as part of libobjc2 (encoding2.c), but they don’t seem to be 
exported in the DLL. Is encoding.h missing some export statements?

> lld-link: error: undefined symbol: __gnustep_objc_personality_v0
> >>> referenced by obj/libgnustep-base.obj/GSICUString.m.o:(.xdata)
> >>> referenced by obj/libgnustep-base.obj/NSRegularExpression.m.o:(.xdata)
> >>> referenced by 
> >>> obj/libgnustep-base.obj/NSRegularExpression.m.o:(GCC_except_table11)
> 
> lld-link: error: undefined symbol: __declspec(dllimport) 
> _objc_class_for_boxing_foreign_exception
> >>> referenced by 
> >>> obj/libgnustep-base.obj/CXXException.m.o:(_c_CXXException__load)
> 
> lld-link: error: undefined symbol: __declspec(dllimport) _objc_weak_load
> >>> referenced by obj/libgnustep-base.obj/NSObject.m.o:(_c_NSObject__load)
> 
> lld-link: error: undefined symbol: __declspec(dllimport) _objc_load_callback
> >>> referenced by obj/libgnustep-base.obj/objc-load.m.o:(GSPrivateLoadModule)


Not sure about these...


I’d appreciate anyone’s thoughts on the above, but also this seems a lot 
further than what I got back in May when I tried last, so that’s very 
encouraging.

Following all the steps to get to the point I’m at just for reference.


1. Install MSYS2 and dependencies

pacman -S git make pkg-config libxml2-devel libxslt-devel libffi-devel 
libgnutls-devel icu-devel
pacman -S mingw-w64-x86_64-pkg-config mingw-w64-x86_64-libxml2 
mingw-w64-x86_64-libxslt mingw-w64-x86_64-libffi mingw-w64-x86_64-gnutls 
mingw-w64-x86_64-icu mingw-w64-x86_64-clang mingw-w64-x86_64-lld

2. Build libobjc2 in "x64 Native Tools Command Prompt for VS 2019"

cmake .. -G Ninja -DTESTS=off -DCMAKE_BUILD_TYPE=RelWithDebInfo 
-DCMAKE_INSTALL_PREFIX:PATH=C:\GNUstep\x64 -DCMAKE_C_COMPILER=clang 
-DCMAKE_CXX_COMPILER=clang
ninja install

3. Build GNUstep Make in MinGW64 prompt

./configure --prefix=/c/GNUstep/x64 --with-library-combo=ng-gnu-gnu 
--with-runtime-abi=gnustep-2.0 LDFLAGS="-fuse-ld=lld -L/c/GNUstep/x64/lib" 
CFLAGS="-I/c/GNUstep/x64/include"

This required a couple tries to get all the config checks to pass. For some 
reason some of the checks don’t seem to search the prefix for libraries or 
headers, so I had to add -L and -I flags manually as well. Also I think using 
lld instead of ld is key.

It still shows the following warning, which seems incorrect though as lld _is_ 
being used successfully for all linking:

checking for an gnustep-2.0 ABI compatible linker... unlikely (GNU ld)
configure: WARNING: The detected linker might not produce working Objective-C 
binaries using the gnustep-2.0 ABI. Consider using gold or LLD.

Also it native exceptions are not recognized for some reason:

checking whether the compiler supports native ObjC exceptions... no

4. Building GNUstep Base in MinGW64 prompt

. /c/GNUstep/x64/share/GNUstep/Makefiles/GNUstep.sh
cp /c/GNUstep/x64/lib/objc.dll .
./configure
make

The only important point here is to copy objc.dll into the source directory so 
that the config tests will find it when being run. Maybe configure should do 
that automatically?


Thanks,
Frederik

Re: Building GNUstep for Windows using Clang

[Riccardo Mottola]

Hi,

Frederik Seiffert wrote:
> I did /not/ have to patch the MSYS2 headers as written in the
> instructions, but maybe that’s only needed for Gui?

patching was only needed for Gui not for Base. Now it is no longer
needed, I was able to make the necessary workarounds in our code.

Riccardo

Re: Building GNUstep for Windows using Clang

[Frederik Seiffert]

I’ve opened a pull request that adds CI targets for 32- and 64-bit Windows 
using MinGW-w64 and GCC:
https://github.com/gnustep/libs-base/pull/136

It’s not fully working (more details in the PR), but I think it’s a start. I’d 
appreciate any feedback and thoughts on how to get the builds and tests fixed.

Frederik


> Am 15.05.2020 um 10:00 schrieb Frederik Seiffert :
> 
> Hi all,
> 
> Following up on this thread I wanted to give a quick update on building 
> GNUstep for Windows.
> 
> First, I managed to build Base successfully using GCC on MinGW 64-bit 
> following Riccardo’s helpful instructions at 
> http://wiki.gnustep.org/index.php/Installation_MSYS2 
> .
> Two small things here (I can’t edit the wiki, so would be great if someone 
> could add these):
> 
> 1. The build instructions for Make are obviously missing a "make install" 
> step.
> 2. I also had to install the following packages for ICU:
>   - mingw64/mingw-w64-x86_64-icu
>   - msys/icu-devel
> 
> I did not have to patch the MSYS2 headers as written in the instructions, but 
> maybe that’s only needed for Gui?
> 
> It does show a lot of warnings during build, some of which look somewhat 
> concerning. If I find some time I’ll try to add a Windows OS target to the 
> Travis setup to run the tests and ensure this is kept working.
> 
> As a side note, Make doesn’t seem to handle spaces in the home directory 
> correctly – does someone know where to fix this?
> 
>> $ /mingw64/bin/gnustep-config --objc-flags
>> -MMD -MP -DGNUSTEP -DGNUSTEP_BASE_LIBRARY=1 -DGNU_RUNTIME=1 
>> -DGNUSTEP_BASE_LIBRARY=1 -DGNUSTEP_WITH_DLL -fno-strict-aliasing 
>> -fno-omit-frame-pointer -Wall -DGSWARN -DGSDIAGNOSE -Wno-import -g -O2 
>> -fconstant-string-class=NSConstantString -I. -I/home/Frederik 
>> -ISeiffert/GNUstep/Library/Headers -I/mingw64/include
> 
> 
> 
> Moving on to building with Clang and libobjc2, as mentioned in an earlier 
> message to this thread, I first built libobjc2 in a Visual Studio command 
> prompt using CMake and clang-cl, which according to David is the way to go.
> 
> I’ve then been trying two approaches for building GNUstep:
> 
> 1. Using MinGW 32/64-bit, and setting CC/CXX env vars to Clang:
> 
>   I have not been able to get this to work at all so far, as I can’t 
> figure out how to change the linker to LLD or ld.gold, as required for this 
> setup. Neither setting LD=lld or LDFLAGS="-fuse-ld=lld" or "=gold" seems to 
> have any effect. Calling "clang --print-prog-name=ld" (which is what Make 
> does to check which linker is being used) will always output ld. I’m probably 
> missing something here – can anyone point me in the right direction how to 
> change the linker?
> 
> 2. Using the llvm-mingw toolchain (https://github.com/mstorsjo/llvm-mingw 
> ), which is preconfigured to use LLD:
> 
>   This goes pretty far (after a couple fixes I pushed yesterday), but in 
> the end fails for me with the following:
> 
>> No rule to make target 'Additions/obj/subproject.o', needed by 
>> 'obj/libgnustep-base.a'
> 
> 
> I’d appreciate any thoughts on the above.
> 
> Thanks!
> Frederik
> 

Re: Building GNUstep for Windows using Clang

[Frederik Seiffert]

Hi all,

Following up on this thread I wanted to give a quick update on building GNUstep 
for Windows.

First, I managed to build Base successfully using GCC on MinGW 64-bit following 
Riccardo’s helpful instructions at 
http://wiki.gnustep.org/index.php/Installation_MSYS2.
Two small things here (I can’t edit the wiki, so would be great if someone 
could add these):

1. The build instructions for Make are obviously missing a "make install" step.
2. I also had to install the following packages for ICU:
- mingw64/mingw-w64-x86_64-icu
- msys/icu-devel

I did not have to patch the MSYS2 headers as written in the instructions, but 
maybe that’s only needed for Gui?

It does show a lot of warnings during build, some of which look somewhat 
concerning. If I find some time I’ll try to add a Windows OS target to the 
Travis setup to run the tests and ensure this is kept working.

As a side note, Make doesn’t seem to handle spaces in the home directory 
correctly – does someone know where to fix this?

> $ /mingw64/bin/gnustep-config --objc-flags
> -MMD -MP -DGNUSTEP -DGNUSTEP_BASE_LIBRARY=1 -DGNU_RUNTIME=1 
> -DGNUSTEP_BASE_LIBRARY=1 -DGNUSTEP_WITH_DLL -fno-strict-aliasing 
> -fno-omit-frame-pointer -Wall -DGSWARN -DGSDIAGNOSE -Wno-import -g -O2 
> -fconstant-string-class=NSConstantString -I. -I/home/Frederik 
> -ISeiffert/GNUstep/Library/Headers -I/mingw64/include



Moving on to building with Clang and libobjc2, as mentioned in an earlier 
message to this thread, I first built libobjc2 in a Visual Studio command 
prompt using CMake and clang-cl, which according to David is the way to go.

I’ve then been trying two approaches for building GNUstep:

1. Using MinGW 32/64-bit, and setting CC/CXX env vars to Clang:

I have not been able to get this to work at all so far, as I can’t 
figure out how to change the linker to LLD or ld.gold, as required for this 
setup. Neither setting LD=lld or LDFLAGS="-fuse-ld=lld" or "=gold" seems to 
have any effect. Calling "clang --print-prog-name=ld" (which is what Make does 
to check which linker is being used) will always output ld. I’m probably 
missing something here – can anyone point me in the right direction how to 
change the linker?

2. Using the llvm-mingw toolchain (https://github.com/mstorsjo/llvm-mingw), 
which is preconfigured to use LLD:

This goes pretty far (after a couple fixes I pushed yesterday), but in 
the end fails for me with the following:

> No rule to make target 'Additions/obj/subproject.o', needed by 
> 'obj/libgnustep-base.a'


I’d appreciate any thoughts on the above.

Thanks!
Frederik

Re: Building GNUstep for Windows using Clang

[Gregory Casamento]

I will try to reproduce with gcc.  Then I will see if I can get clang
working.   I would very much like to get clang working.  It would be nice
if there were a prebuilt package.

On Thu, Mar 12, 2020 at 7:40 PM Riccardo Mottola 
wrote:

> Hi,
>
> Frederik Seiffert wrote:
> >>
> >>
> >> http://wiki.gnustep.org/index.php/Installation_MSYS2
> 
> >
> >
> > Thank you Riccardo! I’ll follow along and will gladly test
> > instructions here.
> >
>
> I just complteted to my best. By writing this tutorial I was finally
> able to replicate the setup I had once runnign at work also on my
> personal system. I failed previously!
>
> I got "Ink" working.
> Unfortunately other problems exist. E.g. jpeg images are not loaded,
> network connections do not work.
> (All this worked in our old, classinc mingw setup)
>
> Maybe you want to try your luck with gcc and objc-1 first to see if then
> everything works and then start working on clang?
>
> Riccardo
>
>

-- 
Gregory Casamento
GNUstep Lead Developer / OLC, Principal Consultant
http://www.gnustep.org

- http://heronsperch.blogspot.com

http://ind.ie/phoenix/

Re: Building GNUstep for Windows using Clang

[Riccardo Mottola]

Hi,

Frederik Seiffert wrote:
>>
>>
>> http://wiki.gnustep.org/index.php/Installation_MSYS2
>
>
> Thank you Riccardo! I’ll follow along and will gladly test
> instructions here.
>

I just complteted to my best. By writing this tutorial I was finally
able to replicate the setup I had once runnign at work also on my
personal system. I failed previously!

I got "Ink" working.
Unfortunately other problems exist. E.g. jpeg images are not loaded,
network connections do not work.
(All this worked in our old, classinc mingw setup)

Maybe you want to try your luck with gcc and objc-1 first to see if then
everything works and then start working on clang?

Riccardo

Re: Building GNUstep for Windows using Clang

[Frederik Seiffert]

> Am 07.03.2020 um 12:33 schrieb Riccardo Mottola :
> 
> since several people asked about it, I will collect and share my work here:
> 
> 
> http://wiki.gnustep.org/index.php/Installation_MSYS2 
> 


Thank you Riccardo! I’ll follow along and will gladly test instructions here.

Frederik

Re: Building GNUstep for Windows using Clang

[Frederik Seiffert]

Hi David,

> Am 06.03.2020 um 17:51 schrieb David Chisnall :
> 
>> I also had to remove "OBJ_MERGE_CMD_FLAG" in config.make, as LLD doesn’t 
>> support the -r flag for incremental linking.
> 
> Hmm, that probably means that -base Additions won't build.

Ah makes sense. So I guess that means we can’t use LLD on Windows unless 
GNUstep Make is rewritten to not use incremental linking.

Unfortunately the Gold linker doesn’t seem to support Windows COFF 
(https://github.com/msys2/MINGW-packages/issues/4807 
), so I’m not sure where 
to go from here.

Frederik

Re: Building GNUstep for Windows using Clang

[Johannes Brakensiek]

Gregory,

On 8 Mar 2020, at 1:41, Gregory Casamento wrote:

Sorry for the confusion, but MailTrack is a service I pay for so I can 
verify that clients are actually reading my email.  It's not tracking 
by google.  It's tracking by me.  Occasionally I accidentally leave 
it on when I send to this list.


I hope that solves the moral dilemma.   From now on I will make sure 
it is off prior to mailing to the list.


Thank you for clarification. No problem. Sorry for any inconvenience.

Best
Johannes

Re: Building GNUstep for Windows using Clang

[Gregory Casamento]

Johannes,

Sorry for the confusion, but MailTrack is a service I pay for so I can
verify that clients are actually reading my email.  It's not tracking by
google.  It's tracking by me.  Occasionally I accidentally leave it on when
I send to this list.

I hope that solves the moral dilemma.   From now on I will make sure it is
off prior to mailing to the list.

GC

On Sat, Mar 7, 2020 at 3:38 PM Johannes Brakensiek 
wrote:

>
>
> On 7 Mar 2020, at 20:52, Ivan Vučica wrote:
>
> > [still OT:] Where does it say that The Mail Track Company, S.L. is
> > owned by Google?
>
> Thank you for that hint. Good question. Just seems to be a plugin to
> Gmail? If it could be disabled I’d be happy (still knowing using Gmail
> includes some serious flaws, but most of them do not apply for a public
> mailing list.)
>
> Johannes
>
>

-- 
Gregory Casamento
GNUstep Lead Developer / OLC, Principal Consultant
http://www.gnustep.org

- http://heronsperch.blogspot.com

http://ind.ie/phoenix/

Re: Building GNUstep for Windows using Clang

[Johannes Brakensiek]

On 7 Mar 2020, at 20:52, Ivan Vučica wrote:


[still OT:] Where does it say that The Mail Track Company, S.L. is
owned by Google?


Thank you for that hint. Good question. Just seems to be a plugin to 
Gmail? If it could be disabled I’d be happy (still knowing using Gmail 
includes some serious flaws, but most of them do not apply for a public 
mailing list.)


Johannes

Re: Building GNUstep for Windows using Clang

[Ivan Vučica]

On Sat, Mar 7, 2020 at 6:50 PM Johannes Brakensiek
 wrote:
> Everyone clicking on that link accidentally is tracked by Google even if
> he/she did not consent with it. For me that does not fit well to a
> project reaching out for software freedom. No offense, just what I
> thought.

[still OT:] Where does it say that The Mail Track Company, S.L. is
owned by Google?

Re: Building GNUstep for Windows using Clang

[Johannes Brakensiek]

On 7 Mar 2020, at 19:31, Gregory Casamento wrote:


OT: Could you please clarify your point?


Everyone clicking on that link accidentally is tracked by Google even if 
he/she did not consent with it. For me that does not fit well to a 
project reaching out for software freedom. No offense, just what I 
thought.


Johannes

Re: Building GNUstep for Windows using Clang

[Gregory Casamento]

OT: Could you please clarify your point?

On Sat, Mar 7, 2020 at 1:16 PM Johannes Brakensiek 
wrote:

>
>
> On 7 Mar 2020, at 19:03, Gregory Casamento wrote:
>
> > [http://wiki.gnustep.org/index.php/Installation_MSYS2](
> 
> <
> https://mailtrack.io/trace/link/ecfffb1e1e01ed33b8146aebcbb6613500e9d421?url=http%3A%2F%2Fwiki.gnustep.org%2Findex.php%2FInstallation_MSYS2=2790543=7dfd345a079b5f9d
> 
> >)
>
> OT: As this is a GNU mailing list I’d like to point to the fact that
> using gmail converts this link to one tracked by Google using
> mailtrack.io
> 
> .
>
> Johannes
>


-- 
Gregory Casamento
GNUstep Lead Developer / OLC, Principal Consultant
http://www.gnustep.org

- http://heronsperch.blogspot.com

http://ind.ie/phoenix/

Re: Building GNUstep for Windows using Clang

[Johannes Brakensiek]

On 7 Mar 2020, at 19:03, Gregory Casamento wrote:


[http://wiki.gnustep.org/index.php/Installation_MSYS2]()


OT: As this is a GNU mailing list I’d like to point to the fact that 
using gmail converts this link to one tracked by Google using 
mailtrack.io.


Johannes

Re: Building GNUstep for Windows using Clang

[Gregory Casamento]

Riccardo,

Thank you so much, old friend.   This is great news.

GC

On Sat, Mar 7, 2020 at 6:33 AM Riccardo Mottola 
wrote:

> Hi,
>
> On 3/7/20 11:54 AM, Riccardo Mottola wrote:
> >
> >
> > well, since I am working since almost a year to get instead a working
> > ming64 setup on windows7 & windows10 with GCC, there is probably some
> > common ground.
> >
> > I never started this because.. it yields a not totally stable result
> > and it is not very reproducible from computer to computer, it is very
> > strange.
> >
> > I propose a wiki page. Then two sub-sections for the different
> > compiler & runtimes.
> >
>
> since several people asked about it, I will collect and share my work here:
>
>
> http://wiki.gnustep.org/index.php/Installation_MSYS2
> 
>
>
>
> Riccardo
>
>
>

-- 
Gregory Casamento
GNUstep Lead Developer / OLC, Principal Consultant
http://www.gnustep.org

- http://heronsperch.blogspot.com

http://ind.ie/phoenix/

Re: Building GNUstep for Windows using Clang

[Riccardo Mottola]

Hi,

On 3/7/20 11:54 AM, Riccardo Mottola wrote:



well, since I am working since almost a year to get instead a working 
ming64 setup on windows7 & windows10 with GCC, there is probably some 
common ground.


I never started this because.. it yields a not totally stable result 
and it is not very reproducible from computer to computer, it is very 
strange.


I propose a wiki page. Then two sub-sections for the different 
compiler & runtimes.




since several people asked about it, I will collect and share my work here:


http://wiki.gnustep.org/index.php/Installation_MSYS2



Riccardo

Re: Building GNUstep for Windows using Clang

[Riccardo Mottola]

Hi,

On 3/6/20 7:44 PM, Gregory Casamento wrote:


Since we are talking about building on Windows 10 using clang and 
msys2 I would like someone to write up a comprehensive guide on how.  
 From A to Z, please.   I realize I'm likely to be roasted for this 
request by multiple people, but at this point it needs to be done and 
I am quite used to being roasted. :/



well, since I am working since almost a year to get instead a working 
ming64 setup on windows7 & windows10 with GCC, there is probably some 
common ground.


I never started this because.. it yields a not totally stable result and 
it is not very reproducible from computer to computer, it is very strange.


I propose a wiki page. Then two sub-sections for the different compiler 
& runtimes.


Riccardo

Re: Building GNUstep for Windows using Clang

[Gregory Casamento]

Guys,

Since we are talking about building on Windows 10 using clang and msys2 I
would like someone to write up a comprehensive guide on how.   From A to Z,
please.   I realize I'm likely to be roasted for this request by multiple
people, but at this point it needs to be done and I am quite used to being
roasted. :/

Yours, GC

On Fri, Mar 6, 2020 at 11:51 AM David Chisnall 
wrote:

> On 05/03/2020 00:43, Frederik Seiffert wrote:
> > Thanks David. I made some progress with this setup, although it does
> > feel like we’re a bit off the beaten track here (again)...
> >
> > To get libobjc linking with the MinGW clang toolchain using LLD I had to
> > create an import library (.dll.a) as outlined on the MinGW website:
> > http://www.mingw.org/wiki/CreateImportLibraries
> 
> >
> > Basically I ran "dumpbin /exports objc.dll" to get the list of symbols,
> > used that to manually create a objc.def file, and then ran "dlltool -d
> > objc.def -l objc.dll.a". One thing I noticed is that this doesn’t seem
> > to include global variables (e.g. _objc_unexpected_exception), so these
> > won’t be picked up by GNUstep configure and thus native exception
> > support won’t work.
> >
> > In the end however I switched to using the llvm-mingw toolchain
> > (https://github.com/mstorsjo/llvm-mingw
> ),
> which defaults to LLD and
> > directly picks up the objc.lib without the need for the import library
> > (but also doesn’t seem allow linking global variables).
> >
> > I also had to remove "OBJ_MERGE_CMD_FLAG" in config.make, as LLD doesn’t
> > support the -r flag for incremental linking.
>
> Hmm, that probably means that -base Additions won't build.
>
> >
> > With this and a couple more configure flags I got Base to start
> > compiling, but I’m now stuck at the Additions subproject failing to link
> > because it seems to be missing all the necessary linker flags:
> >
> >> clang -nostdlib-o ./obj/subproject.o
> >> obj/Additions.obj/GSTypeEncoding.c.o ...
> >> lld-link: error: : undefined symbol: _mainCRTStartup
> >> lld-link: error: undefined symbol: _malloc
> >> lld-link: error: undefined symbol: __declspec(dllimport)
> _object_getClass
> >> ...
> >
> > Does anyone with better knowledge of GNUstep make have an idea of why
> > this might happen or how to debug this further?
>
> If you're not using -r, then I don't know what this .o will be.  The
> subproject thing is a source of constant pain because almost nothing
> other than GNUstep uses -r, so it tends to be horribly buggy.  It's
> supposed to take a load of .o files and generate a .o file that can be
> linked as if it were the original list of .o files.  Modern build
> systems just pass the list of .o files around.
>
> >
> >
> >> There is a bug somewhere in the SEH support that I need to look for.
> >>  I suspect it is in clang - EH seems to fail with ARC and I think that
> >> it may be to do with the ARC calls not being correctly emitted in the
> >> funclet.  Dustin is planning on looking at some of the Clang funclet
> >> issues.
> >
> > That’s good to know, thanks.
> >
> > By the way, is libcxxrt needed on Windows for ObjC++ EH on Windows?
> > Seems like WinObjC is not using it.
>
>
> No, libcxxrt implements the Itanium C++ ABI.  On Windows, libobjc2
> supports the Visual Studio C++ ABI, so exceptions should interop with
> C++ libraries compiled with clang or MSVC.
>
> David
>
>

-- 
Gregory Casamento
GNUstep Lead Developer / OLC, Principal Consultant
http://www.gnustep.org

- http://heronsperch.blogspot.com

http://ind.ie/phoenix/

Re: Building GNUstep for Windows using Clang

[David Chisnall]

On 05/03/2020 00:43, Frederik Seiffert wrote:
Thanks David. I made some progress with this setup, although it does 
feel like we’re a bit off the beaten track here (again)...


To get libobjc linking with the MinGW clang toolchain using LLD I had to 
create an import library (.dll.a) as outlined on the MinGW website:

http://www.mingw.org/wiki/CreateImportLibraries

Basically I ran "dumpbin /exports objc.dll" to get the list of symbols, 
used that to manually create a objc.def file, and then ran "dlltool -d 
objc.def -l objc.dll.a". One thing I noticed is that this doesn’t seem 
to include global variables (e.g. _objc_unexpected_exception), so these 
won’t be picked up by GNUstep configure and thus native exception 
support won’t work.


In the end however I switched to using the llvm-mingw toolchain 
(https://github.com/mstorsjo/llvm-mingw), which defaults to LLD and 
directly picks up the objc.lib without the need for the import library 
(but also doesn’t seem allow linking global variables).


I also had to remove "OBJ_MERGE_CMD_FLAG" in config.make, as LLD doesn’t 
support the -r flag for incremental linking.


Hmm, that probably means that -base Additions won't build.



With this and a couple more configure flags I got Base to start 
compiling, but I’m now stuck at the Additions subproject failing to link 
because it seems to be missing all the necessary linker flags:


clang -nostdlib        -o ./obj/subproject.o 
obj/Additions.obj/GSTypeEncoding.c.o ...

lld-link: error: : undefined symbol: _mainCRTStartup
lld-link: error: undefined symbol: _malloc
lld-link: error: undefined symbol: __declspec(dllimport) _object_getClass
...


Does anyone with better knowledge of GNUstep make have an idea of why 
this might happen or how to debug this further?


If you're not using -r, then I don't know what this .o will be.  The 
subproject thing is a source of constant pain because almost nothing 
other than GNUstep uses -r, so it tends to be horribly buggy.  It's 
supposed to take a load of .o files and generate a .o file that can be 
linked as if it were the original list of .o files.  Modern build 
systems just pass the list of .o files around.





There is a bug somewhere in the SEH support that I need to look for. 
 I suspect it is in clang - EH seems to fail with ARC and I think that 
it may be to do with the ARC calls not being correctly emitted in the 
funclet.  Dustin is planning on looking at some of the Clang funclet 
issues.


That’s good to know, thanks.

By the way, is libcxxrt needed on Windows for ObjC++ EH on Windows? 
Seems like WinObjC is not using it.



No, libcxxrt implements the Itanium C++ ABI.  On Windows, libobjc2 
supports the Visual Studio C++ ABI, so exceptions should interop with 
C++ libraries compiled with clang or MSVC.


David

Re: Building GNUstep for Windows using Clang

[Frederik Seiffert]

Thanks David. I made some progress with this setup, although it does feel like 
we’re a bit off the beaten track here (again)...

To get libobjc linking with the MinGW clang toolchain using LLD I had to create 
an import library (.dll.a) as outlined on the MinGW website:
http://www.mingw.org/wiki/CreateImportLibraries 


Basically I ran "dumpbin /exports objc.dll" to get the list of symbols, used 
that to manually create a objc.def file, and then ran "dlltool -d objc.def -l 
objc.dll.a". One thing I noticed is that this doesn’t seem to include global 
variables (e.g. _objc_unexpected_exception), so these won’t be picked up by 
GNUstep configure and thus native exception support won’t work.

In the end however I switched to using the llvm-mingw toolchain 
(https://github.com/mstorsjo/llvm-mingw 
), which defaults to LLD and directly 
picks up the objc.lib without the need for the import library (but also doesn’t 
seem allow linking global variables).

I also had to remove "OBJ_MERGE_CMD_FLAG" in config.make, as LLD doesn’t 
support the -r flag for incremental linking.

With this and a couple more configure flags I got Base to start compiling, but 
I’m now stuck at the Additions subproject failing to link because it seems to 
be missing all the necessary linker flags:

> clang -nostdlib-o ./obj/subproject.o 
> obj/Additions.obj/GSTypeEncoding.c.o ...
> lld-link: error: : undefined symbol: _mainCRTStartup
> lld-link: error: undefined symbol: _malloc
> lld-link: error: undefined symbol: __declspec(dllimport) _object_getClass
> ...


Does anyone with better knowledge of GNUstep make have an idea of why this 
might happen or how to debug this further?


> There is a bug somewhere in the SEH support that I need to look for.  I 
> suspect it is in clang - EH seems to fail with ARC and I think that it may be 
> to do with the ARC calls not being correctly emitted in the funclet.  Dustin 
> is planning on looking at some of the Clang funclet issues.


That’s good to know, thanks.

By the way, is libcxxrt needed on Windows for ObjC++ EH on Windows? Seems like 
WinObjC is not using it.

Thanks,
Frederik



> Am 25.02.2020 um 19:22 schrieb David Chisnall :
> 
> Hi,
> 
> 
> 
> On 25/02/2020 16:55, Frederik Seiffert wrote:
>> Hi all,
>> I’m trying to build GNUstep for Windows using Clang and the 2.0 runtime ABI 
>> in order to have support for ARC and blocks, but I’m having some issues and 
>> general questions.
>> I’ve successfully built libobjc2 (as well as libdispatch) in a Visual Studio 
>> command prompt using CMake and clang-cl as recommended 
>>  (i.e. not 
>> using MinGW). Should these DLLs link/work when building GNUstep using 
>> MSYS2/MinGW?
> 
> Yes, they're native Windows DLLs, they should work with any Windows program, 
> irrespective of what other DLLs it links (e.g. cygwin / msys). Note that the 
> v2 ABI now has native support for SEH, so if you want exception interop and 
> you want MinGW, you will need the toolchain variant that uses SEH, not 
> Itanium-style DWARF unwinding.
> 
> There is a bug somewhere in the SEH support that I need to look for.  I 
> suspect it is in clang - EH seems to fail with ARC and I think that it may be 
> to do with the ARC calls not being correctly emitted in the funclet.  Dustin 
> is planning on looking at some of the Clang funclet issues.
> 
>> For me, building GNUstep base in MSYS2/MinGW fails during configure. Using 
>> LLD it doesn’t find objc.dll ("unable to find library -lobjc"). Using Gold 
>> gives different errors ("unrecognized emulation i386pep" and others). I’ve 
>> verified the library search paths.
>> As I’m pretty new to MinGW on Windows any general pointers are also much 
>> appreciated.
> 
> To the best of my knowledge, WinObjC works in this configuration but I do not 
> know of anyone who has tried GNUstep (though I have no reason to suppose it 
> won't work).
> 
> Note that, on Windows, the linker does not need to find objc.dll, it needs to 
> find objc.lib.  You don't need objc.dll until you try to run a program (by 
> default, Windows searches in the same folder as the .exe, so to run the tests 
> CMake copies objc.dll into the Tests directory).  The Gold error looks as if 
> you may have a 32-bit version of the DLL and be using a 64-bit toolchain?  
> WinObjC is not 64-bit clean, but GNUstep should be.  The runtime builds in 
> either configuration (see the CI scripts - we build and test both in CI).
> 
> David
> 

Re: Building GNUstep for Windows using Clang

[David Chisnall]

Hi,



On 25/02/2020 16:55, Frederik Seiffert wrote:

Hi all,

I’m trying to build GNUstep for Windows using Clang and the 2.0 runtime 
ABI in order to have support for ARC and blocks, but I’m having some 
issues and general questions.


I’ve successfully built libobjc2 (as well as libdispatch) in a Visual 
Studio command prompt using CMake and clang-cl as recommended 
 (i.e. 
not using MinGW). Should these DLLs link/work when building GNUstep 
using MSYS2/MinGW?


Yes, they're native Windows DLLs, they should work with any Windows 
program, irrespective of what other DLLs it links (e.g. cygwin / msys). 
Note that the v2 ABI now has native support for SEH, so if you want 
exception interop and you want MinGW, you will need the toolchain 
variant that uses SEH, not Itanium-style DWARF unwinding.


There is a bug somewhere in the SEH support that I need to look for.  I 
suspect it is in clang - EH seems to fail with ARC and I think that it 
may be to do with the ARC calls not being correctly emitted in the 
funclet.  Dustin is planning on looking at some of the Clang funclet issues.


For me, building GNUstep base in MSYS2/MinGW fails during configure. 
Using LLD it doesn’t find objc.dll ("unable to find library -lobjc"). 
Using Gold gives different errors ("unrecognized emulation i386pep" and 
others). I’ve verified the library search paths.


As I’m pretty new to MinGW on Windows any general pointers are also much 
appreciated.


To the best of my knowledge, WinObjC works in this configuration but I 
do not know of anyone who has tried GNUstep (though I have no reason to 
suppose it won't work).


Note that, on Windows, the linker does not need to find objc.dll, it 
needs to find objc.lib.  You don't need objc.dll until you try to run a 
program (by default, Windows searches in the same folder as the .exe, so 
to run the tests CMake copies objc.dll into the Tests directory).  The 
Gold error looks as if you may have a 32-bit version of the DLL and be 
using a 64-bit toolchain?  WinObjC is not 64-bit clean, but GNUstep 
should be.  The runtime builds in either configuration (see the CI 
scripts - we build and test both in CI).


David

Building GNUstep for Windows using Clang

[Frederik Seiffert]

Hi all,

I’m trying to build GNUstep for Windows using Clang and the 2.0 runtime ABI in 
order to have support for ARC and blocks, but I’m having some issues and 
general questions.

I’ve successfully built libobjc2 (as well as libdispatch) in a Visual Studio 
command prompt using CMake and clang-cl as recommended 
 (i.e. not 
using MinGW). Should these DLLs link/work when building GNUstep using 
MSYS2/MinGW?

For me, building GNUstep base in MSYS2/MinGW fails during configure. Using LLD 
it doesn’t find objc.dll ("unable to find library -lobjc"). Using Gold gives 
different errors ("unrecognized emulation i386pep" and others). I’ve verified 
the library search paths.

As I’m pretty new to MinGW on Windows any general pointers are also much 
appreciated.

Thanks,
Frederik