Build latest gnustep on windows.

[bellabs]

Hello guys, I would like to ask if it is possible to build gnustep packages on 
windows, I have currently built libobjc2 on windows but can't build libs-base 
and libs-gui, I know I can use mingw but that is too old, I still want to build 
the latest gnustep libraries through the gnustep repository. Is this possible 
and how can I do it? Thanks! Best regards!

Re: GNUstep on Windows using Clang + MSVC ABI

[David Chisnall]

Thanks,

I’m taking next week off for Easter - hopefully I’ll have some time to look at 
both of these then.  I don’t think either is much work to fix, if I can easily 
set up the test environment.

David

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

Re: GNUstep on Windows using Clang + MSVC ABI

[Frederik Seiffert]

Hi David,

> Am 02.02.2021 um 12:29 schrieb David Chisnall :
> 
 lld-link: error: relocation against symbol in discarded section: 
 __start_.objcrt$SEL
 >>> referenced by C:\msys64\tmp\conftest-78a937.o:(.objc_init)
 This is reproducible when building a file that calls ObjC runtime 
 functions but doesn’t actually contain any ObjC code. Not sure if that’s 
 expected behavior or bug.
>>> 
>>> I think this is a bug, probably a clang bug (and probably my fault)
>> Should I open an LLVM issue for this?
> 
> Yes please.  There was an identical bug on ELF platforms, I may have failed 
> to fix it for Windows.

Here you go, please let me know if you need any other info:
https://bugs.llvm.org/show_bug.cgi?id=49681

>>> Awesome work, and it makes me much happier than trying to support MinGW.
>> Thank you, glad you like it! This is also exciting to us because it should 
>> e.g. allow us to use recent Windows technologies like the C++/WinRT language 
>> projection from ObjC++ which are not compatible with MinGW.
>> That being said, I would still very much like to get libobjc2 working with 
>> MinGW as well, as it would allow people currently using GNUstep with GCC in 
>> a MinGW environment to switch to Clang/libobjc2, should result in a more 
>> streamlined setup experience with all dependencies being available via MinGW 
>> packages and everything being built in one shell, and allow for existing 
>> MinGW-based software to be used.
>> I’ll try to get you those instructions for building LLVM with the MinGW 
>> patches in the next couple weeks.
> 
> I'll try to find some time to work on it.

I’ve finally found steps to reproduce the issues with MinGW using a "normal" 
(non-MinGW) LLDB build using a CMake toolchain file:
https://github.com/gnustep/libobjc2/pull/190#issuecomment-792676170

Hopefully that will be sufficient to look into these at some point.

Thanks!
Frederik

Re: GNUstep on Windows using Clang + MSVC ABI

[David Chisnall]

On 09/02/2021 16:20, Richard Frith-Macdonald wrote:




On 29 Jan 2021, at 16:28, David Chisnall  wrote:




  We have given up supporting MinGW for snmalloc and I am considering 
optionally supporting snmalloc for Objective-C object allocations since it is 
much faster than the system malloc on most platforms and is particularly good 
for fixed-size allocations as are common in Objective-C.  It would be a shame 
for this to be an everywhere-except-Windows thing.


Hi David,  I am giving snmalloc a try, but I'm wondering if (and why) you think 
it is actually better than mimalloc?


Well, I am biased as one of the authors of snmalloc...


As far as I can tell mimalloc ticks the general performance boxes and is 
admirably small (ie relatively simple code).
My interest is probably unusual in that it's primarity about maintaining a low 
memeory footprint for long running processes rather than about speed, so if 
snmalloc does a better job of avoiding fragmentation it would be very appealing.


I think mimalloc may do slightly better there.  We've adopted a lot of 
techniques from mimalloc and snmalloc was doing better than mimalloc 
last time we benchmarked.  The main difference between the two is that 
mimalloc frees directly back into the chunks using atomic operations, 
whereas snmalloc has a per-thread message queue that receives freed 
allocations, making the alloc and free operations entirely thread-local.


From my incredibly biased perspective:

Snmalloc is C++ with clean abstractions and using template parameters 
for a lot of the policy, which lets it both be very flexible and also 
compile down to tiny amounts of code (around 10 x86 instructions on the 
fast path for malloc).  Mimalloc is a C codebase.


Snmalloc has very clean architecture and platform abstractions.  We 
support a lot of both, including things like Haiku and running inside an 
SGX enclave with OpenEnclave.  The mimalloc OS abstraction layer has a 
lot of ifdefs interleaved with code:


https://github.com/microsoft/mimalloc/blob/master/src/os.c

The snmalloc equivalent is a platform-abstraction layer where we define 
a class for each platform.  Some of these are simple, for example 
OpenBSD just says to use the generic POSIX paths:


https://github.com/microsoft/snmalloc/blob/master/src/pal/pal_openbsd.h

Others are a bit more complex, with Windows providing its own codepaths:

https://github.com/microsoft/snmalloc/blob/master/src/pal/pal_windows.h

This abstraction layer if even sufficiently flexible that we can run 
inside the FreeBSD kernel with a handful of lines of code:


https://github.com/microsoft/snmalloc/blob/master/src/pal/pal_freebsd_kernel.h

We're also able to tune aggressively for size class.  If we know the 
size statically at compile time, or if we know it at free time, then we 
can be more accurate.  For Objective-C, I'd like to steal one bit form 
the isa pointer or refcount to see if we've use the extraBytes argument 
in class_createInstance and, if not, use the snmalloc API that doesn't 
need to look up the size.  This should save two instructions and one or 
two cache lines in the free path for most Objective-C dealloc operations.


We originally built snmalloc for Verona, where we expect to do a lot of 
allocations on one thread and the corresponding frees on another thread. 
 A lot of producer-consumer workloads have this characteristic and 
we've seen some incredible speedups reported for snmalloc over jemalloc 
on workloads like this and generally a modest improvement over mimalloc.


