Jackass! 2005.0 Support Group

[96140]

You have some problem in CFLAGS recommendation
After cecking GCC manual and compare with your flags i discover some inconsistency
You recomand for CFLAGS

Code: Select all

CFLAGS="-march=pentium -mtune=pentium"
CFLAGS="${CFLAGS} -pipe"
CFLAGS="${CFLAGS} -03"
CFLAGS="${CFLAGS} -fweb"
CFLAGS="${CFLAGS} -frename-registers"
CFLAGS="${CFLAGS} -fforce-addr"
CFLAGS="${CFLAGS} -momit-leaf-frame-pointer"
CFLAGS="${CFLAGS} -fomit-frame-pointer"
CFLAGS="${CFLAGS} -ftracer"

And way you do not include LDFLAGS > ?

I believe the CFLAGS are redundantly specified so the sneaky ebuild writers can't strip out these helpful flags when they have their ebuilds strip out -O3; as long as the package only looks for -O3--which many packages do--it won't take out helpful things like the redundant CFLAGS.

And check bugs.gentoo.org, as well as searching the forums for "ldflags"; there have been some problems compiling packages if LDFLAGS are set--especially if the LDFLAGS are used in combinations with CFLAGS like the ones specified in the Jackass make.conf. But if you really want to use LDFLAGS, and potentially make your system unstable, it's your call. But is it worth recompiling your entire prebuilt Jackass-powered system several times just for a couple of LDFLAGS?

Really, there is such a thing as overoptimizing your Gentoo!

[Triple5]

Only if Jackass was easier to get running/installed =X
Otherwise its almost as running the Naked/Gentoo

[Bob P]

Bob P, ok, that explanation suits me fine. One of the reasons why I asked was that the PDF doesn't work well on my computer at work. I don't know what's wrong but it seems to have pages missing and images not showing. I get a few error messages from Adobe Reader while the PDF is open... But I'll try to view it with another computer.

When you download the PDF, there's a note next to the PDF icon that mentions that you have to be using Acrobat 5.0. If your reader is older than 5.0, you can't view the file. One of our team members ran into the similar problems to yours with a 5.0 reader, and found that the problem was caused by a corrupted installation of Acrobat.

I've also had a problem installing the Jackass. Nvidia-kernel doesn't seem to compile properly. No errors anywhere, but when loading the module it says it's not a proper module (I'll check the exact error message in a while). I tried both x86 and ~x86. I also tried it with 4kb and 8kb kernel stacks, because some older nvidia-kernel had problems with 4kb stacks.


I was thinking if it was possible to compile it with more conservative CFLAGS. Such as "-O2 -pipe -fomit-frame-pointer". All my other systems has been compiled using that and I haven't seen this problem with them... Only problem now is how to emerge it using those CFLAGS. Can I run 'CFLAGS="-O2 -pipe -fomit-frame-pointer" emerge nvidia-kernel'? Is there a file such as packages.use for this?

Jackass! comes with a standardized set of CFLAGS that have been tested on all of the arches that we've built it for. That isn't to say that we've tested it with everything. Some of our testers have reported that there are specific versions of nvidia drivers that work and some that don't. Beyond that, there isn't much that I can personally add about the driver issues, other than to say that it seems to be a driver problem or a kernel configuration issue.

In regard to emerging Jackass! using more conservative CFLAGS, we don't offer a package like that, but if you want to do that, I'd recommend following the Stage 1/3 Installation Guide.

Edit2: Hmmm... http://forums.gentoo.org/viewtopic-t-33 ... ormat.html
Looks like someone else has had the same problem with Bob P's Stage 1/3 method. Why does it say the kernel is compiled with gcc 3.3.5 when I'm running a pure Jackass 2005.0 install? Well... Only thing that isn't Jackass is my /boot partition which has some of my old kernels.

well, i would consider rebuilding your kernels so that they are built with our compiler. our compiler is probably more extensively tested than the compiler that you used to build your kernels.

