gnustep-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Base status


From: Fred Kiefer
Subject: Re: Base status
Date: Wed, 17 Aug 2011 20:06:45 +0200
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; de; rv:1.9.2.18) Gecko/20110616 SUSE/3.1.11 Thunderbird/3.1.11

With the change in place things look normal again for MinGW.

On 17.08.2011 13:48, Richard Frith-Macdonald wrote:
On 17 Aug 2011, at 10:45, Fred Kiefer wrote:
I really would like to see the 1400 test errors we get on MinGW reduced before 
the next release.

I agree ... mingw is probably our second highest priority platform after 
gnu/linux, so major problems there
How are you building it?  Recent (not necessarily very recent ... I haven't 
tried for weeks) changes seem to have completely broken the build of base on 
mingw for me.

I just downloaded Adam's latest MinGW installation and after installing that compiled make, base, gui and back as usual. You have to remember to add a few configure parameters for make to get the file system layout and the prefix correct.

As far as I can tell most of this boil down to GSMime issues (The NSURL test 
seems to be a result of that as well). Even the most simple test in GSMime 
build.m produces the wrong result. Only the last header and the content get 
reported as the rawMimeData.
As debuggin on MinGW is a rather annoying task, especially when done in a 
virtual machine, I looked through the code at GSMime to find any MinGW specific 
issue and there aren't any. So I furteher tracked this down until I got to the 
method -headerNamed: which always returned the first element what ever the 
given name was. There we use this horrible optimisation of implementation 
caching. Fine if done correctly, but here we use the type IMP to cache a method 
that returns a BOOL not an object. I will fix this later on and give the MinGW 
testing another try. in GSMime.m I could see about five of this misuses of IMP 
and we will have to check the rest of base as well.

Traditionally IMP was supposed to be fine for any method returning a scalar 
type ... but I guess that was back in the (NeXTstep) days where all the ABIs 
passed such return values back by setting the value of a register.  Nowadays 
the use of IMP is definitely no longer safe, and we should check all code as 
you say.   In fact we should probably periodically review this kind of thing 
... optimisations which were necessary when the code was originally written may 
no longer be important (or even be counter-productive) with modern CPUs and 
compilers.

Still no idea why this breaks on MinGW but seems to work on most other systems.

I thought most tests used to pass on MinGW too.

They do now again! NSDecimalNumber and NSNumberformatter aren't working and there are a few random messages about sockets, but the rest looks fine. Ah yes, there is this -isClass issue, which is a bit uncomfortable, but this may just be caused by David removing the "Object.h" import and now the compiler may expect the wrong return type? Just guessing here, why shouldn't this obscure bug have the same reason as the other had?



reply via email to

[Prev in Thread] Current Thread [Next in Thread]