View previous topic :: View next topic |
Author |
Message |
Naib Watchman
Joined: 21 May 2004 Posts: 6051 Location: Removed by Neddy
|
Posted: Fri May 20, 2005 8:03 am Post subject: |
|
|
mm I thought it was quite obviouse when I didnt have those files (and for a fresh install you wont) to create them.
Out of interest, for the JACKASS does that have those files in its STAGE3 tarball? _________________
Quote: | Removed by Chiitoo |
|
|
Back to top |
|
|
Bob P Advocate
Joined: 20 Oct 2004 Posts: 3355 Location: Jackass! Development Labs
|
Posted: Fri May 20, 2005 3:38 pm Post subject: |
|
|
Naib wrote: | mm I thought it was quite obviouse when I didnt have those files (and for a fresh install you wont) to create them.
Out of interest, for the JACKASS does that have those files in its STAGE3 tarball? |
yes, they were used to build the Jackass! stage 3 tarballs -- there's no way that you can perform a Stage 1/3 without them!
for the people who are unfamiliar with the Stage 1/3 method, the JIH! (Jackass! Installation Handbook) clearly answers this question. It explains why the files exist and gives the user recommendations about when the user may need to edit them.
the only exception where the Jackass! files do not look exactly like the Stage 1/3 files is locales.build. we did not restrict the contents of locales.build in Jackass! in the way that it is recommended in the Stage 1/3 Guide:
with a Stage 1/3 install, the user can decide which user locales are appropriate for his individual needs.
With Jackass! we're compiling a tarball that would be distributed internationally and needed to be compatible with as many languages as possible.
instead of following the Stage 1/3 method of abbreviating the contents of locales.build, when we built Jackass! we decided to emerge all of the default user locales when compiling Glibc -- which took an awful lot of time. we did this to make Jackass! Stage 3 tarballs as internationally-compatible as the Gentoo Stage 3 tarballs which they emulate.
when reading the JIH the user is advised that they may need to edit locales.build to remove any unnecessary user locales before the contemplate re-emerging or updating glibc.
in the Jackass! Project, we're distributing a tarball, and this makes it feasible to actually distribute our configuration files. in the Stage 1/3 Guide, no media is distributed. this makes it impossible to distribute the configuration files, so the user has to create his own. _________________ .
Stage 1/3 | Jackass! | Rockhopper! | Thanks | Google Sucks |
|
Back to top |
|
|
Arainach l33t
Joined: 08 Jul 2004 Posts: 609
|
Posted: Tue May 24, 2005 7:11 pm Post subject: |
|
|
Code: | * Done with patching
* Applying gcc_3_4_3.dif ... [ ok ]
* Updating gcc to use SSP from libc ...
* Applying various patches (bugfixes/updates) ...
* 00_all_gcc-4.0-cvs-incompat.patch.bz2 ... [ ok ]
* 00_all_gcc-4.0-cvs-mips-pic-for-3.4.3.patch.bz2 ... [ ok ]
* 00_all_gcc-4.0-cvs-pic.patch.bz2 ... [ ok ]
* 00_all_gcc-4.0-cvs-start_endfile-for-3.4.3.patch.bz2 ... [ ok ]
* 03_all_gcc-3.4.0-v8.7.6.1-pie-arm.patch.bz2 ... [ ok ]
* 04_all_gcc-3.4.0-v8.7.6.1-pie-arm-uclibc.patch.bz2 ... [ ok ]
* Done with patching
* Applying various patches (bugfixes/updates) ...
* 02_all_gcc-3.4.3-v8.7.1-pie-rs6000-nondefault.patch.bz2 ... [ ok ]
* 02_all_gcc-3.4.3-v8.7.6.7-pie-sparc-nondefault.patch.bz2 ... [ ok ]
* Done with patching
* Applying various patches (bugfixes/updates) ...
* 00_all_gcc-3.4.3-v8.7.6.7-incompat-default.patch.bz2 ... [ ok ]
* 01_all_gcc-3.4.3-v8.7.7-pie-generic-default.patch.bz2 ... [ ok ]
* 02_all_gcc-3.4.3-v8.7.6.7-pie-alpha-default.patch.bz2 ... [ ok ]
* 02_all_gcc-3.4.3-v8.7.6.7-pie-arm-default.patch.bz2 ... [ ok ]
* 02_all_gcc-3.4.3-v8.7.6.7-pie-ia64-default.patch.bz2 ... [ ok ]
* 02_all_gcc-3.4.3-v8.7.6.7-pie-rs6000-default.patch.bz2 ... [ ok ]
* 02_all_gcc-3.4.3-v8.7.6.7-pie-sparc-default.patch.bz2 ... [ ok ]
* Done with patching
* Cannot find $EPATCH_SOURCE! Value for $EPATCH_SOURCE is:
*
* /var/tmp/portage/gcc-3.4.3-r1/work/bounds-checking-gcc-3.4.2-1.00.patch
* ( bounds-checking-gcc-3.4.2-1.00.patch )
!!! ERROR: sys-devel/gcc-3.4.3-r1 failed.
!!! Function epatch, Line 216, Exitcode 0
!!! Cannot find $EPATCH_SOURCE!
!!! If you need support, post the topmost build error, NOT this status message.
| I'm currently doing a Stage3/1 Install on an old P3 machine I have from Knoppix; it's already become apparent that the install can read my environment variables even after an env-update since it complained about not running on a 2.6 kernel for NPTL. Could that be the source of my error, or is it something else? I run gcc 3.4.3-r1 on my primary machine, so I would assume that the ebuild is fine. _________________ Gentoo: Stage3 w/ NPTL & udev, gcc 3.4.4 full rebuild
Kernel: 2.6.15-gentoo-r1 w/ 1G-Lowmem Patch
System: Athlon XP 2.2Ghz/1GB Corsair Value/160GB, 250GB WD IDE/128MB GeForce 6800/Sony 17" Trinitron G200 @ 1280x1024x75Hz |
|
Back to top |
|
|
Sith_Happens Veteran
Joined: 15 Dec 2004 Posts: 1807 Location: The University of Maryland at College Park
|
Posted: Wed May 25, 2005 4:26 pm Post subject: |
|
|
It looks like an ebuild problem to me, try rsyncing your portage tree and see if that fixes the problem. _________________ "That question was less stupid; though you asked it in a profoundly stupid way."
I'm the brains behind Jackass! | Tutorials: Shorewall |
|
Back to top |
|
|
Bob P Advocate
Joined: 20 Oct 2004 Posts: 3355 Location: Jackass! Development Labs
|
Posted: Wed May 25, 2005 6:12 pm Post subject: |
|
|
Arainach wrote: | I'm currently doing a Stage3/1 Install on an old P3 machine I have from Knoppix; it's already become apparent that the install can read my environment variables even after an env-update since it complained about not running on a 2.6 kernel for NPTL. Could that be the source of my error, or is it something else? I run gcc 3.4.3-r1 on my primary machine, so I would assume that the ebuild is fine. |
This is a job for Jackass! link
oh, how i've been waiting to say that!
seriously, if you're not doing the Stage 1/3 just because you want to perform a Stage 1/3, i would recommend that you use the Jackass .ISO for Pentium 3.
otoh, if you're doing this as a learning exercise, you may want to review the CVS information on the ebuild to determine if any changes have recently been made to the ebuild that may have introduced a problem. when we built Jackass! we extensively tested the portage tree and sync'd on a specific date that we found to be free of errors. believe it or not, that's a big factor in the equation.
on the subject of troubleshooting, you haven't provided enough information. at an absolute minimum, you need to post the name of the tarball that you installed from, post the output of emerge --info, and tell us what step you're on in the Installaton Guide. _________________ .
Stage 1/3 | Jackass! | Rockhopper! | Thanks | Google Sucks |
|
Back to top |
|
|
IT Tux's lil' helper
Joined: 06 Jul 2004 Posts: 140 Location: Terra Firma
|
Posted: Fri May 27, 2005 4:52 pm Post subject: |
|
|
I was having the circular dependancy problem...first time I experienced that...and I have a "few" stage 1 installs under my belt. I found this post on the forum and BAM...I'm rock solid with a NPTL 1/3 stage install. It went flawlessly until I got to the grub config...but that was my mistake. I quickly corrected that and now I'm up and running with fluxbox and a few other apps. I did have one issue with my regular user...I was getting the error with /dev/null...which, after reading other postings, came down to a udev bug...so I unmerged it...emerged it and it just went away. All is good.
One thing I am a little worried about...to the point of not wanting to do any emerge -uDav worlds...I don't want to break this install and I don't usually use non-stable releases. would I just use the normal emerge --sync and emerge -uDav world to keep this puppy humming along? I saw an earlier post about this, in which Bob said the answer was posted in the 2004.3 post...but I couldn't find it. If you could point me to the exact post I'd like to read what was said.
Thanks Bob...for a great HOWTO...I'm sure you've heard that enough |
|
Back to top |
|
|
Bob P Advocate
Joined: 20 Oct 2004 Posts: 3355 Location: Jackass! Development Labs
|
Posted: Fri May 27, 2005 5:40 pm Post subject: |
|
|
IT wrote: | One thing I am a little worried about...to the point of not wanting to do any emerge -uDav worlds...I don't want to break this install and I don't usually use non-stable releases. would I just use the normal emerge --sync and emerge -uDav world to keep this puppy humming along? I saw an earlier post about this, in which Bob said the answer was posted in the 2004.3 post...but I couldn't find it. If you could point me to the exact post I'd like to read what was said.
Thanks Bob...for a great HOWTO...I'm sure you've heard that enough |
thanks for the feedback. in spite of what you might think, i haven't heard enough, so i always enjoy reading more.
HOW to UPDATE your SYSTEM AFTER a STAGE 1/3 INSTALL
as far as updates go, its important to remember that a Stage 1/3 install uses a testing branch toolkit. this means that the user is subject to the slings and arrows of outrageous fortune that are inherent in running a testing branch Gentoo box. in other words, a b0rked toolkit ebuild could pop-up into the testing branch in portage without warning. if you were to emerge a bad ebuild into your toolkit, your system could be annihilated.
dealing with stable branch toolkit updates is tricky business, but dealing with testing branch toolkit updates is even trickier. unlike stable branch updates, which you can rely on as being fairly innocuous, testing branch toolkit updates could be good for your system, or they could be very, very BAD for it. the user needs to adopt an update policy to protect them from the possibility of a testing branch ebuild borking their system. there are a number of ways to do this.
personally, i will not consider blindly upgrading any toolkit package on my system. before i will consider emerging a testing branch toolkit component onto my system, i will ALWAYS create a chrooted testing environment in which to perform the toolkit upgrade. only after thorough testing of the toolkit upgrade in the chrooted environment will i consider emerging the toolkit upgrade to my main system. this is an extremely important approach from a safety standpoint, and its an advanced method that we haven't specifically addressed in these threads. granted, testing a toolkit in a chrooted environment is a little beyond the scope of this thread, so if anyone wants to pursue this topic, i'd recommend starting a thread about it in Portage & Programming.
an easier approach is to just use hielvc's or minderaser's tcupdate.sh scripts to perform non-toolkit / world-only updates. if you complete a Stage 1/3 install, you'll have a testing branch toolkit on a stable branch system. it makes sense that once you find a stable toolkit in the testing branch, you should NEVER update it until you determine that the update that you are going to replace it with will perform properly. OTOH, you can safely update stable branch world packages whenever you'd like. the hard part about doing this is that you want to update the world packages without updating the toolkit packages, and Gentoo's emerge command doesn't offer this option as a command-line parameter.
normally, the process of updating the world packages without updating the toolkit packages requres that the user perform a pretend update of the world files, read the proposed output, and manually emerge the non-toolkit world packages. this is an extremely time consuming job, but its the safest way to update your system. hielvc and minderaser have automated the process so that their scripts perform these updates in an intelligent fasion -- just like a knowledgeable user would if he were performing the updates by hand.
for more information on how to do this, you should follow the links to hielvc's and minderaser's scripts that are provided in the Stage 1/3 Guide. you should download the scripts, and you should use them to perform world updates that do not update the toolkit components. the information on how to do this is discussed in detail in their thread in the Unsupported Software Forum:
https://forums.gentoo.org/viewtopic-t-282474-highlight-emerge+wrapper.html _________________ .
Stage 1/3 | Jackass! | Rockhopper! | Thanks | Google Sucks |
|
Back to top |
|
|
IT Tux's lil' helper
Joined: 06 Jul 2004 Posts: 140 Location: Terra Firma
|
Posted: Fri May 27, 2005 9:58 pm Post subject: |
|
|
Great! that answered pretty much all of my questions! TY and thanks for the quick response. |
|
Back to top |
|
|
ravv n00b
Joined: 30 May 2005 Posts: 3
|
Posted: Mon May 30, 2005 11:09 am Post subject: |
|
|
Maybe this has been discussed but i didn´t find it when i searched.
Changing
CHOST="i586-pc-linux-gnu"
to
CHOST="i686-pc-linux-gnu"
would have saved me alot of time.
According to this thread glibc-2.3.5 failes compiling under i586. I don´t know if it failes for everyone but i did for me.
Yes i know i´m a newbie and shouldn´t be using this guide but i am and you can´t stop me! Feel free to flame me if i´m wrong |
|
Back to top |
|
|
Sith_Happens Veteran
Joined: 15 Dec 2004 Posts: 1807 Location: The University of Maryland at College Park
|
Posted: Mon May 30, 2005 5:30 pm Post subject: |
|
|
ravv wrote: | Maybe this has been discussed but i didn´t find it when i searched.
Changing
CHOST="i586-pc-linux-gnu"
to
CHOST="i686-pc-linux-gnu"
would have saved me alot of time.
According to this thread glibc-2.3.5 failes compiling under i586. I don´t know if it failes for everyone but i did for me.
Yes i know i´m a newbie and shouldn´t be using this guide but i am and you can´t stop me! Feel free to flame me if i´m wrong | No, that has been my experience as well. That is why when we developed the Jacakss! project for Gentoo 2005.0, we used GCC 2.3.4 in the i586 stages. However, if you are going to be compiling with an i686 chost, then using GCC 2.3.5 isn't a problem. _________________ "That question was less stupid; though you asked it in a profoundly stupid way."
I'm the brains behind Jackass! | Tutorials: Shorewall |
|
Back to top |
|
|
slycordinator Advocate
Joined: 31 Jan 2004 Posts: 3065 Location: Korea
|
Posted: Mon May 30, 2005 6:55 pm Post subject: |
|
|
ravv wrote: | Maybe this has been discussed but i didn´t find it when i searched.
Changing
CHOST="i586-pc-linux-gnu"
to
CHOST="i686-pc-linux-gnu"
would have saved me alot of time.
According to this thread glibc-2.3.5 failes compiling under i586. I don´t know if it failes for everyone but i did for me.
Yes i know i´m a newbie and shouldn´t be using this guide but i am and you can´t stop me! Feel free to flame me if i´m wrong |
If you were using something other than i586 pc you shouldn't have:
1) Ever used a stage tarball for an i586
2) Had CHOST="i586-pc-linux-gnu" in your make.conf
The guide clearly says that the only reason it uses an x86 stage tarball and that CHOST value is because Bob was writing it based on his install he did for an old pentium computer. You must tailor it to meet your pc's specification. |
|
Back to top |
|
|
Bob P Advocate
Joined: 20 Oct 2004 Posts: 3355 Location: Jackass! Development Labs
|
Posted: Tue May 31, 2005 5:08 pm Post subject: |
|
|
ravv wrote: | Maybe this has been discussed but i didn´t find it when i searched.
Changing
CHOST="i586-pc-linux-gnu"
to
CHOST="i686-pc-linux-gnu"
would have saved me alot of time.
According to this thread glibc-2.3.5 failes compiling under i586. I don´t know if it failes for everyone but i did for me.
Yes i know i´m a newbie and shouldn´t be using this guide but i am and you can´t stop me! Feel free to flame me if i´m wrong |
as the others have noted, the CHOST specification is something that is based upon your processor type, and it really is not something that you have any freedom about choosing. when you build your system, there is ONE and only ONE CHOST setting that will be the correct choice for your computer. [1] this is really a Gentoo Fundamentals issue that you need to learn early on, so that you don't make repeated mistakes of this type.
[1] ok, i guess you could intentionally use a 586 CHOST on a 686 computer in the case that you're building on one machine to run on another, but strictly speaking, there is only ONE chost setting, tarball, and processor specification that should be used on any given PC. _________________ .
Stage 1/3 | Jackass! | Rockhopper! | Thanks | Google Sucks |
|
Back to top |
|
|
ravv n00b
Joined: 30 May 2005 Posts: 3
|
Posted: Wed Jun 01, 2005 11:24 pm Post subject: |
|
|
Accordning to the thread that version of glibc can only be built with chost 686. It simly won´t build with anything less. I actually have no idea not like i´m going to flush my system to try it Oh well i´m not going to complain more now. great guide loved it |
|
Back to top |
|
|
slycordinator Advocate
Joined: 31 Jan 2004 Posts: 3065 Location: Korea
|
Posted: Thu Jun 02, 2005 12:20 am Post subject: |
|
|
ravv wrote: | Accordning to the thread that version of glibc can only be built with chost 686. It simly won´t build with anything less. I actually have no idea not like i´m going to flush my system to try it Oh well i´m not going to complain more now. great guide loved it |
That's not entirely correct. That version of glibc can't be built with chost=i586 or lower when you use linuxthreads rather than nptl. So if you force it to build glibc to only use nptl then it will work with chost=i586, if you have chost > i586 it should work with both, and if you have a non-x86 processor it should work with both as well. |
|
Back to top |
|
|
kki n00b
Joined: 21 Nov 2003 Posts: 10
|
Posted: Thu Jun 02, 2005 9:23 am Post subject: problem with libstdc++.so.5 |
|
|
Hello
After i have pruned the old gcc and try to emerge again the new gcc 3.4.4, i obtain this error:
Error while loading shared libraries libstdc++.so.5
and emerge doesn't work anymore
Any idea ?
thanks ! |
|
Back to top |
|
|
Bob P Advocate
Joined: 20 Oct 2004 Posts: 3355 Location: Jackass! Development Labs
|
Posted: Thu Jun 02, 2005 4:12 pm Post subject: Re: problem with libstdc++.so.5 |
|
|
How To Ask For Support
When asking for support, please give us all of the information that we need to approach your problem. This would include:
1. the full output of the error message you received
2. the output of "emerge --info"
3. the name of the tarball that you installed from _________________ .
Stage 1/3 | Jackass! | Rockhopper! | Thanks | Google Sucks |
|
Back to top |
|
|
Naveg n00b
Joined: 20 May 2005 Posts: 73
|
Posted: Fri Jun 03, 2005 2:16 am Post subject: |
|
|
more of a question than a support request:
If i'm installing via Knoppix, would the command for mounting the /proc differ from the in the guide? |
|
Back to top |
|
|
quanttrom n00b
Joined: 26 Jan 2004 Posts: 19
|
Posted: Fri Jun 03, 2005 2:25 am Post subject: missing libstdc++.so.5 |
|
|
Hello,
I was following the guide that you provided and ended up with the same error that kki is ending up with
mainly missing libstdc++.so.5
when I try to emerge anything I get the following: Code: |
livecd / # emerge glibc
/usr/bin/python: error while loading shared libraries: libstdc++.so.5: cannot open shared object file: No such file or directory
|
if I try to type in emerge -info .. same result :
Code: | livecd / # emerge -info
/usr/bin/python: error while loading shared libraries: libstdc++.so.5: cannot open shared object file: No such file or directory |
in fact ANYTHING that uses python won't load because it needs the library..
my make.conf is quite long but here it is:
Code: | CHOST="i686-pc-linux-gnu"
CFLAGS="-O3 -march=athlon-xp -fomit-frame-pointer -pipe -fforce-addr -fomit-frame-pointer -mmmx -msse -msse2 -m3dnow \
-mfpmath=sse"
CXXFLAGS=${CFLAGS}
ACCEPT_KEYWORDS="x86"
LDFLAGS="-Wl,-O1 -Wl,--enable-new-dtags -Wl,--sort-common -s"
PORTAGE_TMPDIR=/var/tmp
PORTDIR=/usr/portage
DISTDIR=${PORTDIR}/distfiles
PKGDIR=${PORTDIR}/packages
PORT_LOGDIR=/var/log/portage
PORTDIR_OVERLAY=/usr/local/portage
GENTOO_MIRRORS="http://adelie.polymtl.ca/ ftp://ftp.ussg.iu.edu/pub/linux/gentoo http://gentoo.arcticnetwork.ca/ \
http://gentoo.mirrored.ca/"
SYNC="rsync://rsync.ca.gentoo.org/gentoo-portage"
RSYNC_RETRIES="3"
RSYNC_TIMEOUT=180
MAKEOPTS="-j2"
#PORTAGE_NICENESS=3
AUTOCLEAN="yes"
FEATURES="ccache distlocks sandbox userpriv usersandbox"
CCACHE_SIZE="512M"
RSYNC_EXCLUDEFROM=/etc/portage/rsync_excludes
USE="-3dfx 3dnow X aax -aalib -accessibility -acl acpi -adabas -adns -afs aim alsa -altivec apache2 apm arts audiofile \
avi bash-completion -bcmath berkdb -bidi -birdstep -bluetooth bmp -bonobo bzlib -canna -caps cdb cdparanoia cdr -chasen \
-cjk crypt cups -db2 -dbase dbus dga dio directfb doc dv dvd dvdr -eds emacs emacs-w3 -emboss -empress encode -esd -esoob \
-ethereal evo exif -fam fbcon -filepro flac truetype -freewnn frontbase ftp gd -geoip gif -glut -gnome gphoto2 gpm -gps \
gtk gtk2 icq -ieee1394 imagemagic -imap -interbase -ipv6 -jabber -jack java javascript -joystick jpeg kde kdeenablefinal \
kdexdeltas lirc lm_sensors mad -migemo mime -nmap mmx mozilla mp3 mpeg msn -msql -mssql mysql -nas ncurses -netboot -nls \
nptl -oci8 -odbc ogg oggvorbis openal opengl -oracle oscar -oss -pcmcia pcre -pda pdflib perl -pfpro php png -portaudio \
-postgres -prelude qt quicktime readline samba -sapdb -sasl -scanner -sdl session sharedext sharedmem -shorten -slang \
-smartcard -sndfile -snmp -soap -socks5 -solid -speex spell spl -sqlite sse -ssl -sybase symlink -tcpd -tetex tiff \
tokenizer truetype usb -v4l vcd -vhosts -videos -voodoo3 vorbis -wifi win32codecs -wmf xine -xinerama xml2 xmms xvid \
yahoo -yaz -zeo"
|
and I'm installing from stage3-athlon-xp-2005.0.tar.bz2 ...this is the image that comes on one of the LiveCD's
Thank you in advance,
Any help would be greatly appreciated! |
|
Back to top |
|
|
Naveg n00b
Joined: 20 May 2005 Posts: 73
|
Posted: Fri Jun 03, 2005 5:05 am Post subject: |
|
|
I get an error when i issue
# emerge gcc-config glibc binutils gcc
I am installing through knoppix
Here is the output:
Code: | Knoppix / # emerge gcc-config glibc binutils gcc
Calculating dependencies ...done!
>>> emerge (1 of 5) sys-devel/gcc-config-1.3.10-r2 to /
>>> md5 files ;-) gcc-config-1.3.10-r1.ebuild
>>> md5 files ;-) gcc-config-1.3.8-r4.ebuild
>>> md5 files ;-) gcc-config-1.4.0.ebuild
>>> md5 files ;-) gcc-config-1.3.10-r2.ebuild
>>> md5 files ;-) ChangeLog
>>> md5 files ;-) metadata.xml
>>> md5 files ;-) files/digest-gcc-config-1.4.0
>>> md5 files ;-) files/digest-gcc-config-1.3.10-r1
>>> md5 files ;-) files/digest-gcc-config-1.3.10-r2
>>> md5 files ;-) files/wrapper-1.4.3.c
>>> md5 files ;-) files/wrapper-1.4.5.c
>>> md5 files ;-) files/wrapper-1.4.6.c
>>> md5 files ;-) files/digest-gcc-config-1.3.8-r4
>>> md5 files ;-) files/gcc-config-1.3.8
>>> md5 files ;-) files/gcc-config-1.4.0
>>> md5 files ;-) files/gcc-config-1.3.10
ACCESS DENIED open_wr: /UNIONFS/dev/pts/1
ACCESS DENIED open_wr: /UNIONFS/dev/pts/1
>>> Unpacking source...
>>> Source unpacked.
--------------------------- ACCESS VIOLATION SUMMARY ---------------------------
LOG FILE = "/tmp/sandbox-sys-devel_-_gcc-config-1.3.10-r2-10495.log"
open_wr: /UNIONFS/dev/pts/1
open_wr: /UNIONFS/dev/pts/1
--------------------------------------------------------------------------------
|
|
|
Back to top |
|
|
Naveg n00b
Joined: 20 May 2005 Posts: 73
|
Posted: Fri Jun 03, 2005 7:04 pm Post subject: |
|
|
Ok that problem fixed, but a new one now.
After setting gcc 3.4.4 to be the default compiler using #gcc-config 5 i get this when doing env-update
Code: |
Knoppix / # env-update && source /etc/profile
/usr/bin/python: error while loading shared libraries: libstdc++.so.5: cannot open shared object file: No such file or directory
|
|
|
Back to top |
|
|
moocha Watchman
Joined: 21 Oct 2003 Posts: 5722
|
Posted: Fri Jun 03, 2005 7:16 pm Post subject: |
|
|
Naveg wrote: | Ok that problem fixed, but a new one now.
After setting gcc 3.4.4 to be the default compiler using #gcc-config 5 i get this when doing env-update
Code: |
Knoppix / # env-update && source /etc/profile
/usr/bin/python: error while loading shared libraries: libstdc++.so.5: cannot open shared object file: No such file or directory
|
| That's because gcc-3.4.4 doesn't automatically pull in libstdc++-v3 anymore. Get it back from your backup GCC package or from avenj's rescue packages, then re-emerge it manually. _________________ Military Commissions Act of 2006: http://tinyurl.com/jrcto
"Those who would give up essential liberty to purchase a little temporary safety deserve neither liberty nor safety."
-- attributed to Benjamin Franklin |
|
Back to top |
|
|
Naveg n00b
Joined: 20 May 2005 Posts: 73
|
Posted: Fri Jun 03, 2005 8:25 pm Post subject: |
|
|
do i put the file in the new 3.4.4 directories? or should i just symlink to them in /usr/lib |
|
Back to top |
|
|
Bob P Advocate
Joined: 20 Oct 2004 Posts: 3355 Location: Jackass! Development Labs
|
Posted: Fri Jun 03, 2005 11:35 pm Post subject: |
|
|
Stage 1/3 Installation Support - Gentoo 2005.0 & GCC 3.4.3
there are a number of reasons that the Guide doesn't support the use of GCC 3.4.4 or installation via Knoppix. your problems are among them. _________________ .
Stage 1/3 | Jackass! | Rockhopper! | Thanks | Google Sucks |
|
Back to top |
|
|
Naveg n00b
Joined: 20 May 2005 Posts: 73
|
Posted: Sat Jun 04, 2005 1:53 am Post subject: |
|
|
those reasons arent too strong, as both of my problems had very simple solutions. |
|
Back to top |
|
|
quanttrom n00b
Joined: 26 Jan 2004 Posts: 19
|
Posted: Sat Jun 04, 2005 4:37 am Post subject: |
|
|
I have been changing couple of things as I go along the manual..(since I'm installing GCC 3.4.4)
once I'm done I'll see how things go..
and tell you if it worked..
so far so good...
*EDIT*
stumbled again..with notworking tar...hehe..I have no idea how I got that...
*EDIT*
very very stupid mistake...now it seems to be working fine..recompiling my toolchain.. |
|
Back to top |
|
|
|