discuss-gnustep
[Top][All Lists]
Advanced

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

Re: GNUstep-corebase to be released next week


From: Sebastian Reitenbach
Subject: Re: GNUstep-corebase to be released next week
Date: Wed, 18 Jul 2012 09:47:18 +0200
User-agent: SOGoMail 1.3.16

 
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

$OpenBSD$
--- Headers/CoreFoundation/CFAttributedString.h.orig    Wed Jul 18 08:36:20 2012
+++ Headers/CoreFoundation/CFAttributedString.h Wed Jul 18 08:36:26 2012
@@ -126,4 +126,5 @@ CFAttributedStringSetAttributes (CFMutableAttributedSt
 
 CF_EXTERN_C_END
 
-#endif /* __COREFOUNDATION_CFATTRIBUTEDSTIRNG_H__ */
\ No newline at end of file
+#endif /* __COREFOUNDATION_CFATTRIBUTEDSTIRNG_H__ */
+
$OpenBSD$
--- Headers/CoreFoundation/CFXMLParser.h.orig   Wed Jul 18 08:36:05 2012
+++ Headers/CoreFoundation/CFXMLParser.h        Wed Jul 18 08:36:10 2012
@@ -198,4 +198,5 @@ CFXMLTreeCreateFromDataWithError (CFAllocatorRef alloc
 
 CF_EXTERN_C_END
 
-#endif /* __CFCOREFOUNDATION_CFXMLPARSER_H__ */
\ No newline at end of file
+#endif /* __CFCOREFOUNDATION_CFXMLPARSER_H__ */
+
$OpenBSD$
--- Source/CFDateFormatter.c.orig       Wed Jul 18 08:38:43 2012
+++ Source/CFDateFormatter.c    Wed Jul 18 08:38:59 2012
@@ -716,4 +716,5 @@ CFTypeID
 CFDateFormatterGetTypeID (void)
 {
   return _kCFDateFormatterTypeID;
-}
\ No newline at end of file
+}
+
$OpenBSD$
--- Source/CFStringFormat.c.orig        Wed Jul 18 08:39:40 2012
+++ Source/CFStringFormat.c     Wed Jul 18 08:52:34 2012
@@ -70,7 +70,7 @@ typedef enum
   CFPtrDiffTLength
 } CFArgLength;
 
-#define CFUnknownType -1
+#define CFUnknownType (UniChar)-1
 typedef enum
 {
   CFUnsignedType,
$OpenBSD$
--- Source/CFXMLNode.c.orig     Wed Jul 18 08:38:21 2012
+++ Source/CFXMLNode.c  Wed Jul 18 08:38:26 2012
@@ -453,4 +453,5 @@ CFIndex
 CFXMLNodeGetVersion (CFXMLNodeRef node)
 {
   return node->_version;
-}
\ No newline at end of file
+}
+
$OpenBSD$
--- Source/NSCFArray.m.orig     Wed Jul 18 08:38:01 2012
+++ Source/NSCFArray.m  Wed Jul 18 08:38:08 2012
@@ -67,4 +67,5 @@
 {
   CFArrayRemoveValueAtIndex (self, (CFIndex)index);
 }
-@end
\ No newline at end of file
+@end
+
$OpenBSD$
--- Source/NSCFType.h.orig      Wed Jul 18 08:35:40 2012
+++ Source/NSCFType.h   Wed Jul 18 08:35:52 2012
@@ -66,4 +66,5 @@ CFRuntimeSetInstanceISA (CFTypeRef cf, Class cls)
 - (CFTypeID) _cfTypeID;
 @end
 
-#endif /* __NSCFTYPE_H__ */
\ No newline at end of file
+#endif /* __NSCFTYPE_H__ */
+
$OpenBSD$
--- configure.ac.orig   Wed Jul 18 09:02:17 2012
+++ configure.ac        Wed Jul 18 09:02:33 2012
@@ -41,12 +41,12 @@ AC_LANG_CONFTEST([AC_LANG_PROGRAM([[#include <pthread.
                                   [[pthread_mutex_t mutex;]])])
 ${CC} -pthread conftest.c -o conftest.o > /dev/null 2>&1
 if test $? -eq 0; then
-  LIBS="$LIBS-pthread "
+  LIBS="$LIBS -pthread "
   AC_MSG_RESULT([yes])
 else
   ${CC} -lpthread conftest.c -o conftest.o > /dev/null 2>&1
   if test $? -eq 0; then
-    LIBS="$LIBS-lpthread "
+    LIBS="$LIBS -lpthread "
     AC_MSG_RESULT([yes])
   else
     AC_MSG_RESULT([no])


> 
> On Tue, Jul 17, 2012 at 5:39 PM, Sebastian Reitenbach
> <sebastia@l00-bugdead-prods.de> wrote:
> > On that box I use:
> > icu4c-49.1.2p0      International Components for Unicode
> >
> > on my desktop, still having OpenBSD 5.1, I have older version of icu4c:
> > icu4c-4.8.1.1       International Components for Unicode
> > with this version, the CLTimeTimeZone test is successfull.
> >
> 
> That's what I figured.  It is really hard running unit tests against
> ICU's output because it changes from version to version.  For now, I'm
> just going to call it a "known failure" and be done.
> 
> > Sebastian
> >
 
 
 
 



reply via email to

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