Hi Bill, On Mon, 12 Sep 2011 21:54:44 +0200, Bill Allombert <bill.allomb...@math.u-bordeaux1.fr> wrote: > On Thu, Aug 04, 2011 at 08:36:52AM +0200, Stephen Kitt wrote: > > 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
That works because mingw32-binutils installs binaries in /usr/i586-mingw32msvc/bin, which is part of i586-mingw32msvc-gcc's search path for programs (as shown by the -print-search-dirs option). I chose not to install binaries in /usr/$target/bin since it goes against Debian policy. Eventually I hope to drop /usr/$target entirely, once the multiarch policy is extended to cross-compiling packages... > > 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. I'd suggest a two-pronged approach: first check to see whether a target-triplet-prefixed tool exists, and only if that fails ask gcc. In addition, if gcc's answer doesn't include the binary's path, it has to be ignored - if gcc doesn't find a given program in its search path it just outputs the program name as given on the command line! > 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. You're welcome! > Now, if only I could get readline to build... Good luck... Regards, Stephen
signature.asc
Description: PGP signature