the other thing that may be worth looking into is a problem with static library retention by the ebuild. if that's the case, the problem is with the ebuild, which needs to have a bug report filed. in the interim, i would suggest rebuilding the video driver with emerge --emptytree, and doing that twice.

[Bob P]

Ok... Now I got it working. I have no idea why cat /proc/version said I have compiled the kernel using gcc 3.3.5, but I recompiled it and now it's working.

that does sound like a static library problem with the ebuild. i would file a bug report.

[Bob P]

Hi all
it is nice to sea iptables included in LiveCD and some other stuff like mc may be even Wiondow manager.
Do you have such plans ?

iptables ca be very very usefull whan installing Gentoo Jackass on gateway or proxy without disconecting network.

no. we just emerge shorewall as one of our first world packages.

we didn't include a window manager for a number of reasons. if we had planned on compiling everything for you, we would have named our project Mandrake or SuSE.

if you want a precompiled window manager, i would suggest looking at the Gentoo GRP binaries.

[Bob P]

You have some problem in CFLAGS recommendation
After cecking GCC manual and compare with your flags i discover some inconsistency
You recomand for CFLAGS...

the subject of redundancy in CFLAG specification has been beaten to death in the threads that led up to the Jackass! Project.

the debate about them was often quite lengthy, so rather than retyping it all, i'll just point you to the relevant threads where this information has already been discussed:

Stage 1/3 Installation Guide for 2004.3
Stage 1/3 Installation Support for 2004.3
Stage 1/3 Installation Guide for 2005.0
Stage 1/3 Installation Support for 2005.0

a search for the term "cflag stripping" will also yield about a dozen threads.

LDFLAGS were not used because they break things.

hth.

[Bob P]

Only if Jackass was easier to get running/installed =X
Otherwise its almost as running the Naked/Gentoo

making Jackass! behave like Gentoo was our design goal. although most people who exclusively use linux in a desktop environment may not realize it, not everybody who uses linux needs X, so X is not included in the package. fwiw, i have an entire array of linux boxes, and X is only installed on one of them.

[obsidianblackhawk]

Only if Jackass was easier to get running/installed =X
Otherwise its almost as running the Naked/Gentoo

but a lot faster and all the hard work is done for you.

[Bob P]

I'm starting to have some problems with udev ... permission problems that I'm able to fix, but I'm not convinced I'm doing it right. For example, I was having the "-bash: /dev/null: Permission denied" error today.

i think that this is a problem with udev in the newer versions of the portage tree. i just "upgraded" my stable branch box to udev-056 and as soon as i ran dispatch-conf, i started having the permission errors at logon, such as the infamous "-bash: /dev/null: Permission denied."

fwiw, there were no changes applied to the toolchain.

interestingly, the problem appears to have disappeared after a reboot. (!)

http://bugs.gentoo.org/show_bug.cgi?id=92333

[Hikaru79]

I'm starting to have some problems with udev ... permission problems that I'm able to fix, but I'm not convinced I'm doing it right. For example, I was having the "-bash: /dev/null: Permission denied" error today.

i think that this is a problem with udev in the newer versions of the portage tree. i just "upgraded" my stable branch box to udev-056 and as soon as i ran dispatch-conf, i started having the permission errors at logon, such as the infamous "-bash: /dev/null: Permission denied."

fwiw, there were no changes applied to the toolchain.

interestingly, the problem appears to have disappeared after a reboot. (!)

http://bugs.gentoo.org/show_bug.cgi?id=92333

Thanks Bob =) I re-emerged udev and everything works fine. I don't know why it happened but as long as it's fixed...

One more question -- I'm really liking Jackass, so I'd like to also install it on my friend's computer. His processor is marked as "Intel Celeron" ... it's not a Pentium, although it is by Intel. Does that mean that none of the Jackass tarballs are appropriate for him? Or is Celeron equivalent to one of the P arches? And if not, if I just do a regular gentoo install, what should his mtune and march flags be set to?

