Re: [ANNOUNCEMENT] Updated: experimental package: gcc4-4.3.2-2

[Dave Korn <dave dot korn dot cygwin at googlemail dot com>]

Dave Korn wrote:

> Ok, for some reason it appears that libCore.dll.a exports symbols from 
> libstdc++:
> 
> DKAdmin@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@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@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@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@ubik /work/root
$ nm ./TSystem.2.o | grep St9exception rtua
         U __ZTISt9exception

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