On Thu, Aug 04, 2011 at 08:36:52AM +0200, Stephen Kitt wrote: > 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?
Sorry to interfer, but I have. Some programs do DLLTOOL = `$CC -print-prog-name=dlltool 2>/dev/null` to derive DLLTOOL from CC. This saves the trouble of setting DLLTOOL separately. This is useful when cross-compiling and it worked with the old mingw32: i586-mingw32msvc-gcc -print-prog-name=dlltool /usr/lib/gcc/i586-mingw32msvc/4.4.4/../../../../i586-mingw32msvc/bin/dlltool > 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. But that raises the question of the proper way to find ar/dlltool for the compiler target platform. In any case, I like to thank you one thousand time for packaging mingw-w64 so I can finally ignore mingw32 and its non-maintainer. Now, if only I could get readline to build... Cheers, -- Bill. <ballo...@debian.org> Imagine a large red swirl here. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
