Tony Theodore <address@hidden> schrieb: Thanks for your investigation. If it is too much work, let's just drop a note in the docs and wait for Apple to do their homework. In other words, this isn't e
Unfortunately, I think they have; and I think this is part of their control games going too far. The in-place upgrade to 10.6 removes all dev tools from /usr. Fair enough, the os controls /usr, dropp
2009/11/12 Volker Grabsch <address@hidden>: I get the same error here and cant find any clues to get started. You pointed out mingw-64 a few months ago, and I think I'll have a look at that instead.
Tony Theodore <address@hidden> schrieb: Maybe it's a good idea to contact the TDM project. After all, they should have the same problem with their patches. On the other hand, they released it, so may
Tony Theodore <address@hidden> schrieb: While my answer is technically "Yes", there are political and moral issues I'd like to discuss with the whole group of Mingw-cross-env users and developers. To
My primary reason for utilizing mingw-cross-env is to reduce the hassle of compiling a cross platform application on multiple platforms (though I have yet to find as nice a solution for OS X). In thi
2009/11/15 Volker Grabsch <address@hidden>: Fascinating reading, I hadn't thought about such things for a long time. Mostly these days I think about windows with a mix of ambivalence and pity. I see
2009/11/15 Tony Theodore <address@hidden>: <snip my long-winded nonsense> and I should have thought about it for a longer time before jumping in and killing the conversation. My apologies. It's a lar
Ben Lau <address@hidden> schrieb: Maybe the IMCROSS project could help here. It is a bit younger than mingw-cross-env. It doesn't provide as many packages, but it provides support for Win32 as well a
Volker Grabsch <address@hidden> schrieb: Thanks to Ben and Tony for sharing your thoughts. I didn't get any negative comments about Win64 support, neither in private nor via the list. The next releas
Tony Theodore <address@hidden> schrieb: Thanks for your investigation! Maybe this is yet another reason to either switch back to MinGW-GCC or to go the MinGW-w64 route. It would of course be great if
I've been using IMCROSS... that's how I ran across mingw-cross-env actually. The major problem with it is getting all of the Apple proprietary libraries to link sanely. The way they manage their head
Tony Theodore <address@hidden> schrieb: Have you tried to build 32-bit binaries with mingw-w64? I.e., is there any "-m32" switch or similar? Is there a possibility to build a "32-bit-only" or "32-bit
Yes, there's two targets - x86_64-w64-mingw32 (can be multilib) and i686-w64-mingw32. With the multilib, you have to do a lot of double builds with "-m32" and it's not always obvious where to install
The attached diff is still a bit messy, I've started changing it over to 32-bit only to see what happens. Pthreads isn't being built yet, but boost is now only failing on 2 targets, which seems more
Tony Theodore <address@hidden> schrieb: Maybe we should solve the Pthreads issue first. That would make the switch to mingw-w64 much easier. I'll try to get that sorted out as soon as possible, hopef
Tony Theodore <address@hidden> schrieb: Maybe the cleanest way is to build 32-bit stuff using the 'i686-w64-mingw32' prefix and 64-bit stuff using the 'x86_64-w64-mingw32' prefix. That way, both coul
It does seem to be the lesser evil, though another problem I find is that there's no standard location for libraries. There's lib, lib32, lib64, and an underscore prefix. This thread made me give up
Tony Theodore <address@hidden> schrieb: Why do we need different library directories at all? Since we have different target prefixes, everything should go into "lib". That's it. So we'd have: usr/i68