Thanks in advance!

[marcelk]

the Pros to not resyncing, and using the portage snapshot that we provided are that our portage snapshot is tested and free of errors.

the Cons to not resyncing are that you may be able to find more recent versions of the packages in the portage tree.

from a practical standpoint, we can guarantee that the portage snapshot that's included with Jackass! works properly. we cannot make that guarantee for any other versions of the portage tree, so if you resync to a more recent snapshot, all bets are off.

Is it really that bad? But, for instance, how can I install a security update of Mozilla if the portage tree is not up-to-date? I am sorry bothering you with this question, but at the moment I am a Mandrake user (and planning to install Gentoo on a new Sempron box), so I am not well-informed about these Gentoo issues.

By the way, the Jackass Project sounds very interesting to me and I will give it a try!

[Bob P]

well, depending upon how you look at it, the answer can be yes or no. experienced gentoo users know that resyncing and performing an update can be dangerous -- you run the risk of borking a completely functional system in the name of keeping it up to date. as a result, most experienced users tend to plan their updates to be performed at convenient times, so that troubleshooting can be performed if a problem is encountered. naive users tend to perform updates in cron jobs because they want to have the most up to date system on their block. that approach invariably leads to problems that crop up at inconvenient times. most experienced Gentoo users typically follow the "if it ain't broke don't fix it" philosophy, especially when it comes to the toolkit.

i'm not saying that you should never sync. but i would recommend that you are conscientious about what you do after you resync, so that you don't go blindly overwriting your toolkit components by performing a naive command such as emerge -uD world. my personal recommendation would be to install Jackass! using the portage snapshot on the CD, and resync after you finish the install. then, i would suggest using hielvc's or minderaser's update scripts to keep your world packages up to date without allowing the update process to bugger-up your toolkit.

Edit: Link to Update Scripts: http://forums.gentoo.org/viewtopic-t-282474.html

[Hikaru79]

well, depending upon how you look at it, the answer can be yes or no. experienced gentoo users know that resyncing and performing an update can be dangerous -- you run the risk of borking a completely functional system in the name of keeping it up to date. as a result, most experienced users tend to plan their updates to be performed at convenient times, so that troubleshooting can be performed if a problem is encountered. naive users tend to perform updates in cron jobs because they want to have the most up to date system on their block. that approach invariably leads to problems that crop up at inconvenient times. most experienced Gentoo users typically follow the "if it ain't broke don't fix it" philosophy, especially when it comes to the toolkit.

i'm not saying that you should never sync. but i would recommend that you are conscientious about what you do after you resync, so that you don't go blindly overwriting your toolkit components by performing a naive command such as emerge -uD world. my personal recommendation would be to install Jackass! using the portage snapshot on the CD, and resync after you finish the install. then, i would suggest using hielvc's or minderaser's update scripts to keep your world packages up to date without allowing the update process to bugger-up your toolkit.

So, then, what packages is it safe to update, and which are not? I'm assuming that I shouldn't let Portage "update" my gcc if I'm using Jackass.. but is there anything else?
Also, could you address my last post? (two above this one?)

Thanks, Bob

[Bob P]

One more question -- I'm really liking Jackass, so I'd like to also install it on my friend's computer. His processor is marked as "Intel Celeron" ... it's not a Pentium, although it is by Intel. Does that mean that none of the Jackass tarballs are appropriate for him? Or is Celeron equivalent to one of the P arches? And if not, if I just do a regular gentoo install, what should his mtune and march flags be set to?

Thanks in advance!

technically speaking, Gentoo and GCC don't recognize Celerons as being any different than the Pentium processors from which they are derived because a Celeron is typically just a Pentium that has been intentionally crippled by a smaller L2 cache. They maintain the same CPU instruction sets as their Pentium counterparts, so they are configured as a Pentium-whatever when it comes to configuring Gentoo.

