On Sun, 21 Mar 2010 13:21:12 NightStrike wrote: > Well, this is a problem, yes. It only affects the multilib builds, > though, which don't really work anyway without a lot of effort. And > this will all be fixed for 4.6, o we won't need to worry about it. > > If users really want it, though, I can rework things to exclude 32-bit > entirely. It's just a little messy in Makefile.am. >
Yeah, I kinda decided to give up on multilib with gcc 4.5 right now. The target DLLs for things like libstdc++, etc are installed into the completely wrong spot due to a -bindir parameter in the libtool portion of the DLL makefiles. They are installed into the host's binary directory (which makes no sense to me at all - by the way I use a different -prefix and -exec-prefix), they cannot be overridden by the --with-slibdir (unlike the libgcc-sjlj-1.dll, which can be overridden and which I have working multilib with a minor patch to gcc/config/t-cygming), nor do they obey the version specific runtime libs directory like the native toolchain does. In addition, the mulitlib install can clobber the dlls in that (wrong) bindir with the wrong arch type (the 32bit install puts the 64 bit version there after all is said and done). Given that the trunk of GCC is in stage 4, I wouldn't expect any of this to be fixed prior to the release even if patches were submitted since I wouldn't expect this to be classified as a P1 issue (I don't think the w64-mingw32 toolchain is considered to be a primary target, is it?) My frustration right now is that the GCC trunk has been in stage 4 since December...aside from the fact that I would be wary personally of moving to a stage 1 or 2 trunk of 4.6 just to get a working mulitilib gcc for these targets... After saying all that, the documentation about multilib should maybe have some caveats... ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ Mingw-w64-public mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
