Re: mingw compilation of base broken
--- Running tests in base/NSNumber ---
base/NSNumber/test00.m:
Failed test: test00.m:102 ... NSDecimalNumber numberWithInt: works
Failed test: test00.m:107 ... NSDecimalNumber doubleValue works
Failed test: test00.m:111 ... NSDecimalNumber charValue works
Failed test: test00.m:113 ... NSDecimalNumber intValue works
Failed test: test00.m:115 ... NSDecimalNumber integerValue works
Failed test: test00.m:117 ... NSDecimalNumber longValue works
Failed test: test00.m:119 ... NSDecimalNumber longLongValue works
Failed test: test00.m:121 ... NSDecimalNumber shortValue works
Failed test: test00.m:123 ... NSDecimalNumber unsignedCharValue works
Failed test: test00.m:125 ... NSDecimalNumber unsignedIntValue works
Failed test: test00.m:127 ... NSDecimalNumber unsignedIntegerValue works
Failed test: test00.m:129 ... NSDecimalNumber unsignedLongValue works
Failed test: test00.m:133 ... NSDecimalNumber unsignedShortValue works
I looked into these test results in some detail and the behaviour is
really strange. The generated NSDecimalNumber seems to have the correct
value, using the description method on the objects yields the correct
result. But when extracting the number from the object things go wrong
for some types. It works for float, bool and unsigned long long, but for
the other types we get a slightly different value. As all these
extraction methods are implemented as simple type cast something must go
wrong there:
- (int) intValue
{
return (int)NSDecimalDouble(data);
}
- (double) doubleValue
{
return NSDecimalDouble(data);
}
How do these two go wrong while the next one seems to work?
- (float) floatValue
{
return (float)NSDecimalDouble(data);
}
If I remember correctly, this isn't new behaviour. I tried to figure out
at least one time before what is going on here, but failed.
I found one rather interesting answer to gcc quirks on MinGW, but this
really doesn't apply to our case. It just makes it clear that we are
talking about a very specific platform here:
http://stackoverflow.com/questions/7134547/gcc-printf-and-long-double-leads-to-wrong-output-c-type-conversion-messes-up
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: mingw - Ink crash
Riccardo Mottola wrote: I did a svn update, make clean, make and run that executable... so in theory no. Then, make systems are not exact science. $ ls -l Ink.app/Ink.exe -rwxr-xr-x 1 mottola Administrators 750367 Aug 23 14:34 Ink.app/Ink.exe $ ls -l ../../../../core/base/Source/NSException.m -rw-r--r-- 1 mottola Administrators 25594 Jun 3 20:31 ../../../../core/base/Source/NSException.m Aug 23 Jun 3 :) These aren't the relevant dates. The relevant ones would be those of gnustep-base dll vs. NSException.m. To find out that you are using the correct dll, try info sharedlibrary in gdb when Ink crashes. Also make sure that your executable isn't loading two different versions of gnustep-base. Wolfgang ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
mingw installation domains: system vs. local defaults!
Hi, Fred's question about me having multiple base installation proved to be legitimate. I discovered that I have gnustep-base in both the local domain and in the system domain on windows. The new one, the current one, being in Local and the old one in System, about from March. This explains also the message source file newer than executable. it was not referred to Ink, but to the library. However, I never changed installation domains and I still have in /etc/GNUstep/installation-domain.conf all system libraries in SYSTEM. I do not specify during configure and make time the installation domain. Are we back to the nightmare were we need to specify the installation domain manually on windows? I truly hope NOT! Riccardo ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: mingw - Ink crash
Hi, Riccardo Mottola wrote: I did a svn update, make clean, make and run that executable... so in theory no. Then, make systems are not exact science. $ ls -l Ink.app/Ink.exe -rwxr-xr-x 1 mottola Administrators 750367 Aug 23 14:34 Ink.app/Ink.exe $ ls -l ../../../../core/base/Source/NSException.m -rw-r--r-- 1 mottola Administrators 25594 Jun 3 20:31 ../../../../core/base/Source/NSException.m Aug 23 Jun 3 :) These aren't the relevant dates. The relevant ones would be those of gnustep-base dll vs. NSException.m. To find out that you are using the correct dll, try info sharedlibrary in gdb when Ink crashes. Also make sure that your executable isn't loading two different versions of gnustep-base. You are right, make ins mixing up the installation domains (again). For a long time everything worked smoothly... this is very inconvenient. I'll try forcing again as in the dark times. Riccardo ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
