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 preferenc

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
     0x7ffce04d1

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, sch

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 b

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 
endea

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

[Vincent Richomme]

On Sun, 24 Jan 2010 12:53:48 +0100, Vincent Richomme
 wrote:
> On Sun, 24 Jan 2010 12:43:36 +0100, Riccardo Mottola 
> 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

[Vincent Richomme]

On Sun, 24 Jan 2010 12:43:36 +0100, Riccardo Mottola 
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

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

[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

Re: GNUStep on Windows

[Vincent R.]

On Fri, 22 Jan 2010 16:12:18 +, David Chisnall 
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 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 (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?

[Yury Mishchenko]

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

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  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

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

[Christopher Armstrong]

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.


Christopher Armstrong
[EMAIL PROTECTED]





___
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

[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

[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

[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

[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

[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]

Fred Kiefer  gmx.de> writes:

> 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

You're so right :-)
The fixed zip file is online. It has to be unzipped in the back (or back/trunk)
directory.

No need for a special configure script : the current one is fine.
I pushed the 'complicated extensions' in the repository a long time ago.
Just in case :-)

This code partialy worked : i can remember some smooth text in a menu.
Cairo on glitz did not work.

You made many changes in the cairo backend : i can get my code work now. But it
is build.

Regards

Xavier








___
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

[TMC]

Paul Fox wrote:
> 
> 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?
> 
You might be talking about [Camaelon][1] (spelling is important).

[1]: http://www.etoile-project.org/etoile/mediawiki/index.php?title=Camaelon

--Tycho Martin Clendenny
-- 
View this message in context: 
http://www.nabble.com/gnustep-on-windows-tp15760118p15769005.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

[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]

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

[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

[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

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

Re: gnustep on Windows

[Adam Fedor]

On May 26, 2006, at 9:26 AM, Daniel Almeida wrote:


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?


Most likely. See the recent discussion on another list:

http://lists.gnu.org/archive/html/discuss-gnustep/2006-05/msg00150.html



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