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 Thursday 17 April 2008 05:26, Brian Dessent wrote:
> Denys Vlasenko wrote:
>
> > Only in my case, $prefix contain neither as nor ld. gcc lives in
>
> Okay, so prepend /usr/app/binutils-2.18-x86_64-linux-uclibc/bin to PATH
> and gcc will find and use x86_64-linux-uclibc-{as,ld} without any of
> --with-{as,ld}.
It will remember the path?
What will happen when I install binutils-2.19
into /usr/app/binutils-2.19-x86_64-linux-uclibc sometime later?
I strongly prefer gcc to use my "public" x86_64-linux-uclibc-ld,
which is accessible by just searching PATH.
By searching PATH gcc doesn't even need to know how exactly it is done -
by adding /usr/app/binutils-2.19-x86_64-linux-uclibc/bin
to PATH or by creating /usr/bin/x86_64-linux-uclibc-ld symlink.
No ad-hoc, gcc-specific searching is needed, execvp already does
that searching in a "standard", well-known way.
This wheel is already invented.
Currently, gcc insists on knowing full path to executable.
It's a policy decision. It narrows down the options.
Policy decisions are best left to humans,
while programs should just provide capabilities.
> > it's much better for sanity that way.
>
> I would argue that it's not, since simply using the same $prefix
> JustWorks(tm) without worrying about modifying PATH or any --with-foo.
Using the same $prefix requires one to remeber which versions
of binutils+gcc+whatever are installed into same $prefix,
and God knows how exactly they will stomp on each other's
toes (files) there.
IMO, of course.
--
vda