X-Recipient: archive-cygwin AT delorie DOT com
X-SWARE-Spam-Status: No, hits=-2.3 required=5.0 	tests=AWL,BAYES_00,SPF_PASS
X-Spam-Check-By: sourceware.org
Message-ID: <49B93C71.50809@gmail.com>
Date: Thu, 12 Mar 2009 16:46:41 +0000
From: Dave Korn <dave DOT korn DOT cygwin AT googlemail DOT com>
User-Agent: Thunderbird 2.0.0.17 (Windows/20080914)
MIME-Version: 1.0
To: Dave Korn <dave DOT korn DOT cygwin AT googlemail DOT com>
CC: cygwin AT cygwin DOT com
Subject: Re: [ANNOUNCEMENT] Updated: experimental package: gcc4-4.3.2-2
References: <49B90A2B DOT 3050907 AT alice DOT it> <49B92D24 DOT 3000802 AT gmail DOT com>
In-Reply-To: <49B92D24.3000802@gmail.com>
Content-Type: text/plain; charset=ISO-8859-15
Content-Transfer-Encoding: 7bit
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id: <cygwin.cygwin.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

Dave Korn wrote:

> Ok, for some reason it appears that libCore.dll.a exports symbols from 
> libstdc++:
> 
> DKAdmin AT ubik /work/root/test $ nm /work/root/lib/libCore.dll.a  |grep 
> St9exception 71d6b958 d .rdata$_ZTISt9exception 71d6ff40 d 
> .rdata$_ZTSSt9exception 71d6b958 D __ZTISt9exception 71d6ff40 D 
> __ZTSSt9exception
> 
> 
> Looks like the DLL got linked against static libstdc++, while the app links 
> against shared libstdc++?

  Nope, it uses -shared correctly.  Nor is the problem down to the auto-export
routines failing to recognize libstdc++ and inadvertently re-exporting its symbols
(cf. libnamencmp).  In fact, the re-exported symbols come from one of the .o files
from which the DLL is composed:

DKAdmin AT ubik /work/root
$ nm core/base/src/TSystem.o  | grep St9exception
00000000 r .rdata$_ZTISt9exception
00000000 r .rdata$_ZTSSt9exception
00000000 R __ZTISt9exception
00000000 R __ZTSSt9exception

DKAdmin AT ubik /work/root

  And the immediate reason for this is the way that TSystem.o is built:

------------------------build.log------------------------
g++-4 -O2 -pipe -Wall -Woverloaded-virtual -D_DLL -Iinclude  -I/usr/X11R6/include
  -o core/base/src/TSystem.o -c core/base/src/TSystem.cxx
------------------------build.log------------------------

  Why is a -D for _DLL present?  That is a reserved definition in the
implementation's namespace, and in particular it used when compiling libstdc++
itself, where it alters the effect of the library headers to declare all the
library APIs as dllexport - they are dllimport by default, which is what user
applications want to see.

  I manually re-ran the compile command without "-D_DLL" and got a good object file:

DKAdmin AT ubik /work/root
$ g++-4 -O2 -pipe -Wall -Woverloaded-virtual  -Iinclude  -I/usr/X11R6/include
 -o ./TSystem.2.o -c core/base/src/TSystem.cxx

DKAdmin AT ubik /work/root
$ nm ./TSystem.2.o | grep St9exception rtua
         U __ZTISt9exception

DKAdmin AT ubik /work/root
$

  So I'll now try rebuilding and retesting without _DLL defined anywhere and see
if it solves the problem.

    cheers,
      DaveK



--
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/