On 2011年09月17日 20:58, Stephen Kitt wrote:
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...
Does creating symbol links in /usr/lib/gcc/$target/$version/ violates
Debian policy? cc1 is in that folder. Please consider it.
Best Regards
Bin Tian
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
