------- Comment #5 from kkylheku at gmail dot com 2008-02-23 04:58 -------
(In reply to comment #4)
> [crti.o is] found through multilib os-directory suffixes.
Actually, I'm even more confused, because the breakage I'm seeing is simply
arising from mips64-linux-ld being called on a bunch of object files, one of
which is crti.o. It's specified just like that. The linker won't search for it;
it's expected to just be there. I will pop off these patches and see how the
link job was being done before.
> How did you configure GCC?
Binutils:
$SRC_ROOT/packages/unpacked/binutils-2.17/configure \
--target=$TARGET_ARCH \
--prefix=$CROSS_ROOT \
--disable-nls \
${TARGET_ABI:+--with-abi=$TARGET_ABI} \
${BUILD64+--enable-64-bit-bfd} \
--with-sysroot=$TARGET_ROOT
TARGET_ARCH is, e.g. mips64-linux. CROSS_ROOT is the root of a cross toolchain
and TARGET_ROOT is derived from that elsewhere (a subdirectory thereof).
TARGET_ABI is like "n32" for MIPS, for instance. Or unset for i686, in which
case the option isn't passed.
Final shared library GCC:
$SRC_ROOT/packages/unpacked/gcc-$VERSION/configure \
--host=$BUILD_ARCH-none-linux \
--build=$BUILD_ARCH-none-linux \
--target=$TARGET_ARCH \
--prefix=$CROSS_ROOT \
--with-sysroot=$TARGET_ROOT \
--with-gnu-ld \
--with-gnu-as \
--disable-libmudflap \
--disable-libada \
--disable-libssp \
--disable-multilib \
--enable-__cxa_atexit \
--enable-c99 \
--enable-long-long \
${TARGET_ABI:+--with-abi=$TARGET_ABI} \
--enable-languages=c,c++ \
--enable-threads=posix
> The standard_exec_prefix_1, et cetera patch is not necessary on HEAD and will
> conflict. In fact that's another of Carlos's patches.
I should pop those patches off and rework my stuff.
> I don't know about the
> update_path patch, but CodeSourcery's been building relocatable sysrooted
> compilers since before 4.1.1 and never encountered this problem. I think we
> avoid the code in prefix.c entirely.
In 4.1.1, update_path is called many tiems, since it's used by add_prefix. If
you load gcc under gdb and put a breakpoint on update_path, and then just run
even with no arguments you can see.
I've been building and relocating this toolchain also, apparently successfully.
It was the users who discovered these bad paths. They were looking at running
compiles with "ps" and noticed that collect2 was being called with -L options
specifying paths on the machine where the toolchain (and Linux distro) is
built. Our configuration manager is concerned that this may create problems. We
produce versioned, binary builds of the toolchain, and have Makefiles
referencing specific versions of a toolchain by pathname. If you check out last
week's build of some software, you get last week's Makefile which points to the
toolchain which was current then. If that toolchain uses some bad paths to pick
up executables or libraries outside of itself, this nice little scheme might in
fact not be so bullet-proof.
Thanks for any discussion. I will continue with this until it's solved. Sorry
about opening a bug, I just thought I had something, but it's a little bit more
elusive than I thought.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35300
