| View previous topic :: View next topic |
| Author |
Message |
Bob P
Advocate
Joined: 20 Oct 2004
Posts: 3355
Location: Jackass! Development Labs
|
 Posted: Sun Mar 13, 2005 2:35 pm Post subject: |
 |
|
| Sheepdogj15 wrote: | | oh shoot... you comment on it in the OPENING POST |
directions? we don't need no stinking directions!
_________________
.
Stage 1/3 | Jackass! | Rockhopper! | Thanks | Google Sucks |
|
| Back to top |
|
 |
nelix
n00b
Joined: 22 Dec 2003
Posts: 30
Location: Melbourne Australia
|
| Posted: Tue Mar 15, 2005 1:39 pm Post subject: thinking |
|
|
I'm thinking about 2005.0...
I'm thinking this is still a nice method of install even once the 2005.0 profiles are released, because its still nice to have a working system up in say 15 minutes and then going on to optimize it while i am using it.
Its still good for new gcc builds etc with the information about what order to build your toolchain in.
and i am sure we can find other things to add, just as a general more avanced search guide.
_________________
eof |
|
| Back to top |
|
|
kimchi_sg
Advocate
Joined: 26 Nov 2004
Posts: 2969
|
| Posted: Tue Mar 15, 2005 1:51 pm Post subject: |
|
|
I've changed my mind about 2005.0 being "good enough to eat off of". The final straw was a few hours ago when I needed to re-install and found out to my horror, that the 2005.0rc5 CD could not detect my motherboard's onboard NIC when I had a PCI NIC of the same type (both use the Realtek 8139too module). And since I am planning to use that box as a router, this was unacceptable.
Also, earlier before that, my daily emerge -uvDa --newuse world picked up no less than 17 packages that had been emerged during bootstrapping with the "build" or "bootstrap" USE flags, but were NOT re-emerged during emerge system without these flags. 
I'm back to 2004.3 for now. And somehow, I feel that this install method will be the superior way to install a rock solid, stable system for some time. Probably until 2006.0 comes out.  |
|
| Back to top |
|
|
nelix
n00b
Joined: 22 Dec 2003
Posts: 30
Location: Melbourne Australia
|
| Posted: Tue Mar 15, 2005 2:03 pm Post subject: |
|
|
btw how long before 2005.0 final is out? seems like this rebuild is taking forever
_________________
eof |
|
| Back to top |
|
|
kimchi_sg
Advocate
Joined: 26 Nov 2004
Posts: 2969
|
| Posted: Tue Mar 15, 2005 2:11 pm Post subject: |
|
|
| nelix wrote: | | btw how long before 2005.0 final is out? seems like this rebuild is taking forever |
Never mind how long the devs take, unless you've got hardware problems with the 2004.3 liveCD, 2004.3 is still fighting fit. 
Tip for compiling gcc
I've gotten into the habit of compiling gcc with the "boundschecking" USE flag. This flag is good to use on non-hardened systems. It enables the HTB bounds checking patches for gcc, and at the same time skips building the hardened gcc profiles. So it saves quite a bit of time on compiling gcc, like the nptlonly flag does for glibc. And it makes gcc check for wild pointers in the source code being compiled - another Good Thing.
If you want to enable bounds checking on your gcc when installing stage 1-on-3, insert this line at the same time as when you enable glibc's "userlocales" USE flag in package.use:
| Code: | echo "sys-libs/glibc userlocales" >> /etc/portage/package.use
echo "sys-devel/gcc boundschecking" >> /etc/portage/package.use |
This is to be done before the first round of compiling the toolchain! |
|
| Back to top |
|
|
nelix
n00b
Joined: 22 Dec 2003
Posts: 30
Location: Melbourne Australia
|
| Posted: Tue Mar 15, 2005 3:43 pm Post subject: |
|
|
2005.0 release would be nice for me, i have 6 systems i want to update to 2.6 headers and udev (i am aware that i can do this manualy) and 4 of those systems are the same and have issues with doscsi and are VERY out of date so i figure its much easyer to just clean install and redesign all of them.... Well thats my reasoning for wanting 2005.0.
sorry for going off topic but i just thought i would justify my self
_________________
eof |
|
| Back to top |
|
|
kimchi_sg
Advocate
Joined: 26 Nov 2004
Posts: 2969
|
| Posted: Tue Mar 15, 2005 3:49 pm Post subject: |
|
|
| nelix wrote: | 2005.0 release would be nice for me, i have 6 systems i want to update to 2.6 headers and udev (i am aware that i can do this manualy) and 4 of those systems are the same and have issues with doscsi and are VERY out of date so i figure its much easyer to just clean install and redesign all of them.... Well thats my reasoning for wanting 2005.0.
sorry for going off topic but i just thought i would justify my self |
Understood.
A goodie new in the 2005.0 liveCD: selective module loading. That should take the pain out of doscsi. Just load 1 of the modules without probing whether all the rest are needed. There's a mod=[module name] kernel parameter that does that. Nice.
Now if i can figure out how to make it recognise both my network cards at once...  |
|
| Back to top |
|
|
Bob P
Advocate
Joined: 20 Oct 2004
Posts: 3355
Location: Jackass! Development Labs
|
| Posted: Tue Mar 15, 2005 4:33 pm Post subject: |
|
|
my impression of 2005.0-rc5 has been less than encouraging, but for a different reason -- i have three criteria that have to be met in order for me to stop using the Stage 1/3 installation method. failure to meet any one of the criteria is a dealbreaker.
1. the var/db/pkg in the 2005.0 Stage 1 tarball has to be complete.
2. circular dependencies have to be eliminated in the base system.
3. GCC 3.4.3 (or later) has to be marked as stable and be incorporated into the Live CD.
unfortunately, because GCC 3.4.3 is still in the testing branch, the 2005.0-rc5 Live CD has been released with GCC 3.3.4.
for me, there is absolutely no purpose in performing a Stage 1 installation if bootstrapping will not bring in the GCC 3.4.3 toolkit. bootstrapping with the GCC 3.4.3 toolkit would only require that i have to rebuild the entire toolkit/system and world files after bootstrapping. this seems rather pointless, as there is no point in bootstrapping if the bootstrapped system isn't what you want it to be.
for me, i'll continue to do the Stage 1/3 installation.
_________________
.
Stage 1/3 | Jackass! | Rockhopper! | Thanks | Google Sucks |
|
| Back to top |
|
|
Bob P
Advocate
Joined: 20 Oct 2004
Posts: 3355
Location: Jackass! Development Labs
|
| Posted: Tue Mar 15, 2005 4:34 pm Post subject: |
|
|
now the second question comes along -- how to modify the Stage 1/3 method for use with 2005.0.
for those of you who can't wait for 2005.0 and continue to ask when it will be released, PLEASE STOP!  we are not developers and we have no control over the process. when we ask this question we get the same response that everyone else gets: "it will be out when it is out." so we've stopped asking, and we'd appreciate it if you would do the same.
if you're curious about whether or not this installation method is 2005.0-compliant, the answer is yes. because 2005.0 is distributed with 2.6 kernel-compatible headers, you can omit the steps of unmerging the linux 24 headers and emerging the linux 26 headers. beyond that, no changes appear necessary.
 please keep this in mind: 2005.0 remains experimental and has not been officially released. this Stage 1/3 installation method remains a method of building a robust and bulletproof installation. 2005.0 as an experimental distribution compromises the integrity of this installation method. until 2005.0 is no longer marked experimental, this guide will not be officially updated to support 2005.0. if you choose to install 2005.0, you do so at your own risk. please do not ask questions about it here. this guide is for 2004.3 and 2005.0 questions will not be answered.
EDIT: New Thread started for all 2005.0 related posts:
https://forums.gentoo.org/viewtopic-p-2204186.html
_________________
.
Stage 1/3 | Jackass! | Rockhopper! | Thanks | Google Sucks
Last edited by Bob P on Fri Mar 18, 2005 1:59 am; edited 1 time in total |
|
| Back to top |
|
|
slycordinator
Advocate
Joined: 31 Jan 2004
Posts: 3065
Location: Korea
|
| Posted: Tue Mar 15, 2005 8:43 pm Post subject: |
|
|
I think there needs to be a simple change made to this guide.
In section "7.1 Building the Toolkit: GCC 3.3.4."
Change
| Code: | | emerge gcc-config glibc binutils gcc |
to
| Code: | | emerge --nodeps gcc-config glibc binutils gcc |
And similarly in "7.2.4 Rebuilding the System Toolkit"
Change
| Code: | | emerge glibc binutils gcc portage |
to
| Code: | | emerge --nodeps glibc binutils gcc portage |
This should be changed because the gcc ebuild now accepts USE="gtk" and if gtk is in your USE flags it will try to install gtk and all of it's dependencies when you try to install the most current gcc. As it stands that will add a TON of extra pointless compile time. |
|
| Back to top |
|
|
kimchi_sg
Advocate
Joined: 26 Nov 2004
Posts: 2969
|
| Posted: Wed Mar 16, 2005 1:31 am Post subject: |
|
|
| slycordinator wrote: | I think there needs to be a simple change made to this guide.
In section "7.1 Building the Toolkit: GCC 3.3.4."
Change
| Code: | | emerge gcc-config glibc binutils gcc |
to
| Code: | | emerge --nodeps gcc-config glibc binutils gcc |
|
That is the most dangerous thing I have heard you to say. What if some of the other dependencies are actually needed? For example, with --nodeps, libstdc++-v3 (which is a PDEPEND of gcc) will not get emerged, as would binutils-config.
Better include "sys-devel/gcc -gtk" in package.use instead. And possibly throw in boundschecking while we are at it. | Code: | | echo "sys-devel/gcc -gtk boundschecking" >> /etc/portage/package.use |
|
|
| Back to top |
|
|
hielvc
Advocate
Joined: 19 Apr 2002
Posts: 2805
Location: Oceanside, Ca
|
| Posted: Wed Mar 16, 2005 2:51 am Post subject: |
|
|
kimchi_sg what is also dangerous is useing "build and bootstrap" in your USE flags. For anyone not totally sure of what theyre doing or nuts like kimchi_sg  they can cause big probs such as not building g++ when it builds your gcc.
_________________
An A-Z Index of the Linux BASH command line |
|
| Back to top |
|
|
kimchi_sg
Advocate
Joined: 26 Nov 2004
Posts: 2969
|
| Posted: Wed Mar 16, 2005 3:38 am Post subject: |
|
|
| hielvc wrote: | | kimchi_sg what is also dangerous is useing "build and bootstrap" in your USE flags. For anyone not totally sure of what theyre doing or nuts like kimchi_sg they can cause big probs such as not building g++ when it builds your gcc. |
What makes you think I actually build my gcc with USE="build bootstrap" ?!  |
|
| Back to top |
|
|
Sysa
Apprentice
Joined: 16 Mar 2005
Posts: 161
Location: Europe
|
| Posted: Wed Mar 16, 2005 10:28 am Post subject: |
|
|
| kimchi_sg wrote: | | slycordinator wrote: | I think there needs to be a simple change made to this guide.
In section "7.1 Building the Toolkit: GCC 3.3.4."
Change
| Code: | | emerge gcc-config glibc binutils gcc |
to
| Code: | | emerge --nodeps gcc-config glibc binutils gcc |
|
That is the most dangerous thing I have heard you to say. What if some of the other dependencies are actually needed? For example, with --nodeps, libstdc++-v3 (which is a PDEPEND of gcc) will not get emerged, as would binutils-config.
Better include "sys-devel/gcc -gtk" in package.use instead. And possibly throw in boundschecking while we are at it. | Code: | | echo "sys-devel/gcc -gtk boundschecking" >> /etc/portage/package.use |
|
I agree with you regarding the --nodeps but maybe it worth to add --newuse instead? I think it could help if somebody does not install from scratch but fix or tune his system in accordance with the recommendations (and adjust the USE!), e.g. as me do . Or you think that it's ~x86 problem too?
_________________
RedHat -> SuSE -> Debian -> Gentoo |
|
| Back to top |
|
|
kimchi_sg
Advocate
Joined: 26 Nov 2004
Posts: 2969
|
| Posted: Wed Mar 16, 2005 10:36 am Post subject: |
|
|
| Sysa wrote: | | I agree with you regarding the --nodeps but maybe it worth to add --newuse instead? I think it could help if somebody does not install from scratch but fix or tune his system in accordance with the recommendations (and adjust the USE!), e.g. as me do . |
If you already have an installed system, stop looking at this topic. This topic is about building the toolchain on a fresh install of the system.
The bash wrapper script mentioned here is the more correct way to maintain the toolchain on an already installed system. |
|
| Back to top |
|
|
Bob P
Advocate
Joined: 20 Oct 2004
Posts: 3355
Location: Jackass! Development Labs
|
| Posted: Wed Mar 16, 2005 4:38 pm Post subject: |
|
|
| slycordinator wrote: | I think there needs to be a simple change made to this guide.
In section "7.1 Building the Toolkit: GCC 3.3.4."
Change
| Code: | | emerge gcc-config glibc binutils gcc |
to
| Code: | | emerge --nodeps gcc-config glibc binutils gcc |
And similarly in "7.2.4 Rebuilding the System Toolkit"
Change
| Code: | | emerge glibc binutils gcc portage |
to
| Code: | | emerge --nodeps glibc binutils gcc portage |
This should be changed because the gcc ebuild now accepts USE="gtk" and if gtk is in your USE flags it will try to install gtk and all of it's dependencies when you try to install the most current gcc. As it stands that will add a TON of extra pointless compile time. |
this is an interesting problem. although i haven't had a chance to verify the problem, i can give a preliminary response. i have never noticed the issue because i have never noticed gtk being emerged on the test systems. on the test systems, the install took an entire week and i wasn't glued to the chair -- so if gtk got emerged, i could have missed it. on my personal systems, i have gtk disabled in my use flags, which prevented the problem from occurring.
like kimchi_sg pointed out, libstdc++-v3 is not explicitly emerged but is emerged implicitly in that step. (it gets pulled in as a dependency). this means that if you specify --nodeps on the command line, you will prevent the emergence of libstdc++-v3. that would not be good.
so if this is indeed a problem, then it seems that a better approach would be to disable gtk from being emerged by controlling it through the use of USE flags. one could do this with a global USE="-gtk" type of flag, which would be appropriate during the process of installation, or one could do it with a package-specific USE flag like kimchi_sg recommended.
i have to admit, i do not yet know why gcc responds to the gtk USE flag, so it would be premature to comment on the use of a package-specific use flag in package.use if the user ultimately intends to emerge gtk.
on the subject of saving compile time, while it certainly seems unnecessary at this point to emerge gtk, again i have to admit that i have no idea if gtk actually gets emerged -- in developing the guide, it did one heck of alot of pretend emerges of gcc, and i NEVER saw gtk being proposed, even on the systems that did not explicitly specify USE="-gtk". if gtk does indeed emerge as a dependency of gcc in that step, can you tell me which version of gcc this behavior started with?
as another consideration, i don't think that the redundant compilations would be as extensive as you have suggested. dependencies aren't re-compiled on the second pass if they already exist. so if the problem does exist, at worst, gtk would be emerged once. as it ultimately becomes part of the world file and not the system, it would also be skipped during "emerge -e system", wouldn't it?
i appreciate the heads-up on this potential problem. until i have a chance to verify that the problem does indeed exist, it would be premature to think about altering the guide. similarly, we have to test the solutions for reliability before we just throw them into the guide. from a safety/reliability perspective, its better to allow some potentially unnecessary compilation than it would be to potentially break the installation method until we've found the definitive answer.
if anyone's performing a de novo installation, i'd appreciate some feedback including your obvservations until i have a chance to get a better handle on this.
_________________
.
Stage 1/3 | Jackass! | Rockhopper! | Thanks | Google Sucks |
|
| Back to top |
|
|
Bob P
Advocate
Joined: 20 Oct 2004
Posts: 3355
Location: Jackass! Development Labs
|
| Posted: Wed Mar 16, 2005 5:13 pm Post subject: |
|
|
| Sysa wrote: | | I agree with you regarding the --nodeps but maybe it worth to add --newuse instead? I think it could help if somebody does not install from scratch but fix or tune his system in accordance with the recommendations (and adjust the USE!), e.g. as me do . Or you think that it's ~x86 problem too? |
i can't see any valid reason to specify "--newuse" on a de novo system installation. 
_________________
.
Stage 1/3 | Jackass! | Rockhopper! | Thanks | Google Sucks |
|
| Back to top |
|
|
kimchi_sg
Advocate
Joined: 26 Nov 2004
Posts: 2969
|
| Posted: Wed Mar 16, 2005 6:07 pm Post subject: |
|
|
| Bob P wrote: | | slycoordinator wrote: | | This should be changed because the gcc ebuild now accepts USE="gtk" and if gtk is in your USE flags it will try to install gtk and all of it's dependencies when you try to install the most current gcc. |
this is an interesting problem. although i haven't had a chance to verify the problem, i can give a preliminary response. i have never noticed the issue because i have never noticed gtk being emerged on the test systems. |
This gtk dependency hypothesis is hereby Officially Disproved.
| Code: | livecd / # USE="gtk" emerge -pv gcc-config glibc binutils gcc
These are the packages that I would merge, in order:
Calculating dependencies ...done!
[ebuild U ] sys-devel/gcc-config-1.4.0 [1.3.8-r3] 0 kB
[ebuild U ] sys-libs/glibc-2.3.4.20050125-r1 [2.3.4.20040808-r1] -build -debug +erandom* -hardened (-multilib) +nls +nomalloccheck* +nptl* +nptlonly* +pic* +userlocales* 15,299 kB
[ebuild N ] sys-devel/binutils-config-1.8-r1 0 kB
[ebuild U ] sys-devel/binutils-2.15.92.0.2-r6 [2.15.90.0.1.1-r3] -debug -multislot -multitarget +nls -test (-uclibc) 10,790 kB
[ebuild NS ] sys-devel/gcc-3.4.3.20050110 -bootstrap +boundschecking -build -debug -fortran -gcj +gtk -hardened (-ip28) (-multilib) -multislot (-n32) (-n64) +nls -nocxx -objc -static (-uclibc) 27,896 kB
[ebuild N ] sys-libs/libstdc++-v3-3.3.4 -debug +nls 22,784 kB
Total size of downloads: 76,772 kB |
Good thing you caught me doing yet another reinstall.
But it makes me wonder, why the vapier, eradicator and co would put a dummy USE flag into the gcc ebuild.
EDIT: Never mind, a little sleuthing inside the toolchain eclass has turned up this nugget which is the only location where the GTK flag makes a difference:
| Code: | gcc-compiler-configure() {
# multilib support
if is_multilib; then
confgcc="${confgcc} --enable-multilib"
else
confgcc="${confgcc} --disable-multilib"
fi
# GTK+ is preferred over xlib in 3.4.x (xlib is unmaintained
# right now). Much thanks to <csm@gnu.org> for the heads up.
# Travis Tilley <lv@gentoo.org> (11 Jul 2004)
if ! is_gcj ; then
confgcc="${confgcc} --disable-libgcj"
elif use gtk ; then
confgcc="${confgcc} --enable-java-awt=gtk"
fi |
Seems that USE="gtk" affects only the building of the AWT GUI for the gcj compiler - which won't be built unless you've turned on USE="gcj", of course. So for most people, it won't make a difference. |
|
| Back to top |
|
|
kimchi_sg
Advocate
Joined: 26 Nov 2004
Posts: 2969
|
| Posted: Wed Mar 16, 2005 6:34 pm Post subject: addendum to the above post |
|
|
Here's a little postscript to my previous post, since links is refusing to let me edit my previous one in its entirety.
For those who want to splunk in the gcc ebuild, don't. They're all wafer thin in terms of length. All the meat (in other words, the specifications for what goes on during gcc compilation) is inside the toolchain eclass. That eclass probably takes the Grand Prize for efficiency in code reuse. |
|
| Back to top |
|
|
Bob P
Advocate
Joined: 20 Oct 2004
Posts: 3355
Location: Jackass! Development Labs
|
| Posted: Wed Mar 16, 2005 6:38 pm Post subject: |
|
|
| slycordinator wrote: | I think there needs to be a simple change made to this guide.
In section "7.1 Building the Toolkit: GCC 3.3.4."
Change
| Code: | | emerge gcc-config glibc binutils gcc |
to
| Code: | | emerge --nodeps gcc-config glibc binutils gcc |
And similarly in "7.2.4 Rebuilding the System Toolkit"
Change
| Code: | | emerge glibc binutils gcc portage |
to
| Code: | | emerge --nodeps glibc binutils gcc portage |
|
as a preliminary test of this theory, this output is obtained when USE includes no reference to "gtk" (maximize your browser window for improved readability):
| Code: | gentoo root # emerge --newuse gcc-config glibc binutils gcc -vp
These are the packages that I would merge, in order:
Calculating dependencies ...done!
[ebuild R ] sys-devel/gcc-config-1.3.10-r1 0 kB
[ebuild R ] sys-libs/glibc-2.3.4.20050125 -build -debug -erandom -hardened (-multilib) +nls -nomalloccheck +nptl -nptlonly -pic +userlocales 0 kB
[ebuild R ] sys-devel/binutils-2.15.92.0.2-r1 -bootstrap -build -debug -multitarget +nls (-uclibc) 0 kB
[ebuild R ] sys-devel/gcc-3.4.3.20050110 -bootstrap -boundschecking -build -debug +fortran -gcj +gtk* -hardened (-ip28) (-multilib) -multislot (-n32) (-n64) +nls -nocxx -objc -static (-uclibc) 0 kB
Total size of downloads: 0 kB |
in contrast, this is what the same command's output looks like when USE="-gtk":
| Code: | gentoo root # emerge --newuse gcc-config glibc binutils gcc -vp
These are the packages that I would merge, in order:
Calculating dependencies ...done!
[ebuild R ] sys-devel/gcc-config-1.3.10-r1 0 kB
[ebuild R ] sys-libs/glibc-2.3.4.20050125 -build -debug -erandom -hardened (-multilib) +nls -nomalloccheck +nptl -nptlonly -pic +userlocales 0 kB
[ebuild R ] sys-devel/binutils-2.15.92.0.2-r1 -bootstrap -build -debug -multitarget +nls (-uclibc) 0 kB
[ebuild R ] sys-devel/gcc-3.4.3.20050110 -bootstrap -boundschecking -build -debug +fortran -gcj -gtk -hardened (-ip28) (-multilib) -multislot (-n32) (-n64) +nls -nocxx -objc -static (-uclibc) 0 kB |
the difference is "+gtk*" in the first case vs. "-gtk" in the second case.
what does the asterisk mean?
am i missing something, or is gtk not going to be emerged when either command is executed?
EDIT: kimchi_sg beat me to the punch. 
_________________
.
Stage 1/3 | Jackass! | Rockhopper! | Thanks | Google Sucks |
|
| Back to top |
|
|
Bob P
Advocate
Joined: 20 Oct 2004
Posts: 3355
Location: Jackass! Development Labs
|
| Posted: Wed Mar 16, 2005 7:19 pm Post subject: |
|
|
kimchi_sg, this is for you:
| Code: | cd /var/db/pkg
for p in $(grep -RiH ^KEYWORDS * | grep ~x86 | cut -d / -f -2); do echo ${p} ~x86; done >> /etc/portage/package.keywords.bob |
_________________
.
Stage 1/3 | Jackass! | Rockhopper! | Thanks | Google Sucks |
|
| Back to top |
|
|
96140
Retired Dev
Joined: 23 Jan 2005
Posts: 1324
|
| Posted: Wed Mar 16, 2005 7:55 pm Post subject: |
|
|
--
Last edited by 96140 on Fri Sep 13, 2013 9:50 am; edited 1 time in total |
|
| Back to top |
|
|
Bob P
Advocate
Joined: 20 Oct 2004
Posts: 3355
Location: Jackass! Development Labs
|
|
| Back to top |
|
|
kimchi_sg
Advocate
Joined: 26 Nov 2004
Posts: 2969
|
| Posted: Thu Mar 17, 2005 7:18 am Post subject: Tip: Styles can be applied quickly to selected text. |
|
|
I had to satisfy my curiousity so I tried this just to see if it was really GCJ that listened for the gtk USE flag.
| Code: | livecd / # USE="gcj gtk" emerge -pv glibc binutils gcc portage
These are the packages that I would merge, in order:
Calculating dependencies ...done!
[ebuild R ] sys-libs/glibc-2.3.4.20050125-r1 -build -debug +erandom -hardened (-multilib) +nls +nomalloccheck +nptl +nptlonly +pic +userlocales 0 kB
[ebuild R ] sys-devel/binutils-2.15.92.0.2-r6 -debug -multislot -multitarget +nls -test (-uclibc) 0 kB
[ebuild N ] dev-util/pkgconfig-0.15.0 596 kB
[ebuild N ] media-libs/libart_lgpl-2.3.17 -debug 282 kB
[ebuild N ] media-libs/libpng-1.2.8 -debug 375 kB
[ebuild N ] media-libs/freetype-2.1.9-r1 -bindist -debug -doc +zlib 969 kB
[ebuild N ] x11-misc/ttmkfdir-3.0.9-r2 -debug 19 kB
[ebuild N ] x11-base/opengl-update-2.1.1-r1 37 kB
[ebuild N ] media-libs/fontconfig-2.2.3 732 kB
[ebuild N ] x11-base/xorg-x11-6.8.2-r1 +3dfx -3dnow +bitmap-fonts +cjk -debug -dlloader -dmx -doc -font-server -hardened -insecure-drivers -ipv6 -minimal +mmx +nls +opengl -pam -sdk +sse -static +truetype-fonts +type1-fonts (-uclibc) -xprint +xv 45,094 kB
[ebuild N ] app-arch/rpm2targz-9.0-r2 2 kB
[ebuild N ] sys-apps/utempter-0.5.5.5-r1 -debug 20 kB
[ebuild N ] x11-terms/xterm-200 -Xaw3d -debug -toolbar +truetype +unicode 681 kB
[ebuild NS ] dev-libs/glib-2.6.3 -debug -doc 2,246 kB
[ebuild N ] dev-libs/atk-1.9.1 -debug -doc -static 472 kB
[ebuild N ] media-libs/jpeg-6b-r4 -debug 598 kB
[ebuild N ] x11-libs/pango-1.8.1 -debug -doc -static 973 kB
[ebuild N ] dev-perl/XML-Parser-2.34 224 kB
[ebuild N ] dev-util/intltool-0.32.1 121 kB
[ebuild N ] dev-libs/libxml2-2.6.17 -debug -ipv6 -python +readline 2,995 kB
[ebuild N ] x11-misc/shared-mime-info-0.15 412 kB
[ebuild N ] x11-libs/gtk+-2.6.4 -debug -doc +jpeg -static -tiff 10,985 kB
[ebuild R ] sys-devel/gcc-3.4.3.20050110 -bootstrap -boundschecking -build -debug -fortran +gcj* +gtk* -hardened (-ip28) (-multilib) -multislot (-n32) (-n64) +nls -nocxx -objc -static (-uclibc) 0 kB
[ebuild U ] sys-apps/portage-2.0.51.19 [2.0.51-r3] -build -debug (-selinux) 277 kB
Total size of downloads: 68,119 kB |
Note to self: gcc seems strangely broken in the 2005.0 x86 stage 3 tarball. emerging gcc dies if boundchecking is enabled. |
|
| Back to top |
|
|
Bob P
Advocate
Joined: 20 Oct 2004
Posts: 3355
Location: Jackass! Development Labs
|
| Posted: Thu Mar 17, 2005 7:23 pm Post subject: |
|
|
| Quote: | | I had to satisfy my curiousity so I tried this just to see if it was really GCJ that listened for the gtk USE flag. |
Yikes! 
| Quote: | | Note to self: gcc seems strangely broken in the 2005.0 x86 stage 3 tarball. emerging gcc dies if boundchecking is enabled. |
i have also seen problems with b0rken GCC behavior in 2005.3 x86 Stage 3. Stay away from it.
_________________
.
Stage 1/3 | Jackass! | Rockhopper! | Thanks | Google Sucks |
|
| Back to top |
|
|
|
Documentation, Tips & Tricks
