On 15 September 2014 13:39, Tony Kelman <t...@kelman.net> wrote: > > I will have to look into that. It doesn't sound like something we want. > Though I don't really understand why changing the host should change the > way gcc compiles code, unless it does so for cygwin itself. > > Changing the host changes which compiler gets used to create the binaries. > In Cygwin or Linux, you can call the MinGW compilers by providing > --host=x86_64-w64-mingw32 or similar, if you're using conventional > autotools. It's also possible in Cmake but it's about 5 lines worth of > flags (or a toolchain file with the same content) - it works, eventually, > but it's really picky. >
Sorry, I think I misunderstood what you were referring to when you said "host". So my response doesn't make any sense in the way that you meant it. I understand what you are getting at now. > > > It was my understanding that the Mingw compiler could be used from > Cygwin. Perhaps I am confused about it, but it seems like interrogating the > compiler may not give the information we need. > > Right, but when you configure with --host=x86_64-w64-mingw32 in Cygwin or > Linux, you're using a cross-compiler that is prefixed by the host triple: > x86_64-w64-mingw32-gcc and similar for binutils. So you can't just ask > "gcc" for information - in a lot of ways MSYS(2) is a hack to avoid > worrying about MinGW cross-compilation, and it leads to some bad ways of > doing things. I think it's better to do the work to make a library possible > to cross-compile, than to give up and say MSYS(2) is the only method of > compiling it for Windows. I've been cross-compiling Julia itself and all of > its dependencies from both Linux and Cygwin for months, I very rarely touch > MSYS(2) any more. > I think this is very common. But it means that people who really want their code to actually compile on Windows frequently have an inferior system with which to do it, because all the real hackers are cross compiling from Linux. There's nothing wrong in that, it just leads to additional frustration for some people. > > We can't use the accepted gnu triples in MPIR and that has always been > the case for GMP too. They don't give nearly enough information for our > needs. > > Of course they don't provide a complete story when you're worrying about > assembly and various SIMD instruction sets. But that's not the GNU triple's > job. That information should be determined and represented separately, > you're not going to include this kind of information in the host prefix of > the name of a cross-compiler executable for example. > Sure, but just to emphasise, we use the standard gnu triples in the first level of config.guess (except when it's broken). The hack I applied was to the second level, which uses the MPIR triples convention. > GMP is also a pretty bad actor in terms of its autotools usage - making a > symlink to libgmp.dll called libgmp.lib in lib/ is completely the wrong > thing to do for MinGW. > As I understand it, few of their core developers even have access to Windows boxes. They also reportedly don't support stack unwinding on Windows (I've never actually checked this) or provide Visual Studio project files. Their assembly code is just modified with lead-in and lead-out code so they can use the same assembly code for Windows and Linux, despite the differences in ABI. (It works relatively well, but it's a hack -- one that we use quite a bit too, I confess). One enormous frustration for us is that MSVC has no inline assembler on Windows 64, and gas format assembly has not traditionally been available in the assemblers available for Windows. There are many, many problems that we work around that require many hacks, even on the linux side. We could fix them all and make it less hackish, but you are talking about something like a year or two of full time work, just to fix all the build system issues alone! Not your fault I know, but sounds like you may have inherited some > autotools abuses from GMP. > > > Many of them are inherited from there. But remember that GMP has been in development since at least 1994! They did things back then that many other projects have not even thought about doing, to this day. MPIR and GMP are *incredibly* complex projects and few people recognise the subtleties which simply don't arise for other types of software. Bill.
