Summary: | python-2.6.2 fails to build due to problematic linking | ||
---|---|---|---|
Product: | Gentoo/Alt | Reporter: | Raphaël Barrois <gentoo> |
Component: | Prefix Support | Assignee: | Gentoo Prefix <prefix> |
Status: | RESOLVED CANTFIX | ||
Severity: | major | CC: | axiator |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | AMD64 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Raphaël Barrois
2009-05-26 09:30:48 UTC
can you check the following: % gcc-config -l % binutils-config -l % $EPREFIX/usr/bin/gcc --version % $EPREFIX/usr/bin/ld --version % ldd %EPREFIX/usr/bin/python (In reply to comment #1) > can you check the following: I cehcked them (in the $EPREFIX environment) : > % gcc-config -l * Python seems to be broken, attempting to locate CHOST ourselves ... sed: can't read /data/prefix//etc/make.conf: No such file or directory * gcc-config: Could not get portage CHOST! * gcc-config: You should verify that CHOST is set in one of these places: * gcc-config: - /data/prefix//etc/make.conf * gcc-config: - active environment > % binutils-config -l [1] x86_64-pc-linux-gnu-2.19.51.0.4 * > % $EPREFIX/usr/bin/gcc --version gcc (GCC) 4.1.2 (Gentoo 4.1.2 p1.1) Copyright (C) 2006 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. > % $EPREFIX/usr/bin/ld --version GNU ld (Linux/GNU Binutils) 2.19.51.0.4.20090418 Copyright 2008 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License version 3 or (at your option) a later version. This program has absolutely no warranty. > % ldd $EPREFIX/usr/bin/python linux-vdso.so.1 => (0x00007fff1c5fd000) libpython2.6.so.1.0 => not found libpthread.so.0 => /lib/libpthread.so.0 (0x00007f4f14176000) libdl.so.2 => /lib/libdl.so.2 (0x00007f4f13f72000) libutil.so.1 => /lib/libutil.so.1 (0x00007f4f13d6f000) libm.so.6 => /lib/libm.so.6 (0x00007f4f13aee000) libc.so.6 => /lib/libc.so.6 (0x00007f4f137a6000) /lib64/ld-linux-x86-64.so.2 (0x00007f4f14391000) You are bootstrapping on a Gentoo Linux host? (In reply to comment #3) > You are bootstrapping on a Gentoo Linux host? > Yes. I have python 2.5.4 on it ; $ gcc --version gcc (GCC) 4.1.2 (Gentoo 4.1.2 p1.1) Right. I already suspected that. It seems your environment isn't really sane. Your python is built without --rpath to your prefix libs. Did you perhaps skip binutils, gcc, and their -config wrappers? (In reply to comment #5) > Right. I already suspected that. It seems your environment isn't really sane. > Your python is built without --rpath to your prefix libs. Did you perhaps > skip binutils, gcc, and their -config wrappers? > Well, python seems to be compiled from portage ; I don't understand what you mean by "skip" ? I did follow the whole http://www.gentoo.org/proj/en/gentoo-alt/prefix/bootstrap-solaris.xml instructions. Do you need any other info ? hmmm. % $EPREFIX/bin/bash -c 'gcc --version' also returns 4.1.2? (In reply to comment #7) > hmmm. > > % $EPREFIX/bin/bash -c 'gcc --version' > > also returns 4.1.2? > Yes : % $EPREFIX/bin/bash -c 'gcc --version' gcc (GCC) 4.1.2 (Gentoo 4.1.2 p1.1) Try this instead: % $EPREFIX/bin/bash -l eprefix% gcc --version Regarding python-2.6: Once I had troubles using python-2.6 as the first python installed - I was left without the usr/bin/python symlink, just usr/bin/python2.6 was there. So I do bootstrap with '<python-2.6' - when there is python-2.5 installed, upgrading to 2.6 works then. Didn't dig deeper into that (yet). (In reply to comment #9) > Try this instead: > > % $EPREFIX/bin/bash -l > eprefix% gcc --version > Here, I get : gcc (GCC) 4.2.4 (Gentoo 4.2.4-r1 p1.1) that's probably eselect python not being called (or installed) (In reply to comment #11) > (In reply to comment #9) > > Try this instead: > > > > % $EPREFIX/bin/bash -l > > eprefix% gcc --version > > > Here, I get : > gcc (GCC) 4.2.4 (Gentoo 4.2.4-r1 p1.1) Hmmm, ok. what does the following return? % head -n1 $EPREFIX/usr/lib/portage/bin/ebuild.sh (In reply to comment #12) > that's probably eselect python not being called (or installed) > ./prefix/usr/bin/eselect python list Available python interpreters: [1] python2.6 * In the end of the python building, I had those lines too : >>> Installing (25 of 27) dev-lang/python-2.6.2 Switching to python2.6 * Byte compiling python modules for python-2.6 .. ... python2.6: error while loading shared libraries: libpython2.6.so.1.0: cannot open shared object file: No such file or directory python2.6: error while loading shared libraries: libpython2.6.so.1.0: cannot open shared object file: No such file or directory (In reply to comment #13) > (In reply to comment #11) > > (In reply to comment #9) > > > Try this instead: > > > > > > % $EPREFIX/bin/bash -l > > > eprefix% gcc --version > > > > > Here, I get : > > gcc (GCC) 4.2.4 (Gentoo 4.2.4-r1 p1.1) > > Hmmm, ok. what does the following return? > % head -n1 $EPREFIX/usr/lib/portage/bin/ebuild.sh > % head -n1 $EPREFIX/usr/lib/portage/bin/ebuild.sh #!/data/prefix/tmp/usr/bin/bash well, the proof of the pudding is in the eating: % $EPREFIX/bin/bash -l $ echo "int main() {}" | gcc -x c -o x -Wl,--verbose - | grep SEARCH_DIR $ scanelf --rpath x (In reply to comment #16) > well, the proof of the pudding is in the eating: > > % $EPREFIX/bin/bash -l > $ echo "int main() {}" | gcc -x c -o x -Wl,--verbose - | grep SEARCH_DIR > $ scanelf --rpath x > % $EPREFIX/bin/bash -l $ echo "int main() {}" | gcc -x c -o x -Wl,--verbose - | grep SEARCH_DIR SEARCH_DIR("/data/prefix/usr/x86_64-pc-linux-gnu/lib64"); SEARCH_DIR("/data/prefix/usr/lib/binutils/x86_64-pc-linux-gnu/2.19.51.0.464"); SEARCH_DIR("/usr/local/lib64"); SEARCH_DIR("/lib64"); SEARCH_DIR("/usr/lib64"); SEARCH_DIR("/data/prefix/usr/x86_64-pc-linux-gnu/lib"); SEARCH_DIR("/data/prefix/usr/lib/binutils/x86_64-pc-linux-gnu/2.19.51.0.4"); SEARCH_DIR("/usr/local/lib"); SEARCH_DIR("/lib"); SEARCH_DIR("/usr/lib"); $ scanelf --rpath x TYPE RPATH FILE ET_EXEC /data/prefix/usr/x86_64-pc-linux-gnu/lib/gcc:/data/rbarrois/prefix/usr/x86_64-pc-linux-gnu/lib:/data/rbarrois/prefix/usr/lib:/data/rbarrois/prefix/lib x (In reply to comment #17) Well, I was able to have it compiling correctly with : % export LD_RUN_PATH="$EPREFIX/usr/lib:$EPREFIX/lib:$LD_RUN_PATH". I think this is just a workaround - if you need, I still have a copy where the problem hasn't been solved in order to make more tests. Is LD_RUN_PATH set? Then that's the culprit. For Prefix you need variables like that to be unset. (In reply to comment #19) > Is LD_RUN_PATH set? Then that's the culprit. For Prefix you need variables > like that to be unset. > It wasn't set, but setting it to include $EPREFIX/usr/lib and $EPREFIX/lib allowed me to build python without linking problems. voodoo stuff, sorry no clues here |