This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Can't build correctly working crosscompiler with 4.3.0. 4.2.1 worked like charm
On Wednesday 16 April 2008 16:23, Daniel Jacobowitz wrote:
> On Tue, Apr 15, 2008 at 05:34:17AM +0200, Denys Vlasenko wrote:
> > --bindir=/usr/bin \
>
> > bindir=$STATIC/bin \
>
> Why are you configuring for one set of paths which are half in $STATIC
> and half in /usr, and installing in paths which are all in $STATIC?
Because I install gcc into /usr/app/gcc-N.N.N-target/{bin,lib,whatever}
and then I create links for every binary in bin/*
/usr/bin/foo -> /usr/app/gcc-N.N.N-target/foo
Same for lib/* etc.
I do it not not only for gcc but for almost everything.
I discovered that a lot of packages will "remember" patchs given
to configure and use those at runtime. I want them to use
/ust/bin/something rather than /usr/app/bar/bin/something.
I found that usually giving bindir=/usr/bin to configure
but giving bindir=/usr/app/bar/bin to "make install" will do the trick.
> That's causing this:
>
> > 30816 stat64("/.share/usr/app/gcc-4.3.0-i486-linux-uclibc/bin/../app/gcc-4.3.0-i486-linux-uclibc/libexec/gcc/i486-linux-uclibc/4.3.0/cc1", 0xffde613c) = -1 ENOENT (No such file or directory)
>
> At this point it's clear something is wrong. The libexec directory is
> not in the same relation to bindir that it was at configure time.
Yes, I see... I will try giving bindir=/usr/app/gcc-N.N.N-target/bin
to configure. Will let you know if it still doesn't work.
> You've moved parts of the toolchain pretty much arbitrarily, so it's
> not surprising at all to me that it can't find itself...
Maybe gcc can use paths relative to executable's location?
readlink("/proc/self/exe") and all that.
It will make gcc installation movable without rebuilding.
(Actually it's my biggest gripe about the way Linux packages
are built: generally you can't move them
and expect them to work).
--
vda