On Sun, Mar 21, 2010 at 8:31 PM, NightStrike <[email protected]> wrote: > 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? >
Oh, I don't need you to support me in particular...I'm a pretty smart guy :) ... I just don't like reinventing the wheel is all :) In fact I'd be willing to volunteer to help with issues like this (in what little free time I have that is) - at the least on discussing things and at the most suggesting ideas or submitting patches for discussion. I'm still waiting for FSF paperwork myself so that I can do things on the binutils side, and I'll probably do FSF paperwork on the gcc side as well so that anything I run into can be at least submitted for comment without problem.. The biggest thing right now is that there are three projects that are interlinked...a change in behavior in one may require a change in all three of binutils, gcc, and the runtime...and really, where do you discuss those changes, all three lists? Even something as seemingly small as the underscore stuff for x64 is something that cascades really quickly... For example, the underscore stuff: the binutils ld right now doesn't support turning it off without a patch, which means that import and export objects can't be built during link without the option (you get a bunch of 'cannot export' stuff) Even with the patch, gcc has the -fno-leading-underscore option, but if you build mingw x64 with the no leading underscores, you have to remember to build everything (from target libraries to your own code) from that point forward with that option, or you need to patch gcc to default to no leading underscore on 64 bit, which has its own set of problems. but that leads to: gcc will still not link 64 bit dlls correctly without being patched, because the entry point will no longer be correct in the spec file. In addition, there's still the matter of getting the --no-leading-underscores option to the (patched) binutils link command line correctly...which means that not only must -fno-leading-underscore be passed on the command line, but also -Wl,--no-leading-underscores... Which also leads to: how can gcc determine which way to go? If you, for example, have a linker that defaults to the no leading underscore method, you want to link with DllMainCrtStartup symbol. If you have a mingw toolchain that was built with -fno-leading-underscore, you also want this. In addition, if you want to change the default, you have to change the default in all of the tools in the chain at the same time. You can't use a binutils that defaults to no leading underscore in the same chain as a gcc or mingw that does, etc. For me, that's not a big deal, because I build the entire toolchain in one shot. However, since the three parts of the toolchain can be built and installed separately, it means ensuring that you match what is already installed...Then, there's the interoperability with code that has already been compiled (archives, import libraries, etc)...in order to link properly, the no leading underscore toolchain must be used to rebuild everything that you want to use. Which is why I'd like to see a default (even as a patch for 4.5) configure option available for all three parts of the toolchain (the same name of course so it can be used in a config.site file for example), so that the behavior of all three toolchains can default to one way or the other. You've already got the beginnings of it in the mingw part, and Kai has the patch for ld - so for that all that would be needed is a bfd/configure option that changes the TARGET_UNDERSCORE (and targ_underscore in config.bfd) behavior. GCC is slightly more problematic, but it's actually not too bad if you're not building multilib. Considering the fact that multilib builds are not necessarily working anyway, it can be hacked :) (sorry for being so long winded) ------------------------------------------------------------------------------ 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
