Re: [gentoo-gnustep] Re: Help with gnustep

[Luis Felipe Strano Moraes]

On 8/2/07, Luis Felipe Strano Moraes <luis.strano@×××××.com> wrote:
> On 8/2/07, Sourav K. Mandal <sourav.mandal@×××××.com> wrote:
> > [quote snipped]
> >
> > Comments:
> >
> > * I would be nervous to use the ~x86 keyword except for specific
> > packages at a high-level.  The reason it takes a while for things to get
> > into x86 is because there are obscure bugs which can affect obscure
> > setups -- unfortunately, GNUstep is in this category.  A small bug in
> > the toolchain can screw up everything else on top of it.  At a minimum,
> > I would revert to gcc-4.1 and glibc-2.5 in x86.
> I found too many problems related with having some packages ~x86 and
> some x86, and in general my experience with ACCEPT_KEYWORDS="~x86"
> has been a really pleasant one (I mean, I've been using gentoo for years now,
> and ~x86 is alot more stable now than it was before).
> I tried reverting to gcc-4.1.2 and recompiling gnustep-base but it didn't
> change anything, I can try reverting glibc as well, but I'd rather try other
> things first if possible.
>
> >
> > * Consider adding "-ggdb" to your C(XX)FLAGS, and "splitdebug" to your
> > features.  Compilation will produce gdb-compatible debugging symbols,
> > but they'll be split off into /usr/lib/debug to reduce loading times for
> > binaries.  This works for ObjC/GNUstep; if you are serious about
> > debugging, do this.
> I've tried this already, but the debug flags are being stripped so far
> as I can tell. Take
> a look at the example below which I randomly selected from the
> compilation output :
>
> i686-pc-linux-gnu-gcc NSIndexPath.m -c \
>               -MMD -MP -DGNUSTEP_TARGET_DIR=\".\"
> -DGNUSTEP_TARGET_CPU=\"ix86\" -DGNUSTEP_TARGET_OS=\"linux-gnu\"
> -DGNUSTEP_IS_FLATTENED=\"yes\" -DLIBRARY_COMBO=\"gnu-gnu-gnu\" -Wall
> -Wcast-align -DGNUSTEP -DGNUSTEP_BASE_LIBRARY=1 -DGNU_GUI_LIBRARY=1
> -DGNU_RUNTIME=1 -DGNUSTEP_BASE_LIBRARY=1 -D_REENTRANT -fPIC -g -Wall
> -DDEBUG -fno-omit-frame-pointer -DGSWARN -DGSDIAGNOSE -Wno-import
> -march=prescott -pipe -fno-strict-aliasing -fexceptions
> -fobjc-exceptions -D_NATIVE_OBJC_EXCEPTIONS -fgnu-runtime
> -fconstant-string-class=NSConstantString -I../Headers/Additions
> -I../Headers -I./. -I. -I/usr/GNUstep/System/Library/Headers
> -I/usr/GNUstep/System/Library/Headers -I/usr/include/libxml2
> -I/usr/include -I/var/tmp/portage/gnustep-base/gnustep-base-1.14.0/temp/GNUstep/Library/Headers
> -I/usr/GNUstep/Local/Library/Headers
> -I/usr/GNUstep/System/Library/Headers \
>                -o obj/NSIndexPath.o
>
> This is with -ggdb on the CFLAGS, splitdebug on FEATURES and debug on
> gnustep-base's
> USEflags. Am I doing anything wrong ?

Ok, apparently it's compiling with debug support, so I just ran the plmerge line
which was giving me errors on gdb and this is the backtrace that I got
(I've to go
to class now, and I'll take a look at it later tonight possibly) :

(gdb) r libgnustep-back-012.bundle/Resources/Info-gnustep.plist
libgnustep-back-012Info.plist
Starting program: /usr/GNUstep/System/Tools/plmerge
libgnustep-back-012.bundle/Resources/Info-gnustep.plist
libgnustep-back-012Info.plist

Program received signal SIGABRT, Aborted.
0xb7eed410 in __kernel_vsyscall ()
(gdb) backtrace
#0  0xb7eed410 in __kernel_vsyscall ()
#1  0xb7795969 in raise () from /lib/libc.so.6
#2  0xb7796f51 in abort () from /lib/libc.so.6
#3  0xb7afd6ef in objc_exception_throw () from
/usr/lib/gcc/i686-pc-linux-gnu/4.2.0/libobjc.so.2
#4  0xb7c4a06f in -[NSException raise] (self=0x80fd6e0,
_cmd=0xb7e753a0) at NSException.m:806
#5  0xb7bad638 in -[GSMutableDictionary setObject:forKey:]
(self=0x80f9880, _cmd=0xb7e70cf0, anObject=0x0, aKey=0x80814c8)
    at GSDictionary.m:408
#6  0xb7b9d1fb in GSDomainFromDefaultLocale () at GSLocale.m:162
#7  0xb7d04e37 in +[NSUserDefaults standardUserDefaults]
(self=0xb7ecca00, _cmd=0xb7e93350) at NSUserDefaults.m:592
#8  0xb7c40313 in -[NSDictionary writeToFile:atomically:]
(self=0x80964b0, _cmd=0x804ab58, path=0x808bff8, useAuxiliaryFile=1
'\001')
    at NSDictionary.m:951
#9  0x080492c3 in main () at plmerge.m:139
#10 0xb77829a8 in __libc_start_main () from /lib/libc.so.6
#11 0x080488e1 in _start ()




--lf


>
>
> >
> > * You have a ton of USE flags.  The more intricate/featureful your
> > system, the more likely you are to get weird bugs.  Consider paring it
> > down to exactly what you need.
> Ok, there are lots of USE flags there that are related to a bug on
> gtkphoto2 which
> I still haven't had the time to take a better look at (I've got a
> canon camera, but the
> canon useflag is not adding support for it, so I brute forced and set
> all useflags
> possible). I can cut down my USEflags, but that would involve rebuilding the
> entire system, and I would really prefer another solution to finding
> out what's wrong
> if possible.
> I mean, my idea with building gnustep is basically to test Étoilé for some time.
>
> cheers,
> --lf
>
> >
> >
> > Good luck,
> >
> > Sourav
> >
> >
> > --
> > Sourav K. Mandal
> > http://sourav.net/
> >
> > PGP: 7E7E 14CD A983 484C 8A43  55CA DBAC 539C 1814 3DAF
> >
> > --
> > gentoo-gnustep@g.o mailing list
> >
> >
>
>
> --
> "People assume that time is a strict progression of cause to effect...
> but actually, from a non-linear, non-subjective viewpoint, it's more
> like a big ball of wibbly-wobbly...timey-wimey...stuff." - The Doctor
>


-- 
"People assume that time is a strict progression of cause to effect...
but actually, from a non-linear, non-subjective viewpoint, it's more
like a big ball of wibbly-wobbly...timey-wimey...stuff." - The Doctor
-- 
gentoo-gnustep@g.o mailing list