X-Recipient: archive-cygwin AT delorie DOT com
X-Spam-Check-By: sourceware.org
From: "Dave Korn" <dave DOT korn AT artimi DOT com>
To: <cygwin AT cygwin DOT com>
References: <announce.001001c91336$91e70d10$9601a8c0 AT CAM DOT ARTIMI DOT COM> <48C8FE4D DOT 1090103 AT users DOT sourceforge DOT net> <013401c9140b$22b569c0$9601a8c0 AT CAM DOT ARTIMI DOT COM> <48CA2107 DOT FE8D0CB2 AT dessent DOT net>
Subject: RE: [ANNOUNCEMENT] New experimental package: gcc4-4.3.0-1
Date: Fri, 12 Sep 2008 14:27:39 +0100
Message-ID: <01cb01c914db$53d34d80$9601a8c0@CAM.ARTIMI.COM>
MIME-Version: 1.0
Content-Type: text/plain; 	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
In-Reply-To: <48CA2107.FE8D0CB2@dessent.net>
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Precedence: bulk
List-Id: <cygwin.cygwin.com>
List-Unsubscribe: <mailto:cygwin-unsubscribe-archive-cygwin=delorie DOT com AT cygwin DOT com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com

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/