On Sun, 21 Mar 2010 18:37:12 NightStrike wrote: > On Sun, Mar 21, 2010 at 2:10 PM, Doug Semler <[email protected]> wrote: > > 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). > > Jon Y has a patch for all of that. > > > 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?) > > Yeah, it's not getting fixed in 4.5. And no, we aren't even a > secondary target :( > > > 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... > > Well, to be fair, we never advertised that it even exists... so.....
In both how-to-build docs, yes, you do :) I know that there was the "the tools now track gcc" statement and "no more need to patch gcc." One of the problems really is going to be requiring the use of the 4.6 trunk to get the correct behavior for installation of the toolchain (multilib notwithstanding, I still feel the installation of the target DLLs is also woefully incorrect, so I presume the patch mentioned above does that as well) unless there are also plans to backport them to 4.5, which I would doubt. I would never use the stage 1,2, or 3 trunks to build production code (well, maybe the stage 3 depending on the issues in it)-- they are just too unstable --which means I'll track the 4.5 branch for quite a while. Don't know what I'll do...wait for the patch(es) to be applied, do the work myself, or just deal with it (using nonmultilib, moving the files to where they should be, and modifying the installed .la files correctly...) OK...vent mode off :) ------------------------------------------------------------------------------ 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
