Dave Korn wrote: > > Why bother? > > Hence the "may". I don't plan to bother for myself, but it depends if I
Please don't. gcc isn't special in this regard, it shouldn't receive any special treatment. bash fails without cygintl-8.dll and I don't think anyone is proposing to statically link libintl into bash just because some people seem to find ways to screw up their installations by not installing libintl8. If there's a problem we need to fix the root cause, not paper it over. Besides, in 1.7 there is a sensible error message when a DLL isn't found. > 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. > The problem with making shared libstdc - it can be done - is that it shows > regressions, because win32 doesn't currently fully support the semantics of > weak symbols like ELF does. Specifically, since a DLL has to be > fully-resolved when it is linked, any references to e.g. operators new/delete > get statically resolved as internal calls within the DLL, and then when you > attempt to define a custom operator new/delete override within your > executable, it doesn't get interposed between the already-resolved calls and > their destinations within the DLL. > > 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 -- though I would even argue that we should go one step farther and make it the default and say that if you need to override operator new you select the static libstdc++. 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. 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. > > 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.) Brian -- 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/
