On Sun, Mar 21, 2010 at 7:24 PM, Doug Semler <[email protected]> wrote: > 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 :)
Oh... well, hmm.... We should probably change that. In my defense, I've been away for a while :) > 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. There's a few choices. Foremost, I would bribe Kai into getting this committed to 4.6 the moment it opens up into stage 1. That way, you are essentially using 4.5+patches, as opposed to somewhere in the middle of stage 1 4.6, which will have a lot more churn in the code. The best way to do that would be to have the binutils side already done. Beyond that... just grin and bear it? I dunno.. I'm open to suggestions. How do you want us to support you? > 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
