Gentoo Archives: gentoo-gnustep

From: Luis Felipe Strano Moraes <luis.strano@×××××.com>
To: gentoo-gnustep@l.g.o
Subject: Re: [gentoo-gnustep] Re: Help with gnustep
Date: Thu, 02 Aug 2007 19:34:39
In Reply to: Re: [gentoo-gnustep] Re: Help with gnustep by "Sourav K. Mandal"
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 ?
> > * 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 > > > 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 -- gentoo-gnustep@g.o mailing list


Subject Author
Re: [gentoo-gnustep] Re: Help with gnustep Luis Felipe Strano Moraes <luis.strano@×××××.com>