[bug #29203] Base does not compile with GNUstep libobjc from svn trunk
URL: http://savannah.gnu.org/bugs/?29203 Summary: Base does not compile with GNUstep libobjc from svn trunk Project: GNUstep Submitted by: wlux Submitted on: Fr 12 Mär 2010 10:39:07 GMT Category: Base/Foundation Severity: 3 - Normal Item Group: Bug Status: None Privacy: Public Assigned to: None Open/Closed: Open Discussion Lock: Any ___ Details: The recent changes on the trunk have broken compilation when using libobjc from the GNUstep svn. The first problem is that objc/objc.h does not define the type BOOL type at all if BOOL is #defined. This might be fixed by removing the #ifdef BOOL check from objc/objc.h or by replacing #define BOOL GNU_BOOL in Source/ObjectiveC2/runtime.c by #define BOOL BOOL. The second problem is that the GNUstep libobjc defines objc_sync_enter and objc_sync_exit and thus building libgnustep-base fails because these functions are defined twice (once in libobjc and once in Source/ObjectiveC2/sync.m). ___ Reply to this item at: http://savannah.gnu.org/bugs/?29203 ___ Nachricht geschickt von/durch Savannah http://savannah.gnu.org/ ___ Bug-gnustep mailing list Bug-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnustep
[bug #29204] GNUstep base does not compile on Apple machines
URL: http://savannah.gnu.org/bugs/?29204 Summary: GNUstep base does not compile on Apple machines Project: GNUstep Submitted by: wlux Submitted on: Fr 12 Mär 2010 10:43:02 GMT Category: Base/Foundation Severity: 3 - Normal Item Group: Bug Status: None Privacy: Public Assigned to: None Open/Closed: Open Discussion Lock: Any ___ Details: There is an incorrect #if defined(__APPLE__) test in Source/Additions/NSThreads+GNUstepBase.m, which breaks compilation when using gnu-gnu-gnu on Apple machines. This #ifdef really should check whether base is built for *-apple-*. ___ Reply to this item at: http://savannah.gnu.org/bugs/?29204 ___ Nachricht geschickt von/durch Savannah http://savannah.gnu.org/ ___ Bug-gnustep mailing list Bug-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnustep
[bug #29208] NSCalendarDate's format does not support the %k conversion specifier
URL: http://savannah.gnu.org/bugs/?29208 Summary: NSCalendarDate's format does not support the %k conversion specifier Project: GNUstep Submitted by: yavor Submitted on: Fri 12 Mar 2010 03:41:18 PM EET Category: Base/Foundation Severity: 3 - Normal Item Group: Change Request Status: None Privacy: Public Assigned to: None Open/Closed: Open Discussion Lock: Any ___ Details: While preparing the upload of SimpleAgenda/0.40 for Debian I discovered something unpleasant -- the time in the app icon is displayed as '%k,minutes,seconds' when run under Bulgarian locale. This is because our locale definition is '%k,%M,%S'. (The %k specifier is a GNU extension according to the glibc manual, which makes its use perfectly valid in a glibc locale.) Unfortunately NSCalendarDate (as documented) does not understand it. I checked the Cocoa documentation, and there's no %k there too (not surprising). Would you accept a patch implementing support for the %k specifier? I hope that Apple not implementing it won't be an obstacle... AFAICS from the online documentation, `strftime' in FreeBSD, OpenSolaris and even Mac OS X support it, so it's not something strictly GNU-specific. The attached test program demonstrates the current ugliness: $ LC_ALL=C ./obj/test %H:%M:%S 15:37:17 $ LC_ALL=en_US.UTF-8 ./obj/test %r 03:38:37 PM $ ./obj/test %k,%M,%S %k,38,48 ___ File Attachments: --- Date: Fri 12 Mar 2010 03:41:18 PM EET Name: test.m Size: 401B By: yavor http://savannah.gnu.org/bugs/download.php?file_id=19920 ___ Reply to this item at: http://savannah.gnu.org/bugs/?29208 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-gnustep mailing list Bug-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnustep
[bug #29204] GNUstep base does not compile on Apple machines
Update of bug #29204 (project gnustep): Status:None = Fixed Open/Closed:Open = In Test ___ Follow-up Comment #1: Thanks ... I applied the suggested fix ... please let me know if it works now. ___ Reply to this item at: http://savannah.gnu.org/bugs/?29204 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-gnustep mailing list Bug-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnustep
[bug #29208] NSCalendarDate's format does not support the %k conversion specifier
Follow-up Comment #1, bug #29208 (project gnustep): I'd be very happy to have a patch to support this. Yes please. It would be ideal if you could bracket the behavior with: if (NO == GSPrivateDefaultsFlag(GSMacOSXCompatible)) That way, if someone sets the GSMacOSXCompatible user default to YES, they would get OSX compatible behavior. ___ Reply to this item at: http://savannah.gnu.org/bugs/?29208 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-gnustep mailing list Bug-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnustep
[bug #29203] Base does not compile with GNUstep libobjc from svn trunk
Follow-up Comment #2, bug #29203 (project gnustep): I guess the solution is to remove sync support from the libobjc code as it's now in base. seems a lot simpler than adding autoconf tests and conditionally compiling the sync stuff. Not sure. Once the libobjc shipped with GCC gets sync support, you may have to add the tests back. So we may as well have them now ? Thanks ___ Reply to this item at: http://savannah.gnu.org/bugs/?29203 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-gnustep mailing list Bug-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnustep
[bug #29204] GNUstep base does not compile on Apple machines
Follow-up Comment #2, bug #29204 (project gnustep): Yes, it does work now. Thanks. ___ Reply to this item at: http://savannah.gnu.org/bugs/?29204 ___ Nachricht geschickt von/durch Savannah http://savannah.gnu.org/ ___ Bug-gnustep mailing list Bug-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnustep
[bug #29203] Base does not compile with GNUstep libobjc from svn trunk
Follow-up Comment #3, bug #29203 (project gnustep): Not sure. Once the libobjc shipped with GCC gets sync support, you may have to add the tests back. So we may as well have them now ? Are there any plans to add sync support to gcc's libobjc any time soon? If not, I'd be in favor of removing sync support from GNUstep's libobjc and not getting into the troubles of adding an autoconf test. ___ Reply to this item at: http://savannah.gnu.org/bugs/?29203 ___ Nachricht geschickt von/durch Savannah http://savannah.gnu.org/ ___ Bug-gnustep mailing list Bug-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnustep
Logic error in GSContext.m?
Hi everyone, I think that I find a logic error in the code of *GSContext.m * (back/Source/gsc/GSContext.m) I don't know why you do this: const unsigned char *data[5]; [bitmap getBitmapDataPlanes: data]; * * while the getBitmapDataPlanes receive *unsigned char ***, by the way I just modify to remove the warnings in the gsc module (?).* * Sorry for my English. Anibal.- GSContext.patch Description: Binary data ___ Bug-gnustep mailing list Bug-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnustep
[bug #29191] How does gdlgsdoc work?
Follow-up Comment #1, bug #29191 (project gnustep): gdlgsdoc --verbose=1 Examples/library.eomodel gdlgsdoc --verbose=1 --template=Tools/eomodeltemplate.gsdoc Examples/library.eomodel creates Examples/library.gsdoc for me (make debug=yes strip=no). I have no idea why segfault happens with the optimization is enabled by plain make. The backtrace: #0 0xb7b5f7ac in objc_msg_lookup (receiver=0xb7f8b5e0, op=0xb7f582f8) at /build/buildd/gcc-4.4-4.4.1/src/libobjc/sendmsg.c:225 #1 0xb7d5342e in GSPrivateFormat (s=0xbfffd730, format=0xbfffd78c, ap=0xbfffe87c 240k 23b200350 21bt 05b320` 23b300W 23b8 05b340265370267 60w 23b$351377277300ffbjb, locale=0x0) at GSFormat.m:1848 #2 0xb7d702eb in -[GSPlaceholderString initWithFormat:locale:arguments:] (self=0x8067dd8, _cmd=0xb7fa9be8, format=0x805208c, locale=0x0, argList=0xbfffe87c 240k 23b200350 21bt 05b320` 23b300W 23b8 05b340265370267 60w 23b$351377277300ffbjb) at GSString.m:769 #3 0xb7e8f76e in -[NSString initWithFormat:arguments:] (self=0x8067dd8, _cmd=0xb7fdbe08, format=0x805208c, argList=0xbfffe87c 240k 23b200350 21bt 05b320` 23b300W 23b8 05b340265370267 60w 23b$351377277300ffbjb) at NSString.m:1073 #4 0xb7f207e6 in +[NSString(GNUstepBase) stringWithFormat:arguments:] (self=0xb7fa9a60, _cmd=0xb7fa9c38, format=0x805208c, argList=0xbfffe87c 240k 23b200350 21bt 05b320` 23b300W 23b8 05b340265370267 60w 23b$351377277300ffbjb) at NSString+GNUstepBase.m:45 #5 0xb7e92954 in -[NSString stringByAppendingFormat:] (self=0x8136100, _cmd=0x8051f30, format=0x805208c) at NSString.m:1501 #6 0x0804ab48 in -[EOModel(GSDoc) gsdocContentSplittedByEntities:idPtr:] (self=0x811d560, _cmd=0x8052c38, entitiesPtr=0x0, xmlIdPtr=0x0) at EOModel+GSDoc.m:77 #7 0x0804ccad in main (argc=3, argv=0xbfffeb64, env=0xbfffeb74) at gsdoc-model.m:411 ___ Reply to this item at: http://savannah.gnu.org/bugs/?29191 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-gnustep mailing list Bug-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnustep
[bug #29191] How does gdlgsdoc work?
Follow-up Comment #2, bug #29191 (project gnustep): ubuntu 9.10 base r29694 2010-02-21 10:33:24 gdl2 r29566 2010-02-12 02:44:52 ___ Reply to this item at: http://savannah.gnu.org/bugs/?29191 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-gnustep mailing list Bug-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnustep
[bug #29191] How does gdlgsdoc work?
Additional Item Attachment, bug #29191 (project gnustep): File name: gdl2_Tools_EOModel_GSDoc.patch Size:0 KB ___ Reply to this item at: http://savannah.gnu.org/bugs/?29191 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-gnustep mailing list Bug-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnustep
