Bug#632003: i686-w64-mingw32-gcc --print-prog-name gives wrong result for some tools
On Sun, Sep 18, 2011 at 11:59:24PM +0200, Stephen Kitt wrote: 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.allomb...@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. The software in point is not using autoconf and is not using target-triplet either. All it knows about is the compiler. On Sun, 18 Sep 2011 09:29:45 +0800, Bin Tian tian...@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. Alternatively, you can patch gcc so that it returns 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... I do not see which policy would be violated, not even the no-broken-link rule 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! Not everybody is using autoconf/libtool. Cheers, PS: I managed to build readline with termcap. -- 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
Bug#632003: i686-w64-mingw32-gcc --print-prog-name gives wrong result for some tools
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.allomb...@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. On Sun, 18 Sep 2011 09:29:45 +0800, Bin Tian tian...@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 signature.asc Description: PGP signature
Bug#632003: i686-w64-mingw32-gcc --print-prog-name gives wrong result for some tools
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
Bug#632003: i686-w64-mingw32-gcc --print-prog-name gives wrong result for some tools
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 Tiantian...@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
Bug#632003: i686-w64-mingw32-gcc --print-prog-name gives wrong result for some tools
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
Bug#632003: i686-w64-mingw32-gcc --print-prog-name gives wrong result for some tools
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
Bug#632003: i686-w64-mingw32-gcc --print-prog-name gives wrong result for some tools
Package: gcc-mingw-w64 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-w642.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-2multiple 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 zlib1g1:1.2.3.4.dfsg-3 compression library - runtime Versions of packages gcc-mingw-w64 recommends: ii libstdc++6-4.6-dev4.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-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#632003: i686-w64-mingw32-gcc --print-prog-name gives wrong result for some tools
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. Regards, Bin Tian On 2011年06月29日 11:55, Bin Tian wrote: Package: gcc-mingw-w64 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-w642.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-2multiple 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 zlib1g1:1.2.3.4.dfsg-3 compression library - runtime Versions of packages gcc-mingw-w64 recommends: ii libstdc++6-4.6-dev4.6.0-14 GNU Standard C++ Library v3 (devel Versions of packages gcc-mingw-w64 suggests: pn gcc-4.6-localesnone (no description available) -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
