On Fri, Nov 9, 2012 at 9:01 AM, Ruben Van Boxem <[email protected]> wrote: > 2012/11/9 Earnie Boyd <[email protected]> >> >> On Thu, Nov 8, 2012 at 5:05 PM, JonY wrote: >> > >> > There isn't an include directory specifically for win32 and another for >> > win64. Installing to the same area will clash as OP predicted. >> > >> >> There is only one set of mingw-w64 distributed headers and those >> headers contain both Win32 and Win64 filtered by _WIN64 if the 64bit >> compiler is being used. I filtered my statements with "mingw-w64 >> distributed", therefore there is no clash. >> >> If the OP intends to use various compiler distributions then yes, >> segregation is needed; but I didn't get that from the original post. > > > Let's reiterate: the OP wanted to install his 3rd party headers and libs to > a standard search location. You suggested the toolchain's sysroot, which is > fine, as long as you only have one architecture to worry about. For both x86 > and x64 in the same (multilib) toolchain's sysroot, headers and, if not > carefully handled, libraries will clash. For an example where headers always > clash in this setup, see GMP, for which the generated header gmp.h is > different for x86 vs x64, heck even shared vs static. >
Acknowledged. > Your suggestion quite frankly sucks. JonY is correct in saying that the only > semi-decent way of dealing with this is passing the library locations to a > build system. > What sucks is the generated header. Quite frankly the architecture differences should be handled via the #if filters. Generating a header for a single platform this is meant to be distributed is bonkers. But a generated header should be placed in /PREFIX/lib/PACKAGE/VERSION/ARCH/include similar to the way GCC does. The 32bit versions would go to /PREFIX/lib32/PACKAGE/VERSION/ARCH/include. And using them would require letting the build system know where they are; libtool would help with that. > That, or use two toolchains (one per architecture), and install every > header/lib into <prefix>\<target>, which is the fail-safe way to go. This is > what is done for all Arch AUR MinGW-w64 packages (I'm surprised about the > sheer amount of libraries present in the AUR for mingw-w64 btw since I put a > cross-compiler in there). That is one way to handle it. You could use a VM for each but that could be cumbersome. I've created a batch file to install a set of required packages that I named ProjectEarnie that installs an independent set of MinGW.org tools to create independent environments (projects) that could be adapted for mingw-w64. You can find it on my SF project page if you want to look. The independent environments can help with the development of differing Windows architectures. -- Earnie -- https://sites.google.com/site/earnieboyd ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_nov _______________________________________________ Mingw-w64-public mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
