[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
> >
- Re: GNUstep-corebase to be released next week, (continued)
- Re: GNUstep-corebase to be released next week, Sebastian Reitenbach, 2012/07/17
- Re: GNUstep-corebase to be released next week, Stefan Bidi, 2012/07/17
- Re: GNUstep-corebase to be released next week, Sebastian Reitenbach, 2012/07/17
- Re: GNUstep-corebase to be released next week, Stefan Bidi, 2012/07/17
- Re: GNUstep-corebase to be released next week, Gregory Casamento, 2012/07/17
- Re: GNUstep-corebase to be released next week, Stefan Bidi, 2012/07/17
- Re: GNUstep-corebase to be released next week, Gregory Casamento, 2012/07/18
- Re: GNUstep-corebase to be released next week, Stefan Bidi, 2012/07/18
- Re: GNUstep-corebase to be released next week, Gregory Casamento, 2012/07/18
- Opal backend (was: GNUstep-corebase to be released next week), Ivan Vučica, 2012/07/19
- Re: GNUstep-corebase to be released next week,
Sebastian Reitenbach <=
- Re: GNUstep-corebase to be released next week, Fred Kiefer, 2012/07/18
- Re: GNUstep-corebase to be released next week, Stefan Bidi, 2012/07/18
- Re: GNUstep-corebase to be released next week, Eric Wasylishen, 2012/07/18
- Re: GNUstep-corebase to be released next week, Stefan Bidi, 2012/07/21
Re: GNUstep-corebase to be released next week, Sebastian Reitenbach, 2012/07/17