Re: Application crashes when embedding GNU Smalltalk lib - Help?
fyi -
At the moment I seem to be successfully avoiding the problem by
statically linking libgst (and libexecinfo) into my framework, as
follows:
LIBRARIES_DEPEND_UPON = -Wl,-Bsymbolic,-Bstatic,-lgst,-lexecinfo,-
Bdynamic -lreadline -lm
This is probably what I want to do anyway, since I'd like to
encapsulate libgst in the framework to avoid the need to install it
separately.
-Tim
On May 1, 2007, at 10:27 PM, Tim McIntosh wrote:
Nicola,
Good call! Apparently libgst includes libsnprintfv, which provides
another version of register_printf_function (incompatible, of
course -- it returns a pointer upon success). I'll have to think
about how to best work around this.
This brings up another question, though: is it really safe/
advisable to raise an exception in NSString +initialize? Is there
a better way to handle this error condition? I've never seen the
exception actually get printed; the app always crashes with
SIGSEGV. In the original application where I first encountered
this, I couldn't even get a usable stack trace--it looked like a
stack overflow was occurring due to recursion or something.
Thanks!
-Tim
On May 1, 2007, at 10:07 AM, Nicola Pero wrote:
from the stacktrace that you provided, it seems that the problem
is in NSString +initialize.
In particular, you're getting the following exception:
#ifdef HAVE_REGISTER_PRINTF_FUNCTION
if (register_printf_function ('@',
handle_printf_atsign,
#if PRINTF_ATSIGN_VA_LIST
0))
#else
arginfo_func))
#endif
[NSException raise: NSGenericException
format: @"register printf handling of %%@
failed"];
#endif /* HAVE_REGISTER_PRINTF_FUNCTION */
Maybe if you link GNU smalltalk, that interferes with
register_printf_function() somehow ? Or anyway
causes it to fail
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Application crashes when embedding GNU Smalltalk lib - Help?
Nicola,
Good call! Apparently libgst includes libsnprintfv, which provides
another version of register_printf_function (incompatible, of course
-- it returns a pointer upon success). I'll have to think about how
to best work around this.
This brings up another question, though: is it really safe/advisable
to raise an exception in NSString +initialize? Is there a better way
to handle this error condition? I've never seen the exception
actually get printed; the app always crashes with SIGSEGV. In the
original application where I first encountered this, I couldn't even
get a usable stack trace--it looked like a stack overflow was
occurring due to recursion or something.
Thanks!
-Tim
On May 1, 2007, at 10:07 AM, Nicola Pero wrote:
from the stacktrace that you provided, it seems that the problem is
in NSString +initialize.
In particular, you're getting the following exception:
#ifdef HAVE_REGISTER_PRINTF_FUNCTION
if (register_printf_function ('@',
handle_printf_atsign,
#if PRINTF_ATSIGN_VA_LIST
0))
#else
arginfo_func))
#endif
[NSException raise: NSGenericException
format: @"register printf handling of %%@
failed"];
#endif /* HAVE_REGISTER_PRINTF_FUNCTION */
Maybe if you link GNU smalltalk, that interferes with
register_printf_function() somehow ? Or anyway
causes it to fail
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev
Backbone + gnustep-make v2 patch
Here is a patch to update Backbone to work with gnustep-make v2 (and FHS, etc). I'm sending it to the mailing list so that it doesn't get lost. ;-) Thanks diff Description: Binary data ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
RE: Application crashes when embedding GNU Smalltalk lib - Help?
Hi Tim,
from the stacktrace that you provided, it seems that the problem is in NSString
+initialize.
In particular, you're getting the following exception:
#ifdef HAVE_REGISTER_PRINTF_FUNCTION
if (register_printf_function ('@',
handle_printf_atsign,
#if PRINTF_ATSIGN_VA_LIST
0))
#else
arginfo_func))
#endif
[NSException raise: NSGenericException
format: @"register printf handling of %%@ failed"];
#endif /* HAVE_REGISTER_PRINTF_FUNCTION */
Maybe if you link GNU smalltalk, that interferes with
register_printf_function() somehow ? Or anyway
causes it to fail ? To confirm that this is the problem, you could try to
comment that bit out and see if that
stops the problem.
Thanks
-Original Message-
From: Tim McIntosh <[EMAIL PROTECTED]>
Sent: Mon, April 30, 2007 2:56 am
To: GNUstep Developer
Subject: Application crashes when embedding GNU Smalltalk lib - Help?
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev
Does anyone happen to know why the mere presence of "-lgst" (GNU
Smalltalk library) in the link would cause the attached app to crash?
(see transcript below)
Thanks!
-Tim
Transcript:
% uname -a
FreeBSD kashyyyk.astro.net 6.2-RELEASE FreeBSD 6.2-RELEASE #0: Fri
Jan 12 11:05:30 UTC 2007 [EMAIL PROTECTED]:/usr/obj/
usr/src/sys/SMP i386
### NOTE: As shown below, app runs when -lgst is suppressed; same
results if the Test_GUI_LIBS line is simply removed from the
Makefile: ###
% gmake Test_GUI_LIBS=
This is gnustep-make 2.0.0. Type ’make print-gnustep-make-help’
for help.
Making all for app Test...
Creating Test.app/
Compiling file main.m ...
Linking app Test ...
Creating Test.app/Resources...
Creating Test.app/Resources/Info-gnustep.plist...
Creating Test.app/Resources/Test.desktop...
% openapp ./Test
2007-04-29 19:33:45.080 Test[80416] Unable to read color file at "/
Network/Users/tmcintos/Library/Colors/Emacs
.clr" -- unknown format.
^C
% gmake clean
This is gnustep-make 2.0.0. Type ’make print-gnustep-make-help’
for help.
rm -rf ./*~ ./obj
(cd .; \
rm -rf*.app)
### NOTE: Here is the build with -lgst where the crash is observed: ###
% gmake
This is gnustep-make 2.0.0. Type ’make print-gnustep-make-help’
for help.
Making all for app Test...
Creating Test.app/
Compiling file main.m ...
Linking app Test ...
Creating Test.app/Resources...
Creating Test.app/Resources/Info-gnustep.plist...
Creating Test.app/Resources/Test.desktop...
% openapp ./Test
Segmentation fault
% debugapp ./Test
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and
you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for
details.
This GDB was configured as "i386-marcel-freebsd"...
(gdb) run
Starting program: /.amd_mnt/alderaan/Exports/Users/tmcintos/
Development/SmallTalk/SmallStep/Test.subproj/Test.
app/Test
warning: Unable to get location for thread creation breakpoint:
generic error
[New LWP 100098]
[New Thread 0x8054018 (LWP 100098)]
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x8054018 (LWP 100098)]
0x in ?? ()
(gdb) bt
#0 0x in ?? ()
#1 0x2852fde2 in +[NSAutoreleasePool new] (self=0x28773a80,
_cmd=0x28773b08) at NSAutoreleasePool.m:143
#2 0x285300e4 in +[NSAutoreleasePool addObject:] (self=0x28773a80,
_cmd=0x2879d208, anObj=0x80c9b60)
at NSAutoreleasePool.m:247
#3 0x285bbd30 in -[NSObject autorelease] (self=0x80c9b60,
_cmd=0x287d6960) at NSObject.m:1790
#4 0x28653a29 in +[NSString(GSCategories)
stringWithFormat:arguments:] (self=0x287b2880, _cmd=0x28789f68,
format=0x287b2ddc, argList=0xbfbfdc90 "x¬\t\b%") at
GSCategories.m:1100
#5 0x285828aa in +[NSException raise:format:arguments:]
(self=0x28789d80, _cmd=0x28789f60, name=0x2878a07c,
format=0x287b2ddc, argList=0xbfbfdc90 "x¬\t\b%") at
NSException.m:751
#6 0x28582854 in +[NSException raise:format:] (self=
FW: Addresses building patch
Not sure if Bjorn received my patch or applied it, so just resending out to dev and if anything is working on that at least they can reuse it Thanks -Original Message- From: Nicola Pero <[EMAIL PROTECTED]> Sent: Wed, March 7, 2007 8:02 pm To: Björn Giesler <[EMAIL PROTECTED]> Subject: Addresses building patch Hi Bjorn I was looking at Addresses (great stuff) and noticed your GNUmakefiles needed a bit of updating to work with the forthcoming gnustep-make v2 (FHS, etc) too. Since it takes me very little to do the updates myself, I just did it for you -- in attach a patch. ;-) ThanksOnly in Addresses-0.4.6/AddressManager: AddressManager.app diff -ru Addresses-0.4.6/Frameworks/Addresses/GNUmakefile Addresses-0.4.6.nicola/Frameworks/Addresses/GNUmakefile --- Addresses-0.4.6/Frameworks/Addresses/GNUmakefile 2004-07-29 16:36:21.0 +0100 +++ Addresses-0.4.6.nicola/Frameworks/Addresses/GNUmakefile 2007-03-07 18:56:57.0 + @@ -49,6 +49,6 @@ -include GNUmakefile.postamble after-Addresses-install:: - ln -sf $(GNUSTEP_INSTALLATION_DIR)/Library/Headers/Addresses \ - $(GNUSTEP_INSTALLATION_DIR)/Library/Headers/AddressBook + ln -sf $(GNUSTEP_HEADERS)/Addresses \ + $(GNUSTEP_HEADERS)/AddressBook diff -ru Addresses-0.4.6/GNUmakefile Addresses-0.4.6.nicola/GNUmakefile --- Addresses-0.4.6/GNUmakefile 2004-07-29 16:36:21.0 +0100 +++ Addresses-0.4.6.nicola/GNUmakefile 2007-03-07 18:57:47.0 + @@ -1,3 +1,7 @@ +ifeq ($(GNUSTEP_MAKEFILES),) + GNUSTEP_MAKEFILES := $(shell gnustep-config --variable=GNUSTEP_MAKEFILES 2>/dev/null) +endif + include $(GNUSTEP_MAKEFILES)/common.make PACKAGE_NAME = Addresses diff -ru Addresses-0.4.6/Goodies/LDAPAddressBook/LDAPAddressBookClass/GNUmakefile Addresses-0.4.6.nicola/Goodies/LDAPAddressBook/LDAPAddressBookClass/GNUmakefile --- Addresses-0.4.6/Goodies/LDAPAddressBook/LDAPAddressBookClass/GNUmakefile 2004-07-29 16:36:21.0 +0100 +++ Addresses-0.4.6.nicola/Goodies/LDAPAddressBook/LDAPAddressBookClass/GNUmakefile 2007-03-07 18:55:01.0 + @@ -2,7 +2,7 @@ BUNDLE_NAME=LDAPAddressBook BUNDLE_EXTENSION=.abclass -LDAPAddressBook_INSTALL_DIR=$(GNUSTEP_ROOT)/Local/Library/Addresses +LDAPAddressBook_INSTALL_DIR=$(GNUSTEP_LIBRARY)/Addresses LDAPAddressBook_OBJC_FILES=LDAPAddressBook.m utils.m LDAPAddressBook_RESOURCE_FILES=LDAPPersonMapping.plist LDAPAddressBook_MAIN_CLASS=LDAPAddressBook diff -ru Addresses-0.4.6/Goodies/VCFViewer/GNUmakefile Addresses-0.4.6.nicola/Goodies/VCFViewer/GNUmakefile --- Addresses-0.4.6/Goodies/VCFViewer/GNUmakefile 2004-07-29 16:36:21.0 +0100 +++ Addresses-0.4.6.nicola/Goodies/VCFViewer/GNUmakefile 2007-03-07 18:55:46.0 + @@ -1,13 +1,13 @@ +# hack -- GWorkspace won't find bundles if they weren't installed in +# ~/GNUstep/Library/GWorkspace +GNUSTEP_INSTALLATION_DOMAIN = USER + include $(GNUSTEP_MAKEFILES)/common.make BUNDLE_NAME = VCFViewer BUNDLE_EXTENSION = .inspector -BUNDLE_INSTALL_DIR = $(GNUSTEP_INSTALLATION_DIR)/Library/GWorkspace - -# hack -- GWorkspace won't find bundles if they weren't installed in -# ~/GNUstep/Library/GWorkspace -GNUSTEP_INSTALLATION_DIR = $(GNUSTEP_USER_ROOT) +BUNDLE_INSTALL_DIR = $(GNUSTEP_LIBRARY)/GWorkspace VCFViewer_HAS_RESOURCE_BUNDLE = yes @@ -31,7 +31,7 @@ @echo "*** WARNING: Due to a GWorkspace limitation, VCFViewer.inspector" @echo "*** currently MUST be installed at ~/GNUstep/Library/GWorkspace" @echo "*** (in your case, $(BUNDLE_INSTALL_DIR))." - @echo "*** Your settings for GNUSTEP_INSTALLATION_DIR (if any)" + @echo "*** Your settings for GNUSTEP_INSTALLATION_DOMAIN (if any)" @echo "*** have been overridden." @echo "***" @echo "***" diff -ru Addresses-0.4.6/INSTALL Addresses-0.4.6.nicola/INSTALL --- Addresses-0.4.6/INSTALL 2004-07-29 16:36:21.0 +0100 +++ Addresses-0.4.6.nicola/INSTALL 2007-03-07 18:56:24.0 + @@ -1,8 +1,8 @@ -1. Make sure you have sourced the file +1. Make sure your GNUstep environment is setup. Usually, this means that you have sourced the file - $GNUSTEP_ROOT/System/Library/Makefiles/GNUstep.sh + $GNUSTEP_MAKEFILES/GNUstep.sh - You can test this by typing "echo $GNUSTEP_ROOT". If that gives an + You can test this by typing "echo $GNUSTEP_MAKEFILES". If that gives an empty line, you need to source the mentioned file. 2. Type diff -ru Addresses-0.4.6/README Addresses-0.4.6.nicola/README --- Addresses-0.4.6/README 2004-07-29 16:36:21.0 +0100 +++ Addresses-0.4.6.nicola/README 2007-03-07 18:54:10.0 + @@ -82,9 +82,10 @@ To keep the library and application as open as possible, it is extensible via plugins. These are loaded from the usual places: - $(GNUSTEP_ROOT)/System/Library/Addresses - $(GNUSTEP_ROOT)/Local/Library/Addresses - $(HOME)/GNUstep/Library/Addresses + $(GNUSTEP_SYSTEM_LIBRARY)/Addresses + $(GNUSTEP_NETWORK_LIBRARY)/Addresses + $(GNUSTE
Re: AddressManager input mask does not work anymore
Hi, "AddressManager developers" is a "work in progress" thing. The original developer had put the project on hold and as far as I know Etoile has some sort of fork. Now I contacted the original developer (Bjoern Gieseler) and obtained that the new official home for Addresses is GAP. I waited to make an announcement since I wanted to check compilation problems (and find a way to fix the installation which is broken since the latest make changes) of the imported source tree, file on it, look for people to work with, gather information about possible patches, etc. Since the problem surfaced now I just thought it good to mention this "transition" which is not yet completed. Furthermore I don't think I will have many resources to dedicate to it myself, but I wanted to give Addresses an official place and avoid a fork. So if there are news about the current problems, be sure to cc me! cheers, Riccardo On 2007-04-26 14:58:32 +0200 Fred Kiefer <[EMAIL PROTECTED]> wrote: Has anybody looked into this problem? I think the AddressManager developers should the first ones to confirm whether this is a GNUstep problem. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
