[bug #29612] Sometimes Gorm saves images from themes into gorm files.
Follow-up Comment #3, bug #29612 (project gnustep): I can reproduce this (in fact I spent time trying to understand my problem, until I remembered this bug). Steps to reproduce the problem: 1) Install Neos theme and active it. 2) Make a new project with Project center. 3) With gorm add one checkbox at interface. 4) Compile the app and run it. All work fine. Close the app. 5) Active the default theme. 6) Run our test app and now when you select the checkbox, you can see the image from Neos theme (even when this isn't active). Try a checkbox in other app (for example GWorkspace) you see the default image. The problem is with the gorm file of our test app. But, if you look inside the gorm directory, there isn't images. See attached image, my problem with FisicaLab. (file #20707) ___ Additional Item Attachment: File name: images.jpg Size:3 KB ___ Reply to this item at: http://savannah.gnu.org/bugs/?29612 ___ Mensaje enviado vai/por Savannah http://savannah.gnu.org/ ___ Bug-gnustep mailing list Bug-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnustep
[bug #29845] FTBFS on GNU/Hurd with -Wl,--no-undefined
Follow-up Comment #2, bug #29845 (project gnustep): Any news on this? It would be nice to get a fix into a 1.20.1 release. Also, I looked at the URL https://buildd.debian.org/fetch.cgi?pkg=gnustep-basearch=hurd-i386ver=1.19.3-2stamp=1273445079file=logas=raw I can't claim to fully understand this log, but I'm guessing it's a build of a debian source package? A few queries/observations... 1. Why is LDFLAGS set to -Wl,-z,defs -Wl,--as-needed ? I don't know what this does ... it seems unlikely (since I guess these flags do no harm on other systems) but perhaps it's the cause of the problem? It's a natural suspect since the flags are for the linker and the problem is a linker issue (the linker ought to be expecting gnustep_base_user_main to be undefined, not complaining about it). 2. The base configure log says: Your gnustep-make is configured to use native objc exceptions, but the objc runtime does not appear to support setting an uncaught exception handler. This means that any uncaught exception will cause a program to abort immediately. Consider reconfiguring gnustep-make or updating libobjc to fix this. So the library is being built with the wrong objective-c library and/or incorrectly configured gnustep-make. That suggests that the packages or package dependencies are faulty. I can't see how this could have any effect on the linking issue, but it looks like a package problem. Of course, this is an old version of GNUstep anyway ... so perhaps this bug report is obsolete and should simply be closed? ___ Reply to this item at: http://savannah.gnu.org/bugs/?29845 ___ 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 #29845] FTBFS on GNU/Hurd with -Wl,--no-undefined
Follow-up Comment #3, bug #29845 (project gnustep): No news, unfortunately. I'd be glad to provide a patch if I only knew what would be the correct fix... It seems that all platforms which use the GS_FAKE_MAIN hack are affected; on GNU/Linux you can reproduce the problem with ./configure --enable-fake-main LDFLAGS=-Wl,--no-undefined To your questions: I'm guessing it's a build of a debian source package? That's right. 1. Why is LDFLAGS set to -Wl,-z,defs -Wl,--as-needed ? The latter removes unnecessary dependencies. When you link -lfoo and -lbar, but you only need -lfoo, dpkg-shlibdeps will add an explicit package dependency on the package providing libfoo.so. -Wl,-z,defs is a safety check; it enables symbol resolution at build time, to ensure that all objects are linked against all libraries they use symbols from. Note that this is not a Debian invention; most binary-based distros (Fedora, Mandriva, etc.) use these flags for most packages, because this solves the following vital issues: 1) package foo *must* depend on all packages it needs 2) in the ideal case package foo should not depend on any packages it doesn't need, because this causes inconvenience for users and more importantly, complicates library transitions and the archive software (at least for Debian) perhaps it's the cause of the problem? Absolutely. For the time being I workarounded the issue (to use only --as-needed on GNU/Hurd). So the library is being built with the wrong objective-c library and/or incorrectly configured gnustep-make. Yes, this is fixed in 1.20.0-1, but this problem is not the culprit here. perhaps this bug report is obsolete No, it's not. ___ Reply to this item at: http://savannah.gnu.org/bugs/?29845 ___ 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 #29845] FTBFS on GNU/Hurd with -Wl,--no-undefined
Follow-up Comment #4, bug #29845 (project gnustep): Ah ... so '-Wl,-z,defs -Wl,--as-needed' has a similar effect to '-Wl,--no-undefined' In that case this is really not a bug ... the linker flags are telling the link to fail since the fake main mechanism *requires* the gnustep_base_user_main() function to be undefined as it is supplied by the program which is using gnsutep. ie. your program implements gnustep_base_user_main() and the base library calls the method in your program from the main() function in NSProcessInfo.m So this is more a package bug (building base with illegal linker flags), than a gnustep bug, but I guess either way we want to fix it somehow. So ... there are two obvious options: 1. change the package script to change the linker flags ... but as they do something useful (as well as breaking things), that's not ideal. 2. add hurd support to avoid the need for fake-main The reason for the existence of fake-main is to allow the NSProcessInfo class to be properly initialized with the process arguments and environment. On many platforms we can get that information from the /proc filesystem or by some other system specific mechanism. On platforms where there is no known mechanism to get that information, we have to use the argc, argv, and envp arguments to main() (which is what the fake-main does for us). If there's a hurd specific way to obtain that info, we could change the configure.ac to detect its presence and add code to use it instead of fake-main. Do you know of a way to do it? I suppose another option is just to change the makefile to filter out the linker flags which cause the trouble, but that's not much better than changing the package build script to refrain from using the flags. ___ Reply to this item at: http://savannah.gnu.org/bugs/?29845 ___ 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 #29845] FTBFS on GNU/Hurd with -Wl,--no-undefined
Follow-up Comment #5, bug #29845 (project gnustep): Ah ... so '-Wl,-z,defs -Wl,--as-needed' has a similar effect to '-Wl,--no-undefined' Almost; -Wl,-z,defs is another way of writing -Wl,--no-undefined. the fake main mechanism requires the gnustep_base_user_main() function to be undefined as it is supplied by the program which is using gnsutep. Thanks... I never actually fully understood the fake-main thingy :-( So it's not a bug, I agree. So this is more a package bug (building base with illegal linker flags) (You mean invalid, illegal is something different and its use in this context is discourged by the GNU Coding Standards.) Yes, I agree the value of LDFLAGS is invalid for this platform, and it's a Debian packaging bug for defining it. If there's a hurd specific way to obtain that info, we could change the configure.ac to detect its presence and add code to use it instead of fake-main. Do you know of a way to do it? IIRC one or two years ago there was a Hurd GSoC project for implementing a GNU/Linux-compatible procfs translator. AFAICS now, the code has been merged into the Hurd repository and is available in the Debian hurd(-dev) package. So my wild guess is that /proc on GNU/Hurd is not mounted by default, which is why the configure check fails. I can use --enable-procfs when configuring gnustep-base on this platform, but I have to recheck with the Hurd people if/how it is guaranteed to have /proc on a live user GNU/Hurd system, otherwise things may break at runtime. Many thanks for enlightening me. I suggest to close this bug; if it turns out there are other related issues I'll follow up accordingly. ___ Reply to this item at: http://savannah.gnu.org/bugs/?29845 ___ 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 #30094] (Regression) FTBFS on GNU/kFreeBSD: sync.m:87: error: 'PTHREAD_MUTEX_RECURSIVE' undeclared
URL: http://savannah.gnu.org/bugs/?30094 Summary: (Regression) FTBFS on GNU/kFreeBSD: sync.m:87: error: 'PTHREAD_MUTEX_RECURSIVE' undeclared Project: GNUstep Submitted by: yavor Submitted on: Wed Jun 9 14:38:36 2010 Category: Base/Foundation Severity: 3 - Normal Item Group: Bug Status: None Privacy: Public Assigned to: None Open/Closed: Open Discussion Lock: Any ___ Details: 1.20.0 fails to build on GNU/kFreeBSD with the following error: gcc sync.m -c \ -MMD -MP -Wall -Wdeclaration-after-statement -DGNUSTEP -DGNUSTEP_BASE_LIBRARY=1 -DGNU_RUNTIME=1 -DGNUSTEP_BASE_LIBRARY=1 -D_REENTRANT -fPIC -Wall -DGSWARN -DGSDIAGNOSE -Wno-import -g -O2 -fno-strict-aliasing -fexceptions -fobjc-exceptions -D_NATIVE_OBJC_EXCEPTIONS -fgnu-runtime -fgnu-runtime -fconstant-string-class=NSConstantString -I../../Headers/Additions -I../. -I../ -I../../Headers -I. -I/usr/include/GNUstep -I/usr/local/include/GNUstep -I/usr/local/include/GNUstep -I/usr/include/libxml2 -I/usr/include -I/usr/local/include/GNUstep -I/usr/include/GNUstep \ -o obj/ObjectiveC2.obj/sync.m.o sync.m: In function 'initLockObject': sync.m:87: warning: implicit declaration of function 'pthread_mutexattr_settype' sync.m:87: error: 'PTHREAD_MUTEX_RECURSIVE' undeclared (first use in this function) sync.m:87: error: (Each undeclared identifier is reported only once sync.m:87: error: for each function it appears in.) make[5]: *** [obj/ObjectiveC2.obj/sync.m.o] Error 1 Trivial patch attached. GNU libc supports several kernels: Linux, GNU Mach+Hurd, kFreeBSD and (unofficially) kOpenSolaris. So the correct check in this case is for the symbol __GLIBC__, which is guaranteed to be defined on all glibc-based platforms. Perhaps it's worth to leave __linux__ for the rare cases when another libc is used with Linux (uClibc, dietlibc, etc.), although I'm not sure if the GNUstep stack works on those systems at all. Thanks. ___ File Attachments: --- Date: Wed Jun 9 14:38:36 2010 Name: kfreebsd.patch Size: 610B By: yavor http://savannah.gnu.org/bugs/download.php?file_id=20708 ___ Reply to this item at: http://savannah.gnu.org/bugs/?30094 ___ 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 #29845] FTBFS on GNU/Hurd with -Wl,--no-undefined
Follow-up Comment #6, bug #29845 (project gnustep): seems like you could declare gnustep_base_user_main with __attribute__((weak)) which should allow it to continue building with -Wl,-z,defs ___ Reply to this item at: http://savannah.gnu.org/bugs/?29845 ___ 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 #30094] (Regression) FTBFS on GNU/kFreeBSD: sync.m:87: error: 'PTHREAD_MUTEX_RECURSIVE' undeclared
Update of bug #30094 (project gnustep): Status:None = Fixed Open/Closed:Open = Closed ___ Follow-up Comment #1: Thanks, I applied that fix. ___ Reply to this item at: http://savannah.gnu.org/bugs/?30094 ___ 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
Re: [bug #30077] Unable to launch application on Windows
Unfortunately, I didn't indicate it before but I was at revision 30606 at the time. I just updated base to r30616 (from 30586) and the crash is back. I didn't think it was anything related to our app specifically, but I'll dig around some more and see what I can find. Doug On Jun 8, 2010, at 3:53 AM, Richard Frith-Macdonald wrote: Follow-up Comment #2, bug #30077 (project gnustep): I haven't reproduced this on windowsw, but I guess your problem was not windows specific and was due to a mistake someone made in the invocation code which caused a crash on some versions of the runtime. If that's the problem then I already committed a fix at revision 30606 and certainly updating trunk from svn should solve it for you. ___ Reply to this item at: http://savannah.gnu.org/bugs/?30077 ___ 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
Re: [bug #30077] Unable to launch application on Windows
Okay, here's a bit more information: The crash occurs at line 779 of NSDistributedNotificationCenter.m in the _connect method. Watching the Windows Task Manager I can see that gdnc gets launched ok. The thing that may be different about our app is that this occurs when we call [NSDocumentController init] while instantiating a custom subclass of NSDocumentController. We do this fairly early, in an override of NSApplication's +sharedApplication method, before we call [super sharedApplication]. Is it possible that this (in conjunction with the recent changes in base) is the source of the problem? Based on that guess, I rearranged our code to call [super sharedApplication] before creating our documentController instance, but that didn't resolve the problem. Any new idea what the cause might be? On Jun 8, 2010, at 3:53 AM, Richard Frith-Macdonald wrote: Follow-up Comment #2, bug #30077 (project gnustep): I haven't reproduced this on windowsw, but I guess your problem was not windows specific and was due to a mistake someone made in the invocation code which caused a crash on some versions of the runtime. If that's the problem then I already committed a fix at revision 30606 and certainly updating trunk from svn should solve it for you. ___ Reply to this item at: http://savannah.gnu.org/bugs/?30077 ___ 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
Re: [bug #30045] minor incompatibility in NSURL
Thanks again, Richard! Doug On Jun 8, 2010, at 10:54 AM, Richard Frith-Macdonald wrote: Update of bug #30045 (project gnustep): Status:None = Fixed Open/Closed:Open = Closed ___ Follow-up Comment #1: Thanks ...added a check to fix that. ___ Reply to this item at: http://savannah.gnu.org/bugs/?30045 ___ 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 #29845] FTBFS on GNU/Hurd with -Wl,--no-undefined
Update of bug #29845 (project gnustep): Status:None = Fixed Open/Closed:Open = In Test ___ Follow-up Comment #7: Great idea about making gnustep_base_user_main 'weak' It's never quite that simple, but with some other tweaking I think I've got the code to a state where we can use fake-main *and* -Wl,--no-undefined Changes now in svn trunk. Please give it a go and let me know. ___ Reply to this item at: http://savannah.gnu.org/bugs/?29845 ___ 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