So here's the answer -- you need to decide which Pentium processor your Celeron is derived from, and use that ISO image. You won't need to change anything as far as arches are concerned. A good place to start would be by looking at the output of cat /proc/cpuinfo. For more info, read man gcc or look here:

http://gcc.gnu.org/onlinedocs/gcc-3.4.3 ... 64-Options

[Bob P]

So, then, what packages is it safe to update, and which are not? I'm assuming that I shouldn't let Portage "update" my gcc if I'm using Jackass.. but is there anything else?

like i said before, syncing is a crapshoot.

[Bob P]

so far, so good... over 1,000 Jackass! Project ISO downloads this week and no Jackass!-specific problems in the Support Thread...

[obsidianblackhawk]

so far, so good... over 1,000 Jackass! Project ISO downloads this week and no Jackass!-specific problems in the Support Thread...

yay we do good work.

[Jorbless]

So here's the answer -- you need to decide which Pentium processor your Celeron is derived from, and use that ISO image. You won't need to change anything as far as arches are concerned. A good place to start would be by looking at the output of cat /proc/cpuinfo.

The Safe Cflags page at the Gentoo Linux Wiki provides a nice way to distinguish between the incarnations of the Celeron via the CPU family and model gleaned from cat /proc/cpuinfo. The apparent consensus, though, is that the -O3 optimization setting may result in degraded performance versus -O2 due to the smaller cache size found in Celerons (and Durons: the AMD counterparts).

BTW, I'm installing Jackass! now on my old dual PIII rig. Thanks for putting this project together! I can see you guys put quite a bit of effort into this. But, don't worry; I'll be sure to complain if I break something...

[Bob P]

So here's the answer -- you need to decide which Pentium processor your Celeron is derived from, and use that ISO image. You won't need to change anything as far as arches are concerned. A good place to start would be by looking at the output of cat /proc/cpuinfo.

The Safe Cflags page at the Gentoo Linux Wiki provides a nice way to distinguish between the incarnations of the Celeron via the CPU family and model gleaned from cat /proc/cpuinfo. The apparent consensus, though, is that the -O3 optimization setting may result in degraded performance versus -O2 due to the smaller cache size found in Celerons (and Durons: the AMD counterparts).

thanks for posting that link to the Wiki. that page will be very helpful for anyone who's trying to configure a Celeron system. actually, that information should probably be posted in the FAQ page here on the Gentoo Forums if it isn't there already.

on the subject of -O2 vs. -O3 optimization, we've really beaten that subject to death in the Portage & Programming forum, in the CFLAGS Central thread, and in the Stage 1/3 discussion threads. my personal benchmarking has shown that -O3 does indeed result in performance increases over -O2, even on the lowly 133 MHz Intel Pentium Classic that has 0 kb of L2 cache, on the K6-233 that has 64 kb of L2 cache, and on various PPro and P3 systems with 256 kb of L2 cache. I've never actually tested Celerons, but interpolating the data obtained from boxes with larger and smaller L2 cache sizes, I can see no reason to believe that they should behave differently.

So if the question of the decreased size of the L2 cache on a Celeron is sufficient to make anyone think about not using Jackass! because it was built with -O3 instead of -O2, I would recommend that they consider their options: you can use Jackass! as it is, or you can build a similar system to your specifications... which could take a VERY long time...

[Jorbless]

on the subject of -O2 vs. -O3 optimization, we've really beaten that subject to death in the Portage & Programming forum, in the CFLAGS Central thread, and in the Stage 1/3 discussion threads.

Argh. I guess I need to scan those over. I ain't tryin' to start nothin'!

my personal benchmarking has shown that -O3 does indeed result in performance increases over -O2, even on the lowly 133 MHz Intel Pentium Classic that has 0 kb of L2 cache, on the K6-233 that has 64 kb of L2 cache, and on various PPro and P3 systems with 256 kb of L2 cache.

