Hi, On Wed, 29 Jun 2011 12:14:14 +0800, Bin Tian <tian...@cernet.edu.cn> wrote: > A possible resolution is to create symbol links for these tools in > /usr/lib/gcc/$target/$version or /usr/$target/bin > > Or just specify the absolute path of these tools when configuring the > package.
Do you have a particular use-case which requires using -print-prog-name to find these tools? From what I've been able to determine, -print-prog-name is only supposed to help users determine which tools gcc is using, and concerns itself only with tools which gcc uses directly: as and ld from binutils, and the various language processors (cc1, cc1plus, f951, gnat1, lto1 etc.) along with collect2. For all these programs -print-prog-name gives the correct result. i686-w64-mingw32-ar which you mention isn't used by gcc. I tried the second solution you suggest, but I couldn't get it to work. As far as I can see only as and ld are handled explicitly, anything else is derived from gcc's search paths (look for "programs" in the output of "i686-w64-mingw32-gcc -print-search-dirs"); see find_a_file() in gcc/gcc.c. I don't think the first solution is appropriate, since it would involve adding links from a gcc-specific directory to binutils-provided binaries; but it wouldn't violate policy (since gcc-mingw-w64 depends on binutils-mingw-w64 anyway) so it would be possible if necessary. Regards, Stephen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
