Mail Archives: cygwin/2008/09/12/09:28:23
Brian Dessent wrote on 12 September 2008 08:58:
> Dave Korn wrote:
>
>>> Why bother?
>>
>> Hence the "may". I don't plan to bother for myself, but it depends if
>> I
>
> Please don't.
OK. Suits me.
>> That's all I get from a default build, I'm not sure if
>> --disable-libjava is the upstream default right now but knowing the
>> somewhat sorry state of libjava on cygwin I wouldn't be surprised.
>> (I'll give it a go and if anything manages to compile, I'll ship it.)
>
> You do need --enable-libjava on Cygwin, it's not enabled by default.
> Aaron posted a patch to build is as a DLL and with that it should be
> usable again, at least with DW2 (not SJLJ.) The bulk of the issues as I
> understand it were with the fact that statically linking java just
> doesn't work very well.
OK, will be in the next update but one (have a minor refresh coming
imminently.)
>> This would make the C++ compiler non-compliant, so as it all works OK
>> with a static library, I'm shipping it that way for now.
>
> IMHO, despite the above we should still ship shared libstdc++ even if
> it's not the default
I'd go that far.
> -- though I would even argue that we should go one
> step farther and make it the default
I won't ship a compiler that's non-compliant by default, if I can possibly
avoid it. I don't mind making non-compliant behaviour available through a
command-line option, just not the default.
> and say that if you need to
> override operator new you select the static libstdc++.
How exactly would a package maintainer know if, somewhere deep down in an
included library package, there's something that critically depends on weak
linking against libstdc++? They wouldn't, AFAICS, and the outcome would be a
very hard-to-find bug.
> Otherwise, we
> just get ourselves into ABI compatibility hell because every C++ library
> gets a copy of libstdc++ linked into it, which means they are tied to
> the compiler version. As it is now we are going to have to rebuild all
> libstdc++-using code in the distro with the new compiler because up
> until now we had no choice but static libstdc++, but by not stopping
> this insanity now we only prolong it.
>
>> I plan to work on improving weak symbol support in binutils to resolve
>> this problem in the long run; I think we can make it work with a little
>> bit of thunk stubbery[*].
>
> PE does have weakref, where you supply a backup symbol name along with
> the reference.
That's what binutils' existing pe weak symbol support is based on, yes.
> If the symbol is defined elsewhere then that definition
> is used, otherwise the backup one supplied with the weakref is used --
> but in either case it does not go undefined. But I'm not sure how this
> would be useful in the case outlined above.
The problem is the major difference between ELF DSOs and PE DLLS: DLLs have
to be fully resolved at link-time, not load-time. So, when you're building
libstdc++ all those internal references to operator new have to be resolved
somewhere, and as the weakref is the only definition available that's where
they get linked to. Permanently and forever.
If they were instead resolved to some kind of thunk that could do a lookup
at runtime for non-weak versions of the same symbol, we'd be golden. Well,
we'd need to make sure the non-weak versions were all declspecced dllexport
somehow, but that would do it for us.
>>> Also, is OpenMP available? Is it being worked on?
>>
>> ? dunno. That's a whole nother story, isn't it?
>
> Should work fine. Requires explicit --enable-libgomp though (not
> enabled by default.)
Will give it a go.
cheers,
DaveK
--
Can't think of a witty .sigline today....
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
- Raw text -