Hey, that's cool! I, personally, have no stake in the -O2 vs. -O3 debate--hence, my use of the weasel-words "apparent" and "may." I've seen quite a bit of posturing and shit-flinging over the issue elsewhere but have not seen actual references to actual benchmarks before. I'll go check out those threads. Thanks for the edification.

Edit: The reason I mentioned it at all was due to my erroneous recollection that the <PIII stages of Jackass! were given -O2 optimization settings. I'm guessing that the delerium I experienced at 4 a.m. while reading through the Jackass! threads and documentation is to blame...

[Bob P]

Edit: The reason I mentioned it at all was due to my erroneous recollection that the <PIII stages of Jackass! were given -O2 optimization settings. I'm guessing that the delerium I experienced at 4 a.m. while reading through the Jackass! threads and documentation is to blame...

to clarify this, we built Jackass! for all architectures using -O3 optimization levels in make.conf.

OTOH, we did nothing to prevent ebuilds from reducing the optimization level from -O3 to -O2 in situations where the ebuild maintainer decided that -O3 would break their ebuild. this is the case when compiling some toolkit components such as glibc and gcc.

a little investigation on my part showed that the ebuild maintainers who were stripping-off -O3 and replacing it with -O2 were not bothering to check for the presence of the CFLAGS that are added when moving from the -O2 specification to the -O3 specification: -fweb and -frename-registers.

for this reason, i decided to out-fox the foxes by redundantly specifying the subset of CFLAGS that are normally added when stepping-up from the -O2 to the -O3 optimization levels -- namely, -fweb and -frename-registers. the idea behind this was that even if some crafty ebuild maintainer decided to throw away the -O3 optimizations in favor of -O2 optimizations, we would still retain as much -O3 optimization as possible by redundantly specifying -fweb and -frename-registers.

[artificio]

I'm having some difficulties emerging visualboyadvance, it starts fine but then it gets to this point and freezes

Code: Select all

  -c -o unzip.o `test -f '../unzip.cpp' || echo './'`../unzip.cpp; \
then mv -f ".deps/unzip.Tpo" ".deps/unzip.Po"; \
else rm -f ".deps/unzip.Tpo"; exit 1; \
fi
if i686-pc-linux-gnu-g++ -DPACKAGE_NAME=\"\" -DPACKAGE_TARNAME=\"\" -DPACKAGE_VERSION=\"\" -DPACKAGE_STRING=\"\" -DPACKAGE_BUGREPORT=\"\" -DPACKAGE=\"VisualBoyAdvance\" -DVERSION=\"1.7.2\" -DYYTEXT_POINTER=1 -DHAVE_LIBZ=1 -DHAVE_LIBPNG=1 -DHAVE_LIBPTHREAD=1 -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_MALLOC_H=1 -DHAVE_STRINGS_H=1 -DHAVE_UNISTD_H=1 -DHAVE_ARPA_INET_H=1 -DHAVE_NETINET_IN_H=1  -I. -I.  -I../../src -DSDL -DSYSCONFDIR=\"/etc/games\"  -fno-exceptions -I/usr/include/SDL -D_REENTRANT -march=pentium4 -mtune=pentium4 -pipe -O2 -fweb -frename-registers -fforce-addr -momit-leaf-frame-pointer -fomit-frame-pointer -ftracer -fvisibility-inlines-hidden -DC_CORE -DPROFILING -DDEV_VERSION -MT TestEmu.o -MD -MP -MF ".deps/TestEmu.Tpo" \
  -c -o TestEmu.o `test -f 'TestEmu.cpp' || echo './'`TestEmu.cpp; \
then mv -f ".deps/TestEmu.Tpo" ".deps/TestEmu.Po"; \
else rm -f ".deps/TestEmu.Tpo"; exit 1; \
fi

and starts to completely fill up my ram and swap from there on.

Code: Select all

