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