Ken Moffat wrote: > On Mon, Aug 06, 2007 at 04:37:54PM +0200, Tobias Vogel wrote: > >>> I think that is the wrong config.log! Binutils creates these in >>> some, or all, of the subdirectories - I imagine you have one in the >>> libiberty directory. >>> >>> ĸen >>> >>> >> Whoops! >> Thanks, you're right, here comes the right config.log. >> Thanks again! >> >> ---- >> > [...] > >> configure:2060: gcc -V </dev/null >&5 >> gcc: '-V' option must have argument >> configure:2063: $? = 1 >> configure:2082: gcc -o conftest -g -O2 conftest.c >&5 >> configure:2085: $? = 0 >> configure:2119: checking for C compiler default output file name >> configure:2122: gcc -g -O2 conftest.c >&5 >> configure:2125: $? = 0 >> configure:2171: result: a.out >> configure:2176: checking whether the C compiler works >> configure:2182: ./a.out >> /binutils-2.17/libiberty/configure: line 2183: ./a.out: No such file >> or directory >> configure:2185: _? = 127 >> configure:2194: error: cannot run C compiled programs. >> > That probably means that a.out is linked against a non-existent > library. Run 'readelf -l' or 'ldd' on it to see what it is trying > to use. > > I have to assume that something wrong happened in 'adjusting the > toolchain' (section 10.7). > > ĸen > Ok, i think i found the problem. While it is linking to /lib/ld-linux-x86_64.so.2 the directory /lib is empty, but the file is located in the /lib64 Is this correct, that /lib is empty? Or is it supposed to contain data? Is it supposed to be a symbolic link to lib64?
Thanks Toby _______________________________________________ Clfs-support mailing list [email protected] http://lists.cross-lfs.org/cgi-bin/mailman/listinfo/clfs-support
