Re: [Mingw-w64-public] Question about the undercore in svn

[NightStrike <nig...@gm...>]

On Mon, Mar 22, 2010 at 3:22 PM, Doug Semler <dou...@gm...> wrote:
> On Sun, Mar 21, 2010 at 8:31 PM, NightStrike <nig...@gm...> wrote:
>> On Sun, Mar 21, 2010 at 7:24 PM, Doug Semler <dou...@gm...> wrote:
>>> On Sun, 21 Mar 2010 18:37:12 NightStrike wrote:
>>>> On Sun, Mar 21, 2010 at 2:10 PM, Doug Semler <dou...@gm...> 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)
>

These are reasons that I would much prefer to force whoever we have to
to accept a patch to gcc 4.5 before it's released.  There will be a
large time gap between 4.5 and 4.6, and it will be painful to maintain
things going forward.  We should REALLY try to get this into 4.5.