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