On 8/2/07, Sourav K. Mandal <sourav.mandal@...> wrote:
> [quote snipped]
> * 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_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
-I../Headers -I./. -I. -I/usr/GNUstep/System/Library/Headers
This is with -ggdb on the CFLAGS, splitdebug on FEATURES and debug on
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
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
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
I mean, my idea with building gnustep is basically to test Étoilé for some time.
> Good luck,
> Sourav K. Mandal
> PGP: 7E7E 14CD A983 484C 8A43 55CA DBAC 539C 1814 3DAF
> firstname.lastname@example.org 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
email@example.com mailing list