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 <[email protected]> wrote: > > On Mon, 12 Sep 2011 21:54:44 +0200, Bill Allombert > > <[email protected]> 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 <[email protected]> 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. <[email protected]> Imagine a large red swirl here. -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