We are doing all of the CHERI temporal safety work on top of snmalloc. 
It is the building block for a fully memory-safe C/C++ environment.  As 
a side effect of this (and of the fact that it's a C++ codebase), we've 
been adding smart-pointer types for all of the different kinds of 
pointer (e.g. pointers into free lists, pointers handed out to the 
malloc consumer).  We are about to start a security audit and this makes 
if *far* easier for anyone to reason about the correctness of our code 
than in a C codebase.


We've also done a lot of work to support sandboxing within an address 
space with snmalloc.  This isn't quite finished but it gives us a very 
cheap way of allocating sandbox memory from either inside or outside a 
sandbox that can then be freed on the other side of the boundary 
cheaply.  This is important for the Verona foreign-code model, which is 
built entirely on top of sandboxing.


All of that said, mimalloc is also evolving and was the source of 
several ideas that improve performance.  My favourite was initialising 
the TLS for the allocator with a dummy allocator and then replacing it 
only on the slow paths.  This took an extra 'has malloc been 
initialised' branch of the fast path for every allocation.


Note that any comparison of total memory usage for snmalloc should be 
done with a system under memory pressure.  On *NIX platforms that 
support some variant of `MADV_FREE`, we use it in 

Re: GNUstep on Windows using Clang + MSVC ABI

[Richard Frith-Macdonald]

> On 29 Jan 2021, at 16:28, David Chisnall  wrote:
> 

>  We have given up supporting MinGW for snmalloc and I am considering 
> optionally supporting snmalloc for Objective-C object allocations since it is 
> much faster than the system malloc on most platforms and is particularly good 
> for fixed-size allocations as are common in Objective-C.  It would be a shame 
> for this to be an everywhere-except-Windows thing.

Hi David,  I am giving snmalloc a try, but I'm wondering if (and why) you think 
it is actually better than mimalloc?
As far as I can tell mimalloc ticks the general performance boxes and is 
admirably small (ie relatively simple code).
My interest is probably unusual in that it's primarity about maintaining a low 
memeory footprint for long running processes rather than about speed, so if 
snmalloc does a better job of avoiding fragmentation it would be very appealing.

Re: GNUstep on Windows using Clang + MSVC ABI

[David Chisnall]

On 01/02/2021 18:24, Frederik Seiffert wrote:

Sorry everyone, looks like my earlier draft got sent out prematurely...


Am 29.01.2021 um 17:28 schrieb David Chisnall 
mailto:gnus...@theravensnest.org>>:


ld -r is pretty flaky everywhere.  LLD wasn't going to implement it at 
all and GNUstep was one of only two consumers so I think it's fair to 
say that it's pretty likely that it will continue to be intermittently 
broken by various linker versions.  I personally like the concept but 
it's probably better to not depend on it anywhere.


Yeah, hopefully this change will resolve these issues once and for all.

That being said, Richard raised one *potential* issue with this change 
on GitHub, which is that it increases the length of the command that the 
linker is being called with, as now all subproject object files are 
passed directly to the linker. Hopefully OS command line limits are 
large enough these days so that this won’t be an issue in practice, but 
I’d still encourage everyone to try building their projects with the 
"clang-msvc-support" branch of tools-make.


I'm curious about this.  GNUstep projects have fairly short linker lines 
in comparison with a bunch of C++ projects.  I had a quick look at the 
systems I have runningL


 - FreeBSD limits it to 256 KiB on processes with limited kernel 
virtual address space, 512 KiB elsewhere.
 - Linux limits it to 128KiB statically but can return a larger number 
via sysconf depending on the system.  For me, that is around 2MiB.

 - Windows limits it to 32 KiB, though cmd.exe only handles 8 KiB.

Even with the 8KiB limit, you'd need a few hundred files on the linker 
invocation for this to be a problem unless you're giving long absolute 
paths for everything.




Have you tried with the bash.exe in C:\Windows\System32?


I briefly tried building in WSL today, and the main difference to using 
an MSYS2 shell is that Autoconf will consider it cross-compiling. This 
means that some config checks will not be run (because Autoconf will 
think that it can’t run the binaries), and we would need to provide a 
cross.config file with pre-determined results of these config files 
instead (just like when cross-compiling e.g. for Android). This is 
obviously more fragile.


But this kind of illustrates what I consider the biggest challenge with 
this setup: the need to install and jump between different shells in 
order to build the whole system (i.e. CMD for libobjc2, libdispatch, and 
probably others; Bash/MSYS2 for GNUstep).


I’m not sure if there’s an elegant solution to this. My current line of 
thinking is to create a project like tools-android (tools-windows?) with 
Batch + Bash scripts to build all dependencies and GNUstep in their 
respective environments.


Oh, sorry, wrong bash.  The one I was thinking of is actually installed 
for me as c:\Program Files\Git\git-bash.exe.  It's installed by the git 
package and gives you a Windows-native bash environment.  If the 
configure scripts just depend on bash, that ought to be sufficient.





Is the -fuse-ld=lld line required?  You get LLD installed when you 
install clang, so it's not very important, but the runtime and its 
tests, at least, also work with LINK.EXE (though you may have to 
disable incremental linking if it's on by default).


I did:

I tried using the MS linker (link.exe), but while that seems to 
generally work fine linking ObjC files, it throws up at some 
configure tests (specifically when testing "whether objc really 
works"). Using LLD works though, so one must run Make configure with 
LDFLAGS="-fuse-ld=lld".


This is reproducible simply by compiling config/config.objc.m from 
libs-base:


$ clang -o conftest.exe config/config.objc.m -I/c/GNUstep/x64/include 
-L/c/GNUstep/x64/lib -fobjc-runtime=gnustep-2.0 -lobjc
LINK : conftest.exe not found or not built by the last incremental link; 
performing full link
conftest-b38f3b.o : warning LNK4078: multiple '.CRT' sections found with 
different attributes (40400040)
libcmt.lib(initializers.obj) : warning LNK4254: section '.CRT' 
(C040) merged into '.rdata' (4040) with different attributes >

$ ./conftest.exe
Segmentation fault


This file appears to depend on objc-common.g, which looks like a 
generated file.  It probably only needs it for the root-class attribute 
(which only raises a warning if it's omitted, so isn't the end of the 
world).  Aside from that, the file looks like a bunch of the tests that 
we have in the libobjc2 repo, which pass in CI, so I'm not sure what's 
going on there.  Can you add -### to the clang command line and see how 
it compares to the same thing for the libobjc2 tests?




$ lldb conftest.exe
(lldb) r
Process 165928 stopped
* thread #1, stop reason = Exception 0xc005 encountered at address 
0x7ffce04d1048: Access violation reading location 0x

     frame #0: 0x7ffce04d1048 objc.dll`objc_msgSend + 40
objc.dll`objc_msgSend:
->  0x7ffce04d1048 <+40>: movl   (%r10), %r11d
     

Re: GNUstep on Windows using Clang + MSVC ABI

[Frederik Seiffert]

Sorry everyone, looks like my earlier draft got sent out prematurely...


> Am 29.01.2021 um 17:28 schrieb David Chisnall :
> 
> ld -r is pretty flaky everywhere.  LLD wasn't going to implement it at all 
> and GNUstep was one of only two consumers so I think it's fair to say that 
> it's pretty likely that it will continue to be intermittently broken by 
> various linker versions.  I personally like the concept but it's probably 
> better to not depend on it anywhere.

Yeah, hopefully this change will resolve these issues once and for all.

That being said, Richard raised one *potential* issue with this change on 
GitHub, which is that it increases the length of the command that the linker is 
being called with, as now all subproject object files are passed directly to 
the linker. Hopefully OS command line limits are large enough these days so 
that this won’t be an issue in practice, but I’d still encourage everyone to 
try building their projects with the "clang-msvc-support" branch of tools-make.


>> - Building
>> Building with this setup requires using a standard (non-MinGW) Clang that 
>> e.g. comes with Visual Studio or is available as pre-built binary from the 
>> LLVM website, and requires passing a host to configure like 
>> --host=x86_64-pc-windows. Invoking `clang -v` should show a target like 
>> "x86_64-pc-windows-msvc". It *might* be that using a MinGW Clang works too 
>> when invoked with --target x86_64-pc-windows-msvc, but I haven’t tried that.
> 
> The easiest way of installing clang on Windows is via Chocolatey: just run 
> `choco install llvm` once it's installed.  Choco is also the easiest way of 
> installing cmake and Ninja for building the runtime.

Thanks, good to know!


>> The build is best done in an MSYS2 shell that does not have any additional 
>> *-devel packages installed that might get picked up by configure. 
>> Alternatively --disable-xxx flags can be used to prevent these dependencies 
>> to be picked up.
> 
> Have you tried with the bash.exe in C:\Windows\System32?

I briefly tried building in WSL today, and the main difference to using an 
MSYS2 shell is that Autoconf will consider it cross-compiling. This means that 
some config checks will not be run (because Autoconf will think that it can’t 
run the binaries), and we would need to provide a cross.config file with 
pre-determined results of these config files instead (just like when 
cross-compiling e.g. for Android). This is obviously more fragile.

But this kind of illustrates what I consider the biggest challenge with this 
setup: the need to install and jump between different shells in order to build 
the whole system (i.e. CMD for libobjc2, libdispatch, and probably others; 
Bash/MSYS2 for GNUstep).

I’m not sure if there’s an elegant solution to this. My current line of 
thinking is to create a project like tools-android (tools-windows?) with Batch 
+ Bash scripts to build all dependencies and GNUstep in their respective 
environments.


> Is the -fuse-ld=lld line required?  You get LLD installed when you install 
> clang, so it's not very important, but the runtime and its tests, at least, 
> also work with LINK.EXE (though you may have to disable incremental linking 
> if it's on by default).

I did:

>> I tried using the MS linker (link.exe), but while that seems to generally 
>> work fine linking ObjC files, it throws up at some configure tests 
>> (specifically when testing "whether objc really works"). Using LLD works 
>> though, so one must run Make configure with LDFLAGS="-fuse-ld=lld".

This is reproducible simply by compiling config/config.objc.m from libs-base:

$ clang -o conftest.exe config/config.objc.m -I/c/GNUstep/x64/include 
-L/c/GNUstep/x64/lib -fobjc-runtime=gnustep-2.0 -lobjc
LINK : conftest.exe not found or not built by the last incremental link; 
performing full link
conftest-b38f3b.o : warning LNK4078: multiple '.CRT' sections found with 
different attributes (40400040)
libcmt.lib(initializers.obj) : warning LNK4254: section '.CRT' (C040) 
merged into '.rdata' (4040) with different attributes

$ ./conftest.exe
Segmentation fault

$ lldb conftest.exe
(lldb) r
Process 165928 stopped
* thread #1, stop reason = Exception 0xc005 encountered at address 
0x7ffce04d1048: Access violation reading location 0x
frame #0: 0x7ffce04d1048 objc.dll`objc_msgSend + 40
objc.dll`objc_msgSend:
->  0x7ffce04d1048 <+40>: movl   (%r10), %r11d
0x7ffce04d104b <+43>: cmpl   $0x8, %r11d
0x7ffce04d104f <+47>: je 0x7ffce04d1063; <+67>
0x7ffce04d1051 <+49>: cmpl   $0x0, %r11d

Let me know if I should open an issue for this somewhere, or if there’s 
something in config.objc.m that we should change to fix this.


>> For pthreads I have built http://www.sourceware.org/pthreads-win32/ 
>>  from source by invoking "nmake 
>> clean VC" in a VS native tools command prompt, and manually copied the 
>> headers (pthread.h, 

Re: GNUstep on Windows using Clang + MSVC ABI

[Frederik Seiffert]

>> - Linking subproject object files directly (instead of merging)
>> As David had suspected, merging the subproject object files turned out to be 
>> an issue: `ld -r` is not available on Windows, and using `ar cr` resulted in 
>> a subproject.o that didn’t contain all the symbols (I’m guessing because ar 
>> doesn't correctly handle PE/COFF files).
>> So I looked into how we could instead use the subproject object files 
>> directly when linking the project, and came up with this solution: instead 
>> of merging the object files into subproject.o, we simply write the list of 
>> object files to a subproject.txt file (in the same location), and read that 
>> to create SUBPROJECT_OBJ_FILES.
>> The change is pretty minimal and seems to work fine on all 
>> platforms/configurations in CI:
>> https://github.com/gnustep/tools-make/commit/434f957df0ad81b52a09e3f8c4a200734898b342
>> Given that this affects all platforms I’d appreciate everyone’s feedback on 
>> this, but given that issues with incremental linking with various setups has 
>> been talked about multiple times on the mailing list, I hope that this 
>> change will be an overall improvement.
> 
> ld -r is pretty flaky everywhere.  LLD wasn't going to implement it at all 
> and GNUstep was one of only two consumers so I think it's fair to say that 
> it's pretty likely that it will continue to be intermittently broken by 
> various linker versions.  I personally like the concept but it's probably 
> better to not depend on it anywhere.
> 
>> - Building
>> Building with this setup requires using a standard (non-MinGW) Clang that 
>> e.g. comes with Visual Studio or is available as pre-built binary from the 
>> LLVM website, and requires passing a host to configure like 
>> --host=x86_64-pc-windows. Invoking `clang -v` should show a target like 
>> "x86_64-pc-windows-msvc". It *might* be that using a MinGW Clang works too 
>> when invoked with --target x86_64-pc-windows-msvc, but I haven’t tried that.
> 
> The easiest way of installing clang on Windows is via Chocolatey: just run 
> `choco install llvm` once it's installed.  Choco is also the easiest way of 
> installing cmake and Ninja for building the runtime.

Thanks, good point!

>> The build is best done in an MSYS2 shell that does not have any additional 
>> *-devel packages installed that might get picked up by configure. 
>> Alternatively --disable-xxx flags can be used to prevent these dependencies 
>> to be picked up.
> 
> Have you tried with the bash.exe in C:\Windows\System32?



>> I’m currently building like this:
>> # tools-make
>> export CC=/C/LLVM/bin/clang
>> export CXX=/C/LLVM/bin/clang++
>> export OBJCXX=/C/LLVM/bin/clang++
>> ./configure --host=x86_64-pc-windows --with-library-combo=ng-gnu-gnu 
>> --with-runtime-abi=gnustep-2.0 --prefix=/c/GNUstep/x64 LDFLAGS="-fuse-ld=lld"
>> make install
> 
> Is the -fuse-ld=lld line required?  You get LLD installed when you install 
> clang, so it's not very important, but the runtime and its tests, at least, 
> also work with LINK.EXE (though you may have to disable incremental linking 
> if it's on by default).

Yeah:

>> I tried using the MS linker (link.exe), but while that seems to generally 
>> work fine linking ObjC files, it throws up at some configure tests 
>> (specifically when testing "whether objc really works"). Using LLD works 
>> though, so one must run Make configure with LDFLAGS="-fuse-ld=lld".





>> # libs-base
>> . /c/GNUstep/x64/share/GNUstep/Makefiles/GNUstep.sh
>> ./configure --host=x86_64-pc-windows --disable-iconv --disable-tls 
>> --disable-icu --disable-xml
>> make -j12 install
>> - Dependencies
>> While most dependencies should be available via NuGet, I have not been able 
>> to figure out yet how we might integrate NuGet packages into the build 
>> process. Downloading the packages results in individual folders per package 
>> with deeply nested folder structures containing the libraries for different 
>> architectures, debug/release targets, and Visual Studio versions.
>> For now I have manually copied the headers and libffi.lib import library 
>> (renamed to ffi.lib) from the libffi package, and the libffi.dll from the 
>> libffi.redist package.
>> For pthreads I have built http://www.sourceware.org/pthreads-win32/ from 
>> source by invoking "nmake clean VC" in a VS native tools command prompt, and 
>> manually copied the headers (pthread.h, sched.h, semaphore.h), 
>> pthreadVC2.lib (renamed to pthread.lib), and phtreadVC2.dll.
> 
> At some point it would be nice to lose this dependency.  I don't know how 
> much the attitude to C++ in GNUstep has changed recently, but C++11 now has a 
> nice set of threading abstractions that provide everything that NSThread, 
> NSLock and friends need.  If we use those instead of pthreads then we'd have 
> something that worked on any platform with a C++11 implementation (Linux, 
> Windows, Fuschia, Haiku, and so on).
> 
> 
>> I haven’t build with any other dependencies so far 

Re: GNUstep on Windows using Clang + MSVC ABI

[David Chisnall]

On 29/01/2021 16:03, Frederik Seiffert wrote:

Good news everyone: I’ve successfully built Base on Windows with Clang, 
libobjc2, and the MSVC ABI. This results in lib, DLL, and PDB files that should 
be usable in any Windows app without using the MinGW toolchain.


*Very* nice!



I’ve opened the following pull requests with the required changes:

- tools-make: https://github.com/gnustep/tools-make/pull/14
- libs-base: https://github.com/gnustep/libs-base/pull/168

A couple of notes:


- Linking subproject object files directly (instead of merging)

As David had suspected, merging the subproject object files turned out to be an 
issue: `ld -r` is not available on Windows, and using `ar cr` resulted in a 
subproject.o that didn’t contain all the symbols (I’m guessing because ar 
doesn't correctly handle PE/COFF files).

So I looked into how we could instead use the subproject object files directly 
when linking the project, and came up with this solution: instead of merging 
the object files into subproject.o, we simply write the list of object files to 
a subproject.txt file (in the same location), and read that to create 
SUBPROJECT_OBJ_FILES.

The change is pretty minimal and seems to work fine on all 
platforms/configurations in CI:
https://github.com/gnustep/tools-make/commit/434f957df0ad81b52a09e3f8c4a200734898b342

Given that this affects all platforms I’d appreciate everyone’s feedback on 
this, but given that issues with incremental linking with various setups has 
been talked about multiple times on the mailing list, I hope that this change 
will be an overall improvement.


ld -r is pretty flaky everywhere.  LLD wasn't going to implement it at 
all and GNUstep was one of only two consumers so I think it's fair to 
say that it's pretty likely that it will continue to be intermittently 
broken by various linker versions.  I personally like the concept but 
it's probably better to not depend on it anywhere.





- Building

Building with this setup requires using a standard (non-MinGW) Clang that e.g. comes with 
Visual Studio or is available as pre-built binary from the LLVM website, and requires 
passing a host to configure like --host=x86_64-pc-windows. Invoking `clang -v` should 
show a target like "x86_64-pc-windows-msvc". It *might* be that using a MinGW 
Clang works too when invoked with --target x86_64-pc-windows-msvc, but I haven’t tried 
that.


The easiest way of installing clang on Windows is via Chocolatey: just 
run `choco install llvm` once it's installed.  Choco is also the easiest 
way of installing cmake and Ninja for building the runtime.



The build is best done in an MSYS2 shell that does not have any additional 
*-devel packages installed that might get picked up by configure. Alternatively 
--disable-xxx flags can be used to prevent these dependencies to be picked up.


Have you tried with the bash.exe in C:\Windows\System32?



I’m currently building like this:

# tools-make
export CC=/C/LLVM/bin/clang
export CXX=/C/LLVM/bin/clang++
export OBJCXX=/C/LLVM/bin/clang++
./configure --host=x86_64-pc-windows --with-library-combo=ng-gnu-gnu 
--with-runtime-abi=gnustep-2.0 --prefix=/c/GNUstep/x64 LDFLAGS="-fuse-ld=lld"
make install


Is the -fuse-ld=lld line required?  You get LLD installed when you 
install clang, so it's not very important, but the runtime and its 
tests, at least, also work with LINK.EXE (though you may have to disable 
incremental linking if it's on by default).




# libs-base
. /c/GNUstep/x64/share/GNUstep/Makefiles/GNUstep.sh
./configure --host=x86_64-pc-windows --disable-iconv --disable-tls 
--disable-icu --disable-xml
make -j12 install


- Dependencies

While most dependencies should be available via NuGet, I have not been able to 
figure out yet how we might integrate NuGet packages into the build process. 
Downloading the packages results in individual folders per package with deeply 
nested folder structures containing the libraries for different architectures, 
debug/release targets, and Visual Studio versions.

For now I have manually copied the headers and libffi.lib import library 
(renamed to ffi.lib) from the libffi package, and the libffi.dll from the 
libffi.redist package.

For pthreads I have built http://www.sourceware.org/pthreads-win32/ from source by 
invoking "nmake clean VC" in a VS native tools command prompt, and manually 
copied the headers (pthread.h, sched.h, semaphore.h), pthreadVC2.lib (renamed to 
pthread.lib), and phtreadVC2.dll.


At some point it would be nice to lose this dependency.  I don't know 
how much the attitude to C++ in GNUstep has changed recently, but C++11 
now has a nice set of threading abstractions that provide everything 
that NSThread, NSLock and friends need.  If we use those instead of 
pthreads then we'd have something that worked on any platform with a 
C++11 implementation (Linux, Windows, Fuschia, Haiku, and so on).




I haven’t build with any other dependencies so far but that will be my next 

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]

crt$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]

or: 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,

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 
> <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 
> <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 
<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 
<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 
<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 
>> <https://github.com/gnustep/libobjc2/blob/master/README.windows> (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 
<https://github.com/gnustep/libobjc2/blob/master/README.windows> (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 
<https://github.com/gnustep/libobjc2/blob/master/README.windows> (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

Re: GNUStep on Windows

[Vincent Richomme]

On Sun, 24 Jan 2010 12:53:48 +0100, Vincent Richomme
foru...@smartmobili.com wrote:
 On Sun, 24 Jan 2010 12:43:36 +0100, Riccardo Mottola mul...@ngi.it
 wrote:
 Hi there,
 
 Vincent R. wrote:
 When will you switch to llvm on windows platform ?
 I can see from website that for now you are releasing a solution based
 on
 msys/mingw-4.4
 and could it be possible to use a msys/llvm alternative ?
 Would it work ?

 We are not going to switch any time soon.  I don't think GNUstep is 
 going to switch anytime soon on other targets either. GCC is
currently
 
 our preferred compiler. David Chisnall is doing some excellent and 
 interesting work in getting llvm and also the libobjc2 runtime to work 
 with GNUstep.
 
 Our goal is to support llvm+lobobjc2 as a second alternative.
 
 Supporting llvm on windows could be possible I gues, depending on how 
 good llvm works with the msys environment. But currently I think nobody

 is working on that directly, David doesn't work on windows and the 
 developers currently active on Windows have their hands full fixing 
 other problems, like theming and backend issues.
 
 Ok so it means I can make some testing in my spare time and try to do
some
 feedback
 

Just for information I was able to compile clang with msys/mingw (but I
had to 
recompile toolchain from mingw-w64 project because with original mingw I
got a memory
exhausted error from the linker).
Now mingw is trying to fix some bugs and once they have finished I would
be tempted
to create an installer with toolchain from mingw-w64.
It would simplify process for people wanting to test on windows.




___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: GNUStep on Windows

[David Chisnall]

On 28 Jan 2010, at 16:41, Vincent Richomme wrote:

 Just for information I was able to compile clang with msys/mingw (but I
 had to 
 recompile toolchain from mingw-w64 project because with original mingw I
 got a memory
 exhausted error from the linker).

Did you do a Release-Asserts build?  For me, the linker uses about 500MB of RAM 
linking a debug build, but a small fraction of that linking a Release-Asserts 
build (it also takes about 30 seconds instead of about 5 minutes).

David

-- Sent from my Difference Engine





___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: GNUStep on Windows

[Riccardo Mottola]

Hi there,

Vincent R. wrote:

When will you switch to llvm on windows platform ?
I can see from website that for now you are releasing a solution based on
msys/mingw-4.4
and could it be possible to use a msys/llvm alternative ?
Would it work ?
   
We are not going to switch any time soon.  I don't think GNUstep is 
going to switch anytime soon on other targets either. GCC is currently 
our preferred compiler. David Chisnall is doing some excellent and 
interesting work in getting llvm and also the libobjc2 runtime to work 
with GNUstep.


Our goal is to support llvm+lobobjc2 as a second alternative.

Supporting llvm on windows could be possible I gues, depending on how 
good llvm works with the msys environment. But currently I think nobody 
is working on that directly, David doesn't work on windows and the 
developers currently active on Windows have their hands full fixing 
other problems, like theming and backend issues.


Riccardo


___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: GNUStep on Windows

[Vincent Richomme]

On Sun, 24 Jan 2010 12:43:36 +0100, Riccardo Mottola mul...@ngi.it
wrote:
 Hi there,
 
 Vincent R. wrote:
 When will you switch to llvm on windows platform ?
 I can see from website that for now you are releasing a solution based
on
 msys/mingw-4.4
 and could it be possible to use a msys/llvm alternative ?
 Would it work ?

 We are not going to switch any time soon.  I don't think GNUstep is 
 going to switch anytime soon on other targets either. GCC is currently

 our preferred compiler. David Chisnall is doing some excellent and 
 interesting work in getting llvm and also the libobjc2 runtime to work 
 with GNUstep.
 
 Our goal is to support llvm+lobobjc2 as a second alternative.
 
 Supporting llvm on windows could be possible I gues, depending on how 
 good llvm works with the msys environment. But currently I think nobody 
 is working on that directly, David doesn't work on windows and the 
 developers currently active on Windows have their hands full fixing 
 other problems, like theming and backend issues.

Ok so it means I can make some testing in my spare time and try to do some
feedback


___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

GNUStep on Windows

[Vincent R.]

Hi,

When will you switch to llvm on windows platform ?
I can see from website that for now you are releasing a solution based on
msys/mingw-4.4
and could it be possible to use a msys/llvm alternative ?
Would it work ?



___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: GNUStep on Windows

[David Chisnall]

On 22 Jan 2010, at 16:07, Vincent R. wrote:

 Hi,
 
 When will you switch to llvm on windows platform ?
 I can see from website that for now you are releasing a solution based on
 msys/mingw-4.4
 and could it be possible to use a msys/llvm alternative ?
 Would it work ?

Clang will probably compile GNUstep on Windows, however:

1) I am the person who maintains GNU runtime code generation in clang, and
2) I don't have a Windows machine.

That means that clang's Objective-C support on Windows is basically untested.  
If people want to test it and send me bug reports, then I'm happy to fix 
things, but so far I have not heard from anyone trying it.

Bottom line: People who care about a platform being supported need to be 
willing to test things on that platform.

David

-- Sent from my Difference Engine


___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: GNUStep on Windows

[Vincent R.]

On Fri, 22 Jan 2010 16:12:18 +, David Chisnall thera...@sucs.org
wrote:
 On 22 Jan 2010, at 16:07, Vincent R. wrote:
 
 Hi,
 
 When will you switch to llvm on windows platform ?
 I can see from website that for now you are releasing a solution based
on
 msys/mingw-4.4
 and could it be possible to use a msys/llvm alternative ?
 Would it work ?
 
 Clang will probably compile GNUstep on Windows, however:
 
 1) I am the person who maintains GNU runtime code generation in clang,
and
OK


 2) I don't have a Windows machine.
 
Impressive! and you can live like that ? ;-) 


 That means that clang's Objective-C support on Windows is basically
 untested.  If people want to test it and send me bug reports, then I'm
 happy to fix things, but so far I have not heard from anyone trying it.
 
 Bottom line: People who care about a platform being supported need to be
 willing to test things on that platform.
 
Ok I will test asap but could you please tell me something before I test,
is it 
possible to use LLVM/clang to link with a msvc import lib ? Same question
for mingw.



___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: GNUStep on Windows

[David Chisnall]

On 22 Jan 2010, at 17:22, Vincent R. wrote:

 Ok I will test asap but could you please tell me something before I test,
 is it 
 possible to use LLVM/clang to link with a msvc import lib ? Same question
 for mingw.


I've no idea.  Clang has some Visual Studio support, and can interact with the 
MS toolchain to a limited degree.  It still needs the GNU assembler, and it 
uses the platform's linker.

David

-- Sent from my Difference Engine





___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Linking error with OpenGL and GNUstep on windows

[peter.vullings]

Hi all,

Please be patient with me :) I have done a lot of windows programming in the
past in a variety of IDEs and languages, however I am fairly new to the
command line way of doing things (gcc, makefiles etc).

I have just installed GNUstep and have it running under windows.  I have
created my first two hello world apps - one console and one windowed,
working beautifully.

Now I have modified the windowed app with an OpenGL view (with a custom
class based on NSOpenGLView) cobbled together from examples found.  I have
finally ironed out all the compiling errors (missing headers etc), but still
have the following error when running make.  I assume i have to specify the
OpenGL library in the makefile somehow?

[code: make]
Making all for app HelloWorld...
  Compiling file OGLView.m ...
  Linking app HelloWorld
Creating library file: ./HelloWorld.app/ ./HellowWorld.exe.a
./obj/OGLView.m.o: in function 'drawArcWithDepth':
OGLView.m:24: undefined reference to '_glverte...@12'
OGLView.m:25: undefined reference to '_glverte...@12'
etc...
[/code]

Additional 'undefined references' include:
_glnorma...@12
_glbe...@4
_gl...@0
_glcolo...@12
_glclearco...@16
_glrota...@16
etc, etc.

My makefile is:
[code: GNUmakefile]
include $(GNUSTEP_MAKEFILES)/common.make

APP_NAME = HelloWorld
HelloWorld_HEADERS = AppController.h OGLView.h
HelloWorld_OBJC_FILES = main.m AppController.m OGLView.m
HelloWorld_RESOURCE_FILES = HelloWorldInfo.plist

include $(GNUSTEP_MAKEFILES)/application.make
[/code]

Any help is much appreciated as to how I can link to the OpenGL libraries
(if this is what the problem is).  If at all possible (if I had the choice)
I would like to link to the OpenGL ES 1.1 libraries.

Regards,
Peter


-- 
View this message in context: 
http://www.nabble.com/Linking-error-with-OpenGL-and-GNUstep-on-windows-tp21512973p21512973.html
Sent from the GNUstep - Dev mailing list archive at Nabble.com.



___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: Linking error with OpenGL and GNUstep on windows

[peter.vullings]

Hi all, got it to compile by adding the following line to the GNUmakefile:
HelloWorld_TOOL_LIBS += -lopengl32

Follow on question - is there something similar to libopengl32 for OpenGL|ES
1.1?


peter.vullings wrote:
 
 I assume i have to specify the OpenGL library in the makefile somehow?
 

-- 
View this message in context: 
http://www.nabble.com/Linking-error-with-OpenGL-and-GNUstep-on-windows-tp21512973p21514830.html
Sent from the GNUstep - Dev mailing list archive at Nabble.com.



___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: GNUstep on Windows (XP, Vista) 64 bits?

[Adam Fedor]

I've never tried these on w64, so I don't know.  It may be just a  
problem cross-compiling - you may need to fix up the configure/make  
scripts or it may be easy to compile them natively.


On Mar 25, 2008, at 10:47 AM, Yury Mishchenko wrote:

I used code from http://sourceforge.net/projects/mingw-w64/ to build  
a cross compiler (build system Win32)
I wanted to cross compile the GNUstep base but it looked like  
required libraries (libxml and libffcall) were not ported to Win64  
(x86_64-pc-mingw32).

At least I could not cross compile them to x86_64-pc-mingw32.
Maybe I do something wrong? Need those libraries to be ported?
From: Adam Fedor [mailto:[EMAIL PROTECTED]
Sent: Wednesday, March 05, 2008 4:45 PM
To: Yury Mishchenko
Cc: gnustep-dev@gnu.org
Subject: Re: GNUstep on Windows (XP, Vista) 64 bits?


On Mar 4, 2008, at 8:19 AM, Yury Mishchenko wrote:


Hi,
Does anybody know whether there is anything planned/done for running  
GNUstep on Windows 64 bits?
It seems there is something ongoing by I can not figure in what  
state it is.

Could anyone clarify the situation?


GNUstep doesn't work with the standard MinGW installation.  However,  
it should work, if you can compile MinGW as 64-bit libraries.  I  
haven't checked recently, but you need to make various patches to  
the compiler and other things to get this to work.

___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev


___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: GNUstep on Windows (XP, Vista) 64 bits?

[Adam Fedor]

On Mar 4, 2008, at 8:19 AM, Yury Mishchenko wrote:


Hi,
Does anybody know whether there is anything planned/done for running  
GNUstep on Windows 64 bits?
It seems there is something ongoing by I can not figure in what  
state it is.

Could anyone clarify the situation?



GNUstep doesn't work with the standard MinGW installation.  However,  
it should work, if you can compile MinGW as 64-bit libraries.  I  
haven't checked recently, but you need to make various patches to the  
compiler and other things to get this to work. ___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: gnustep on windows

[Xavier Glattard]

Paul Fox paulfox at paxway.com writes:

 Ok, I've downloaded the patch and worked on merging the changes in 
 CairoContext.m with the latest version (so pdf and ps output would still 
 work) as well as cleaning up a few minor style things. It now compiles, 
 but I get garbage when I try to run Gorm, and the GNUstep test appears 
 to freeze. I can't find obvious errors in my modification, so is there 
 some code somewhere else that's a problem? Here's the modified 
 CairoContext.m: http://www.mediafire.com/?n2s1stkmu9c
 and here's the result I get for Gorm: http://www.mediafire.com/?ianwbjdsdxs
 
 Does anyone have any suggestions?
 
 Paul

I just posted my code to the svn repos.
There is no real difference between your code and mine so we should get the same
results.

First : the transparency in bitmap images is not render properly.

Gorm :
http://amstradstuff.free.fr/GNUstep/win32cairo-gorm.png

The application is almost Ok. Only the Application window can not be used (the
black box on the screen shot)

I get many error msgs :

2008-03-04 13:15:01.842 Gorm[1964] Error while setting font matrix: out of 
memory
2008-03-04 13:15:01.852 Gorm[1964] Error while setting font matrix: out of 
memory
2008-03-04 13:15:01.942 Gorm[1964] Cairo status 'out of memory' in copy
2008-03-04 13:15:01.942 Gorm[1964] Cairo status 'out of memory' in copy
(...)
_cairo_win32_surface_set_clip_region: Descripteur non valide
_cairo_win32_surface_set_clip_region: Descripteur non valide
_cairo_win32_surface_set_clip_region: Descripteur non valide
_cairo_win32_surface_set_clip_region: Descripteur non valide
(...)
_cai2008-03-04 13:15:02.573 Gorm[1964] Error while setting font matrix: out of
memory
2008-03-04 13:15:02.573 Gorm[1964] Cairo status 'out of memory' in copy
2008-03-04 13:15:02.623 Gorm[1964] Error while setting font matrix: out of 
memory
2008-03-04 13:15:02.673 Gorm[1964] Error while setting font matrix: out of 
memory
(...)
2008-03-04 13:15:31.555 Gorm[1964] Error while setting font matrix: out of 
memory
ro_win32_surface_set_clip_region: Descripteur non valide
_cairo_win32_surface_set_clip_region: Descripteur non valide
_cairo_win32_surface_set_clip_region: Descripteur non valide
(...)

examples/Calculator : fine!

examples/Ink : fine!

examples/GSTest: most tests look Ok. NSViewAnimation-test crashes

I probably had the same results one years ago when i write the code.

I use cairo-1.4.14. My system : XP sp2

I wont work on this code before long. Feel free to hack this stuff :-)

Regards

Xavier






___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

gnustep on windows

[Paul Fox]

Ok, I've downloaded the patch and worked on merging the changes in 
CairoContext.m with the latest version (so pdf and ps output would still 
work) as well as cleaning up a few minor style things. It now compiles, 
but I get garbage when I try to run Gorm, and the GNUstep test appears 
to freeze. I can't find obvious errors in my modification, so is there 
some code somewhere else that's a problem? Here's the modified 
CairoContext.m: http://www.mediafire.com/?n2s1stkmu9c

and here's the result I get for Gorm: http://www.mediafire.com/?ianwbjdsdxs

Does anyone have any suggestions?

Paul



___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: gnustep on windows

[Paul Fox]

I just made some small changes in CairoContext.m
The zip file has been updated :
http://amstradstuff.free.fr/GNUstep/back-win32cairo.zip


Oops... looks like someone beat me to the punch. Great minds think 
alike, eh?


At any rate, I showed my results, and they aren't ideal. Does anyone 
have ideas?


Paul


___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: gnustep on windows

[Fred Kiefer]

Xavier Glattard wrote:
 I just made some small changes in CairoContext.m
 The zip file has been updated :
   http://amstradstuff.free.fr/GNUstep/back-win32cairo.zip
 
 Cairo backend and Cairo/Glitz backend can be build and run.
 With Calculator and Gorm:
   Cairo backend : 
 Text is Ok. Most bitmaps are ugly (transparency ?).
 With Gorm : many error log from GNUstep and Cairo. A black window.
   Glitz backend :
 everything is display in ONE window...
 
 I can put all this highly experimental stuff in the repository 
 if you thing that may be useful.
 

Just before you put it into SVN, could you please rewrite all the
licenses to be LGPL 3 and remove the Windows line endings from the headers?

Otherwise putting that code into SVN would be fine by me. Perhaps we
should add a big warning that it is unsupported and currently not working?


___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: gnustep on windows

[Fred Kiefer]

Christopher Armstrong wrote:
 Hi Paul
 
 Thought I'd chime in on the conversation :-).
  
 When programming with GNUstep you will be working against the GNUstep
 drawing API, not cairo or GDI. It is true that the implementation of
 this API for cairo is more complete, but even that may be changed.
 Oh, I know, but it doesn't make a lot of sense to maintain multiple
 backends when one will serve. Also GDI vector drawing looks ugly and
 Cairo looks nice... so I'd prefer to use Cairo. That way, my results
 should be pretty much the same on Windows and Linux. 
 
 I agree with using cairo. From what I can ascertain, they call GDI where
 possible and do custom drawing where GDI fails to support it -
 effectively a GDI backend of their own. If we can just pass a HDC to
 cairo and let it do the drawing, this means we can take advantage of
 their improvements to *their* GDI backend. 
 
 They're API has already been integrated with GNUstep at one point so it
 shouldn't be difficult to do it again.
 
 You might be talking about [Camaelon][1] (spelling is important).
 I have read a bit about Camaelon, but my understanding is that it's a
 theming engine rather than an API. I also have the impression that it's a
 bit slow because it's pixmap-based. I was looking at the Narcissus theme
 engine, but the developer made the comment that his patch to NSScroller
 to enable theming of the scroller was rejected because it didn't conform
 to the theming API that had been planned. I haven't really been able to
 find out much about this API, however. 
 
 I'm not sure what theming API had been planned, but I'm sure if you were
 to write one it would be accepted. I think there is alot of ideas
 floating around but none have been really fleshed out as code yet. The
 current API and theming code in GNUstep itself suggests using a grid of
 pixmaps for each UI element that are stretched and tiled onto the GUI.
 
 I have been toying with theming on and off for the past couple of years.
 I haven't really got that far, but I'm some way to developing an API. I
 have been trying to integrate Windows theming into GNUstep, which isn't
 all that hard really, its just trying to understand the MS documentation
 and work out the best way to match it to GNUstep. The hard part is doing
 the Windows 2000 theming because Microsoft doesn't store this as a
 theme, but rather requires you to paint it yourself.
 
 Please find attached what I have at the moment (be warned: it is a bit
 messy and incomplete). Your free to play with it or pitch any questions
 you have about it to me.
 

Just one comment on this impressive patch. You seem to override some
system colour methods on NSColor to use the Windows colour settings in
GNUstep. This is the wrong approach to do so. You should be generating a
new system colour list and send that via the themeDidActivate
notification of your theme. That way even system colours loaded from a
NIB file would be displayed correctly.

All you have to do is create the list:

list = [[NSColorList alloc] initWithName: @System];

and to add your colours to it:

[list setColor: Win32ToGSColor(COLOR_WINDOWTEXT)
forKey: @controlTextColor];


Cheers,
Fred



___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: gnustep on windows

[Richard Frith-Macdonald]

On 3 Mar 2008, at 23:41, Christopher Armstrong wrote:


Hi Fred

On 04/03/2008, at 7:06 AM, Fred Kiefer wrote:


Just one comment on this impressive patch. You seem to override some
system colour methods on NSColor to use the Windows colour settings  
in
GNUstep. This is the wrong approach to do so. You should be  
generating a

new system colour list and send that via the themeDidActivate
notification of your theme. That way even system colours loaded  
from a

NIB file would be displayed correctly.


All you have to do is create the list:

list = [[NSColorList alloc] initWithName: @System];

and to add your colours to it:

[list setColor: Win32ToGSColor(COLOR_WINDOWTEXT)
forKey: @controlTextColor];


Thanks, this looks like just what I was looking for. I know what I  
was doing was a hack but I wasn't sure about the way around it.


Also, I'm not sure what patch version you have but I was thinking of  
introducing another theme notification called GSThemeDidUpdate or  
the like, which is sent the first time a theme is updated, or by a  
theme whenever it changes its appearance and requires widgets to be  
updated. Another alternative is sending GSThemeDidActivate every  
time a theme needs to update its appearance. This is even if the  
theme itself does not change but needs to change what it looks like.  
It is necessary, because Windows uxtheme (or a similar adapted theme  
engine) could undergo a theme change, and we would need to update  
our appearance.


I think you should use GSThemeDidActivate when windows changes it's  
theme ... because you are activating a new theme (windows has changed  
to a new theme).
The notification is meant to mean that a them has become active, not  
that a theme engine has changed (for instance, pixmap based themes are  
likely to all use the same theme software, just different images).
Essentially this notification tells the gui controls that they should  
refresh any cached theme information and redraw themselves ... having  
two notifications doing the same thing would seem more trouble than  
it's worth.




___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: gnustep on windows

[Paul Fox]

When programming with GNUstep you will be working against the GNUstep
drawing API, not cairo or GDI. It is true that the implementation of
this API for cairo is more complete, but even that may be changed.


Oh, I know, but it doesn't make a lot of sense to maintain multiple backends when one will serve. Also GDI vector drawing looks ugly and Cairo looks nice... so I'd prefer to use Cairo. That way, my results should be pretty much the same on Windows and Linux. 


You might be talking about [Camaelon][1] (spelling is important).


I have read a bit about Camaelon, but my understanding is that it's a theming engine rather than an API. I also have the impression that it's a bit slow because it's pixmap-based. I was looking at the Narcissus theme engine, but the developer made the comment that his patch to NSScroller to enable theming of the scroller was rejected because it didn't conform to the theming API that had been planned. I haven't really been able to find out much about this API, however. 




___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: gnustep on windows

[Xavier Glattard]

Hello

I just made some small changes in CairoContext.m
The zip file has been updated :
  http://amstradstuff.free.fr/GNUstep/back-win32cairo.zip

Cairo backend and Cairo/Glitz backend can be build and run.
With Calculator and Gorm:
  Cairo backend : 
Text is Ok. Most bitmaps are ugly (transparency ?).
With Gorm : many error log from GNUstep and Cairo. A black window.
  Glitz backend :
everything is display in ONE window...

I can put all this highly experimental stuff in the repository 
if you thing that may be useful.

Regards

Xavier




___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: gnustep on windows

[Richard Frith-Macdonald]

On 1 Mar 2008, at 17:18, Paul Fox wrote:


When programming with GNUstep you will be working against the GNUstep
drawing API, not cairo or GDI. It is true that the implementation of
this API for cairo is more complete, but even that may be changed.


Oh, I know, but it doesn't make a lot of sense to maintain multiple  
backends when one will serve. Also GDI vector drawing looks ugly and  
Cairo looks nice... so I'd prefer to use Cairo. That way, my results  
should be pretty much the same on Windows and Linux.

You might be talking about [Camaelon][1] (spelling is important).


I have read a bit about Camaelon, but my understanding is that it's  
a theming engine rather than an API. I also have the impression that  
it's a bit slow because it's pixmap-based. I was looking at the  
Narcissus theme engine, but the developer made the comment that his  
patch to NSScroller to enable theming of the scroller was rejected  
because it didn't conform to the theming API that had been planned.  
I haven't really been able to find out much about this API, however.


Look at GSTheme.[hm] in the gui library and the Thematic developer app.

The theming stuff is *very* rudimentary so far, but the core framework  
is there for themes to be loaded  and changed at runtime.


A theme is a loadable bundle with resources and (possibly) code.

The code is in the GSTheme class (or a subclass of it).

The idea is that the controls in the gui should eventually draw  
themselves entirely in terms of methods in the GSTheme class (most of  
which are yet to be defined) ... and that those methods can draw  
things in terms of pixmaps (code already in place to support tiling of  
pixmaps etc to draw frames/rectangles) or can draw directly (when the  
theme developer provides a subclass of GSTheme in their theme bundle).


So ... given that the theming API is not yet defined, anyone  
interested has a good opportunity to shape that API.
The Narcissus theme patch was not really rejected ... rather the  
author was asked to rework it to fit in with the GSTheme concept ...  
ie the drawing code should be added to GSTheme, and NSScroller  
modified to call the new methods which are added.  Any API added  
should be well designed ... so that it can easily be implemented using  
pixmaps as well as using hard-coded methods in a GSTheme subclass.


So ... the ideal way to add some theming would be ...

1. Design a new method/methods for GSTheme ... add them to the headers.
2. Alter the gui controls to use the new methods
3a. Implement them in the GSTheme base class in terms of using pixmap  
images with the existing methods
3b. Write a GSTheme subclass to implement the new methods with hard- 
coded drawing rather than pixmaps for performance

4. Modify Thematic to support the new stuff.




___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: gnustep on windows

[Fred Kiefer]

Xavier Glattard wrote:
 Hello
 
 Some months (a year ?) ago i tried to write a Cairo backend for windows.
 You can get the files there :
 http://amstradstuff.free.fr/GNUstep/back-win32cairo.zip
 Put then in Source/cairo directory
 
 Achtung : two files will be overwritten !!
 
 I'm not sure they still can be build as cairo backend has been changed 
 but they may be a first step.
 You will need FreeType and fontconfig.
 

This looks rather nice and it shows that I was wrong, there is a bit
more X specific code inside of CairoContext. Did you get this code to
work? I remember that there was also some complicated extension needed
for the configure script, wasn't it?

And you did forget to add the header files :-)

Cheers,
Fred


___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: gnustep on windows

[Paul Fox]

There shouldn't be any X dependencies in the cairo backend code apart
from the X surfaces of course. You should be able to provide your own MS
Windows surface and use that. This gets a bit harder on the make file
level, here our config scripts currently only support the cairo backend
for X11.
There is one other problem I see, although freetype is available for
Windows you will most likely want to use native font support. For this
you will need to implement your own classes or port the ones from the
the winlib backend.
Out of curiosity, why do you want to use cairo on Windows and not the
native window interface (or one based on GDI+)?


Why Cairo? Mainly because it gives me a fairly nice graphics library that's 
cross-platform. For fancy graphics, Cairo gives a consistent appearance across 
platforms, allows me to ignore platform when coding for the most part, and is 
much nicer looking than GDI. I'm really still exploring what's possible here, 
and it appears that Cairo is the most potentially capable backend.

Yeah, the config scripts will be a bother if I do this, especially given that I have very little knowledge or experience with sh scripting or the GNU Build System (such experience as I have makes me want a better build system.) 


There already is some limited theming available in GNUstep. You find the
API and the code for it in gui/Source/GSTheme.m.


Thanks, I'll take a look.

Paul



___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: gnustep on windows

[Fred Kiefer]

Paul Fox wrote:
 Out of curiosity, why do you want to use cairo on Windows and not the
 native window interface (or one based on GDI+)?
 
 Why Cairo? Mainly because it gives me a fairly nice graphics library
 that's cross-platform. For fancy graphics, Cairo gives a consistent
 appearance across platforms, allows me to ignore platform when coding
 for the most part, and is much nicer looking than GDI. I'm really still
 exploring what's possible here, and it appears that Cairo is the most
 potentially capable backend.

When programming with GNUstep you will be working against the GNUstep
drawing API, not cairo or GDI. It is true that the implementation of
this API for cairo is more complete, but even that may be changed.


___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: gnustep on windows

[Fred Kiefer]

Paul Fox wrote:
 Currently, I am, for various reasons, tied to Windows for most of the
 time. I also think GNUstep looks as if it would make a good
 cross-platform development library (more elegant than QT, and without
 all the restrictions.)  However, in the course of examining and
 attempting to build GNUstep for Windows, I've discovered that  Cairo
 graphics for GNUstep under Windows are unimplemented. I'm interested in
 correcting that, and, from a cursory glance, it doesn't look
 tremendously difficult, but I haven't spent a lot of time yet tracking
 down all the bits of X dependent code, so I'm wondering if anyone knows
 how deep this dependency runs.
 

There shouldn't be any X dependencies in the cairo backend code apart
from the X surfaces of course. You should be able to provide your own MS
Windows surface and use that. This gets a bit harder on the make file
level, here our config scripts currently only support the cairo backend
for X11.
There is one other problem I see, although freetype is available for
Windows you will most likely want to use native font support. For this
you will need to implement your own classes or port the ones from the
the winlib backend.
Out of curiosity, why do you want to use cairo on Windows and not the
native window interface (or one based on GDI+)?


 When I have more time (who knows when that will be!) I will take a
 deeper look and try to figure out everything that needs to be done to
 enable the Cairo backend on Windows.
 
 On a side note, I've heard that there are plans for a theming API, but
 I've had some difficulty finding any details. Where could I find out
 about that?
 
There already is some limited theming available in GNUstep. You find the
API and the code for it in gui/Source/GSTheme.m.

Cheers
Fred




___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

gnustep on windows

[Paul Fox]

Currently, I am, for various reasons, tied to Windows for most of the 
time. I also think GNUstep looks as if it would make a good 
cross-platform development library (more elegant than QT, and without 
all the restrictions.)  However, in the course of examining and 
attempting to build GNUstep for Windows, I've discovered that  Cairo 
graphics for GNUstep under Windows are unimplemented. I'm interested in 
correcting that, and, from a cursory glance, it doesn't look 
tremendously difficult, but I haven't spent a lot of time yet tracking 
down all the bits of X dependent code, so I'm wondering if anyone knows 
how deep this dependency runs.


When I have more time (who knows when that will be!) I will take a 
deeper look and try to figure out everything that needs to be done to 
enable the Cairo backend on Windows.


On a side note, I've heard that there are plans for a theming API, but 
I've had some difficulty finding any details. Where could I find out 
about that?



___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: gnustep on windows

[Xavier Glattard]

Hello

Some months (a year ?) ago i tried to write a Cairo backend for windows.
You can get the files there :
http://amstradstuff.free.fr/GNUstep/back-win32cairo.zip
Put then in Source/cairo directory

Achtung : two files will be overwritten !!

I'm not sure they still can be build as cairo backend has been changed 
but they may be a first step.
You will need FreeType and fontconfig.

Regards

Xavier




___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: GNUstep on Windows - libm5.dll caveat

[Adam Fedor]

On Nov 29, 2007, at 5:23 AM, Christopher Armstrong wrote:


I know this message is probably noise, but couldn't think where else
to put it. Maybe useful as an example of one of those hairy and  
bizarre

problems that occurs. I've spent all week trying to figure it out.



No it's great.  I wish more people would talk about their experience  
on Windows.


My current problem is on a 64bit machine - every program just dies  
when it tries to do a trampoline (via libffi - ffcall doesn't even  
compile). There's no reason and no way to catch it, it seems.  Funny  
thing is, this only occurs when you run the program from a different  
directory than your current dir.  If you run it from the same  
directory, it works (trampolines still fail, but at least the program  
doesn't die).


I wonder if anyone else has gotten it to work on a 64 bit machine.


___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

gnustep on Windows

[Daniel Almeida]

Greetings everyone.

I'm developing an application for Mac OS X, Linux and Windows using
Cocoa and Gnustep.
I've managed to run my program on windows but not in the way I would
like to. Isn't it possible to make the gnustep for windows distribution
to run gnustep programs just by clicking in the program file? Why must I
run it through the console? (ok, I know that some variables must be set
and maybe more things are happening!)

I think the bust thing that for me would to gather all needed files and
drop them in the same directory of my executable and run everything from
there. Can this me made to work?

I've made another cross platform application using GTK2 and this was
what I did for windows. Everything worked just fine!

Best Regards

Daniel Almeida




___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Getting started with software developing with GnuStep on Windows

[Roger Persson]

Hello folks!

This is my first question on this list. Does developer on this list to
those developing the GnuStep library, or does it refers to software
developers using the GnuStep library, or does it refers to both? :-)

What do I need to get started building software on Windows using Cocoa /
GnuStep?

I tried builing a very simple app, but the Makefile system didn't work
because I fail running the set-up script. Am I suppose to use another
terminal other than the DOS-prompt cmd.exe?

I have some general questions:

Is GnuStep on Windows suitable for building stand-alone software on
Windows?

I mean, does an application require many DLLs files to run, or is the
GnuStep fully a static library ?

Does an application require other things like a Info.plist file or a BSD
directory structure (Library, System, Users, etc..) to run?

My software for Cocoa is not complicated. It uses C++ for the heavy work
and Objective-C for the graphical interface.

Thanks for any help!

/Frode




___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Getting started with software developing with GnuStep on Windows

[Roger Persson]

Hello folks!

This is my first question on this list. Does developer on this list to
those developing the GnuStep library, or does it refers to software
developers using the GnuStep library, or does it refers to both? :-)

What do I need to get started building software on Windows using Cocoa /
GnuStep?

I tried builing a very simple app, but the Makefile system didn't work
because I fail running the set-up script. Am I suppose to use another
terminal other than the DOS-prompt cmd.exe?

I have some general questions:

Is GnuStep on Windows suitable for building stand-alone software on
Windows?

I mean, does an application require many DLLs files to run, or is the
GnuStep fully a static library ?

Does an application require other things like a Info.plist file or a BSD
directory structure (Library, System, Users, etc..) to run?

My software for Cocoa is not complicated. It uses C++ for the heavy work
and Objective-C for the graphical interface.

Thanks for any help!

/Frode




___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev