During bootstrap /dev/null is being changed to a regular file causeing glibc to fail suring bootstrap. This hasnt happened to me but quite a few people are reporting it. This thread gives the best info http://forums.gentoo.org/viewtopic.php?t=229921&start=0&postdays=0&postorder=asc&highlight= I have seen 1 maybe 2 others threads with the same problem.http://forums.gentoo.org/viewtopic.php?t=214084&start=0&postdays=0&postorder=asc&highlight= These guys were useing P4s exegete n00b n00b Joined: 16 Apr 2003 Posts: 3 Location: Flagstaff, AZ Posted: Wed Sep 29, 2004 7:34 am Post subject: Reply with quote I have this same problem. The problem seems to resolve around something going wrong with /dev/null In my case: I go ahead and do this: livecd / # mknod -m 777 /dev/null c 1 3 livecd / # ls -alh /dev/null crwxrwxrwx 1 root root 1, 3 Sep 29 08:32 /dev/null And this is correct. But after I run bootstrap.sh (glibc fails to compile, no surprise): livecd / # ls -alh /dev/null -rw-r--r-- 1 root root 0 Sep 29 08:45 /dev/null Which is obviously totally WRONG because this is now a regular file, not a device. So obviously with something in the file, using /dev/null becomes a problem. I've found that if I cancel bootstrap before texinfo-4.6 install, it still turns to a file, so it's somewhere before this. Something is wrong with bootstrap. make.conf: CFLAGS="-O1 -pipe -fomit-frame-pointer" CHOST="x86_64-pc-linux-gnu" CXXFLAGS="${CFLAGS}" MAKEOPTS="-j2" USE="-X"
ive seen this a few times while making s390 stages
I have the same problems, and reported my error messages here: http://bugs.gentoo.org/show_bug.cgi?id=65910
*** Bug 65910 has been marked as a duplicate of this bug. ***
At what point during the bootstrap is /dev/null created? Can the script be modified / lines commented out as a workaround?
One workaround is to mount -obind /dev /wherever/dev just before chrooting. Not ideal though.
Thanks. I think I'm just going to do a Stage 3 and then recompile everything. It shouldn't take much longer than a Stage 1. More and more posts of these errors are showing up on the forums. I tried a stock 2004.2 Stage 1 following the gentoo installation documentation and I got the same error. Now, I did a stage 1 with no problems about 2 weeks ago. I got a new hard drive so I'm starting over again. I've seen the same errors using: default boot 2.4 kernel smp boot 2.6 kernel using gcc 3.3.x off the 2004.2 live CD using gcc 3.4 both both by manually emerging and gcc-config to switch and by changing make.profile to use 3.4 using nptl and not using nptl using just -O2 flag, and using -O2 -pipe -fPIC using no march under 3.3 for my AMD64 using march=k8 under gcc 3.4.x using no USE flag using my normal USE flags using bootstrap.sh using bootstrap-26.sh using bootstrap-cascade.sh It's definately a bug somewhere in the bootstrap process. Unfortunately the script is pretty much greek to me so I can't help to identify any problem. I can compile glibc on its own with various combinations of gccs and CFLAGS with no problems. The only thing I didn't try that I could think of (as a newer user) was to download an older portage snapshot and hope maybe there was an old version that would work.
*** Bug 66452 has been marked as a duplicate of this bug. ***
Got problems even stage3, And even experimental gcc3.4 stage in /experimental/amd64. I'll try reinstall my system again. MAKEDEV generic-i386 or something will help in bootstrap process ... I will forcus on gcc building today if it's crap. I think portage to have workaround for this situation also, Because portage is merge first when bootstrap or anything (I mean portage itself not ebuild). It can handle it.
Hey, just thought I'd mention - the second forum thread linked to in the original comment has posted a solution; turns out the problem is in flag-o-matic.eclass, of all things ...
ive updated flag-o-matic to not use /dev/null but rather a temp file re-open if this does not solve it for you (make sure your portage tree is updated first :P)
*** Bug 66928 has been marked as a duplicate of this bug. ***