Portage 2.0.51.19 (default-linux/x86/2005.0, gcc-3.4.3-20050110, glibc-2.3.5-r0, 2.6.11-gentoo-r6 i686)
=================================================================
System uname: 2.6.11-gentoo-r6 i686 Intel(R) Pentium(R) 4 CPU 2.80GHz
Gentoo Base System version 1.4.16
Python:              dev-lang/python-2.3.4-r1 [2.3.4 (#1, Apr 28 2005, 01:36:14)]
ccache version 2.3 [enabled]
dev-lang/python:     2.3.4-r1
sys-apps/sandbox:    [Not Present]
sys-devel/autoconf:  2.59-r6, 2.13
sys-devel/automake:  1.7.9-r1, 1.8.5-r3, 1.5, 1.4_p6, 1.6.3, 1.9.4
sys-devel/binutils:  2.15.92.0.2-r7
sys-devel/libtool:   1.5.14
virtual/os-headers:  2.6.8.1-r2
ACCEPT_KEYWORDS="x86"
AUTOCLEAN="yes"
CFLAGS="-march=pentium4 -mtune=pentium4 -pipe -O3 -fweb -frename-registers -fforce-addr -momit-leaf-frame-pointer -fomit-frame-pointer -ftracer"
CHOST="i686-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.3/env /usr/kde/3.3/share/config /usr/kde/3.3/shutdown /usr/kde/3/share/config /usr/lib/X11/xkb /usr/lib/mozilla/defaults/pref /usr/share/config /var/qmail/control"
CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d"
CXXFLAGS="-march=pentium4 -mtune=pentium4 -pipe -O3 -fweb -frename-registers -fforce-addr -momit-leaf-frame-pointer -fomit-frame-pointer -ftracer -fvisibility-inlines-hidden"
DISTDIR="/usr/portage/distfiles"
FEATURES="autoaddcvs autoconfig ccache distlocks sandbox sfperms strict"
GENTOO_MIRRORS="http://distfiles.gentoo.org http://distro.ibiblio.org/pub/Linux/distributions/gentoo"
MAKEOPTS="-j3"
PKGDIR="/usr/portage/packages"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
PORTDIR_OVERLAY="/usr/local/portage"
SYNC="rsync://rsync.gentoo.org/gentoo-portage"
USE="x86 X alsa apm arts avi berkdb bitmap-fonts cdr crypt cups curl eds emboss encode esd fam flac foomaticdb fortran gdbm gif gnome gpm gstreamer gtk gtk2 imlib ipv6 java jpeg junit kde libg++ libwww mad mikmod motif mozilla mp3 mpeg ncurses nls nptl ogg oggvorbis opengl oss pam pdflib perl png python qt quicktime readline sdl spell ssl svga tcpd tiff truetype truetype-fonts type1-fonts vorbis xml2 xmms xv zlib userland_GNU kernel_linux elibc_glibc"
Unset:  ASFLAGS, CBUILD, CTARGET, LANG, LC_ALL, LDFLAGS, LINGUAS

The same thing happens for the stable/unstable and since I didn't see it happen with my last (non-jackass) system I'm thinking it might have something to do with the ~x86 gcc that's being used? This looks like it might be related...
https://bugzilla.redhat.com/bugzilla/sh ... i?id=31016
Can I just rememerge a version that I know will work to emerge visualboyadvance, or will that completely screw things up?

[Sith_Happens]

Try Commenting out some of the lower CFLAGS lines in your make.conf and re-emerging (now you see why we have them on seperate lines ). If it doesn't compile with a minimum of CFLAGS, such as simply an march flag, then it is probably an incompatibility this package has with GCC 3.4.3. In that case you should post it to Gentoo's Bugzilla and let them sort out what the problem is. Sorry I can't be more helpful.

[artificio]

You couldn't have been more helpful! Although I'm kicking myself, because what I came across was a bug involving -O3. Once I commented that out it was smooth sailing, thanks a lot!

[Sith_Happens]

You couldn't have been more helpful! Although I'm kicking myself, because what I came across was a bug involving -O3. Once I commented that out it was smooth sailing, thanks a lot!

Ah, good stuff.