On Wednesday, July 18, 2012 01:44 CEST, Stefan Bidi <stefanbidi@gmail.com>
wrote:
I believe I fixed the at least some of the failing tests. I made
CFNumber test more verbose to get some insight in what is going on.
The CFString formating tests will be a little more tricky, this most
likely has to do with how ppc passes arguments. Unfortunately, I have
no idea where to even start fixing this error.
yep, I looked a bit into it, and it seems, this needs some byte swapping,
depending
on CFByteOrderGetCurrent() or the like. I'll also look into it later today.
So far, all, besides this timezone name now work for me on i386 and amd64.
on macppc, only the following fails:
Running Tests/CFNumber/general.m...
Failed test: general.m:24 ... SInt32 converted to SInt8 (251) correctly.
Running Tests/CFString/format.m...
Failed test: format.m:14 ... Characters are formatted correctly
expected r un, but got
Failed test: format.m:50 ... Strings are formatted correctly
expected 0xc A longer than usual string., but got 0x0 A longer than usual
string.
Failed test: general.m:40 ... Standard localized name is correct.
expected Central European Time, but got Central European Standard Time
The pthread thing should also be resolved, please give it another shot.
Yes, works for me, as long as I don't have LIBS defined in configure
environment.
I patched configure.ac again to fix that, a space is missing ;)
But I've seen to detect the objc_getClass, you took the easy route.
What if someone installs libobjc2 so that it must be linked with:
-li-give-a-fuck-how-i-call-the-runtime
then your test will fail again. Therefore I suggested to use input from
gnustep-config --objc-libs
I'm not good with this autoconf, but if you don't mind, I'll take a look at it
also.
So the patch below fixes:
- the configure mentioned above
- a couple "no newline at the end of file" compiler warnings
- and in CFStringFormat.c, the warning:
CFStringFormat.c: In function '_CFStringAppendFormatAndArgumentsAux':
CFStringFormat.c:1057: warning: comparison is always false due to limited
range of data type
but actually, I don't know why you don't put the CFUnknownType, or define it as
UINT16_MAX?
then this weirdo casting I'm doing might not be necessary, which I doubt may
not even be right.
cheers,
Sebastian