Bug#632003: i686-w64-mingw32-gcc --print-prog-name gives wrong result for some tools
Bin Tian
Version: 4.6.0-11
Severity: normal
The output of `i686-w64-mingw32-gcc --print-prog-name=ar` is ar, it is
obviously incorrect.
In fact, it gives wrong result for all tools except as and ld.
x86_64-w64-mingw32-gcc have the same problem.
Regards,
Bin Tian
-- System Information:
Debian Release: 6.0.2
APT prefers stable
APT policy: (990, 'stable'), (500, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.39-2-amd64 (SMP w/8 CPU cores)
Locale: LANG=zh_CN.UTF-8, LC_CTYPE=zh_CN.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages gcc-mingw-w64 depends on:
ii binutils-mingw-w64 2.21.51.20110523-1 Cross-binutils for Win32 and Win64
ii libc6 2.13-7 Embedded GNU C Library: Shared lib
ii libcloog-ppl0 0.15.9-3 the Chunky Loop Generator (runtime
ii libgmp10 2:5.0.1+dfsg-7 Multiprecision arithmetic library
ii libmpc2 0.8.2-1+b1 multiple precision complex floatin
ii libmpfr4 3.0.0-2 multiple precision floating-point
ii libppl-c4 0.11.2-3 Parma Polyhedra Library (C interfa
ii mingw-w64-dev 1.0+20110523-1 Development files for MinGW-w64
ii zlib1g 1:1.2.3.4.dfsg-3 compression library - runtime
Versions of packages gcc-mingw-w64 recommends:
ii libstdc++6-4.6-dev 4.6.0-14 GNU Standard C++ Library v3 (devel
Versions of packages gcc-mingw-w64 suggests:
pn gcc-4.6-locales <none> (no description available)
-- no debconf information
--
To UNSUBSCRIBE, email to debian-bugs-...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Bin Tian
/usr/lib/gcc/$target/$version or /usr/$target/bin
Or just specify the absolute path of these tools when configuring the
package.
Regards,
Bin Tian
Stephen Kitt
On Wed, 29 Jun 2011 12:14:14 +0800, Bin Tian <tia...@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
Bill Allombert
> Hi,
>
> On Wed, 29 Jun 2011 12:14:14 +0800, Bin Tian <tia...@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. <ball...@debian.org>
Imagine a large red swirl here.
Stephen Kitt
On Mon, 12 Sep 2011 21:54:44 +0200, Bill Allombert
<Bill.Al...@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 <tia...@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
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.
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.
> Now, if only I could get readline to build...
Regards,
Stephen
Bin Tian
Debian policy? cc1 is in that folder. Please consider it.
Best Regards
Bin Tian
Stephen Kitt
Scratch that, it turns out autoconf already knows how to do this when given
an appropriate --host directive: AC_CHECK_TOOL([DLLTOOL], [dlltool], [:])
does the trick. This is used for example by gnupg to find ar, and LibreOffice
to find ar, dlltool, windres and others.
On Sun, 18 Sep 2011 09:29:45 +0800, Bin Tian <tia...@cernet.edu.cn> wrote:
> Does creating symbol links in /usr/lib/gcc/$target/$version/ violates
> Debian policy? cc1 is in that folder. Please consider it.
Strictly speaking I believe it wouldn't violate policy, but I'd rather not
add links from a gcc-internal directory to binaries provided by binutils...
Could either one (or both) of you give the AC_CHECK_TOOL approach a shot? And
send patches upstream of course if it works!
Regards,
Stephen
Bill Allombert
> Hi again,
>
> On Sat, 17 Sep 2011 14:58:09 +0200, Stephen Kitt <st...@sk2.org> wrote:
> > On Mon, 12 Sep 2011 21:54:44 +0200, Bill Allombert
> > <Bill.Al...@math.u-bordeaux1.fr> wrote:
> > > 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!
>
> Scratch that, it turns out autoconf already knows how to do this when given
> an appropriate --host directive: AC_CHECK_TOOL([DLLTOOL], [dlltool], [:])
> does the trick. This is used for example by gnupg to find ar, and LibreOffice
> to find ar, dlltool, windres and others.
All it knows about is the compiler.
> On Sun, 18 Sep 2011 09:29:45 +0800, Bin Tian <tia...@cernet.edu.cn> wrote:
> > Does creating symbol links in /usr/lib/gcc/$target/$version/ violates
> > Debian policy? cc1 is in that folder. Please consider it.
i686-w64-mingw32-foo for all unknown foo.
> Strictly speaking I believe it wouldn't violate policy, but I'd rather not
> add links from a gcc-internal directory to binaries provided by binutils...
since gcc-mingw-w64 depends on binutils-mingw-w64.
The binaries are provided by binutils-mingw-w64, but not under their plain name.
There should be a way to retrieve the correct prefix (which is no canonical,
old mingw32 used a different one). There might be one, but I fail to see it.
Ideally the compiler alone should be sufficient to build a shared library.
This work on linux. Unfortunately this is not the case on mingw: you need to
run ranlib on .a files and you need dlltool to build correct DLL.
> Could either one (or both) of you give the AC_CHECK_TOOL approach a shot? And
> send patches upstream of course if it works!
Cheers,
PS: I managed to build readline with termcap.