2010/3/22 Doug Semler <[email protected]>:
> 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...
You help is welcome and appreciated. The synchronization between all
three ventures (cygwin, mingw.org, and mingw-w64) is a bit exertive
but in general not that problematic. Danny, Dave, and I do coordinate
us.
But I agree that there are some venture-specific needs, which lead us
to introduce the -w64- venture key-part in configure, so that we can
support additional features the other ventures don't support, or
aren't interested in.
> 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.
Well, in fact is this entry-point a no issue. By a recent patch, ld is
able to select the proper entry-point without the need of specifying
the -e <entry>. So this argument is in fact deprecated. Major pain
here is the backward-compatibility necessary for older binutils. Buf
for 4.6 I would prefer to make a crued break in support of older
binutils versions (at least if configure for using no-underscore
variant).
> 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.
Yes, this is required for having real support of w64 ABI.
Kai
--
| (\_/) This is Bunny. Copy and paste
| (='.'=) Bunny into your signature to help
| (")_(") him gain world domination
------------------------------------------------------------------------------
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
