From nobody@FreeBSD.ORG Wed Sep  1 08:17:03 1999
Return-Path: <nobody@FreeBSD.ORG>
Received: by hub.freebsd.org (Postfix, from userid 32767)
	id B587214E17; Wed,  1 Sep 1999 08:17:03 -0700 (PDT)
Message-Id: <19990901151703.B587214E17@hub.freebsd.org>
Date: Wed,  1 Sep 1999 08:17:03 -0700 (PDT)
From: bostic@sleepycat.com
Sender: nobody@FreeBSD.ORG
To: freebsd-gnats-submit@freebsd.org
Subject: gcc fails load against library with both C++ and C modules
X-Send-Pr-Version: www-1.0

>Number:         13525
>Category:       gnu
>Synopsis:       gcc fails load against library with both C++ and C modules
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    freebsd-bugs
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Wed Sep  1 08:20:01 PDT 1999
>Closed-Date:    Wed May 21 06:44:41 PDT 2003
>Last-Modified:  Wed May 21 06:44:41 PDT 2003
>Originator:     Keith Bostic
>Release:        FreeBSD 3.2-STABLE
>Organization:
Sleepycat Software
>Environment:
Not available.
>Description:
I'm having trouble with gcc and a dynamic shared library that
includes both C++ and C sources.

I'm using gcc 2.7.2.1 with gld 2.8.1.

I've seen this problem on BSD/OS 4.0 and FreeBSD 3.2-STABLE.

Here are the steps:

1. Build a dynamic shared library that contains both C++ and
   C sources.  (The C++ modules are a thin API on top of the
   C sources -- they call the C modules, but C modules never
   call or reference symbols in the C++ modules.)

2. Build a C-source program and use gcc to link against the
   library.  Errors appear, such as:

abyssinian:build_local {312} cc -g -I. -Wall -W t.c .libs/libdb-3.0.so
t.c: In function `main':
.libs/libdb-3.0.so: undefined reference to `ostream::operator<<(char const *)'
.libs/libdb-3.0.so: undefined reference to `terminate(void)'

3. Confirm that those symbols don't appear in any C modules:

abyssinian:build_local {313} nm -o *.lo | egrep terminate
cxx_app.lo:         U terminate__Fv
cxx_except.lo:         U terminate__Fv
cxx_lock.lo:         U terminate__Fv
cxx_log.lo:         U terminate__Fv
cxx_mpool.lo:         U terminate__Fv
cxx_table.lo:         U terminate__Fv
cxx_txn.lo:         U terminate__Fv

4. Note, you can build the source file correctly if you use C++:

abyssinian:build_local {315} g++ -g -I. -Wall -W t.c .libs/libdb-3.0.so

   works.

Does anybody understand what the problem is, here?

Are there any suggested workarounds?  Is it a bad idea to include
both C++ and C modules in the same library?

>How-To-Repeat:
Here are the steps:

1. Build a dynamic shared library that contains both C++ and
   C sources.  (The C++ modules are a thin API on top of the
   C sources -- they call the C modules, but C modules never
   call or reference symbols in the C++ modules.)

2. Build a C-source program and use gcc to link against the
   library.  Errors appear, such as:

abyssinian:build_local {312} cc -g -I. -Wall -W t.c .libs/libdb-3.0.so
t.c: In function `main':
.libs/libdb-3.0.so: undefined reference to `ostream::operator<<(char const *)'
.libs/libdb-3.0.so: undefined reference to `terminate(void)'

3. Confirm that those symbols don't appear in any C modules:

abyssinian:build_local {313} nm -o *.lo | egrep terminate
cxx_app.lo:         U terminate__Fv
cxx_except.lo:         U terminate__Fv
cxx_lock.lo:         U terminate__Fv
cxx_log.lo:         U terminate__Fv
cxx_mpool.lo:         U terminate__Fv
cxx_table.lo:         U terminate__Fv
cxx_txn.lo:         U terminate__Fv

4. Note, you can build the source file correctly if you use C++:

abyssinian:build_local {315} g++ -g -I. -Wall -W t.c .libs/libdb-3.0.so

   works.

>Fix:


>Release-Note:
>Audit-Trail:
State-Changed-From-To: open->feedback 
State-Changed-By: iedowse 
State-Changed-When: Mon Jan 21 13:17:03 PST 2002 
State-Changed-Why:  

Does this problem still exist? 

http://www.FreeBSD.org/cgi/query-pr.cgi?pr=13525 

From: Ian Dowse <iedowse@maths.tcd.ie>
To: Keith Bostic <bostic@sleepycat.com>
Cc: freebsd-gnats-submit@freebsd.org
Subject: Re: gnu/13525: gcc fails load against library with both C++ and C modules 
Date: Tue, 22 Jan 2002 01:06:25 +0000

 In message <200201212132.g0LLWwH11686@abyssinian.sleepycat.com>, Keith Bostic w
 rites:
 >Sorry, but I haven't the slightest idea -- it's been 2 1/2 years.
 >There's a test case in the PR, so you should be able to find out.
 
 Thanks for the reply - yes, it seems that the issue is still present.
 The following script reproduces it directly (cc'd to gnats for
 future reference).
 
 Ian
 
 #!/bin/sh
 
 cat > a.c << EOF
 void a(void) {}
 EOF
 
 cat > b.cc << EOF
 #include <iostream.h>
 extern "C" { void a(void); } 
 class b { public: void A(); };
 void b::A() { a(); cout << "a"; }
 EOF
 
 cat > c.c << EOF
 extern void a(void);
 int main() { a(); return 0; }
 EOF
 
 gcc -Wall -c -fpic a.c
 c++ -Wall -c -fpic b.cc
 gcc -shared -o libab.so a.o b.o
 gcc -Wall -o c c.c ./libab.so
 
State-Changed-From-To: feedback->open 
State-Changed-By: iedowse 
State-Changed-When: Mon Jan 21 17:11:47 PST 2002 
State-Changed-Why:  

Still a bug. 

http://www.FreeBSD.org/cgi/query-pr.cgi?pr=13525 

From: Sheldon Hearn <sheldonh@starjuice.net>
To: iedowse@FreeBSD.org
Cc: bug-followup@freebsd.org
Subject: Re: gnu/13525: gcc fails load against library with both C++ and C modules 
Date: Thu, 31 Jan 2002 12:06:21 +0200

 On Mon, 21 Jan 2002 17:12:18 PST, iedowse@FreeBSD.org wrote:
 
 > Synopsis: gcc fails load against library with both C++ and C modules
 > 
 > State-Changed-From-To: feedback->open
 > State-Changed-By: iedowse
 > State-Changed-When: Mon Jan 21 17:11:47 PST 2002
 > State-Changed-Why: 
 > 
 > Still a bug.
 
 As contributed software, it's very unlikely that this will be fixed
 unless it's reported to the GCC distribution maintainers.
 
 Has this been done?
 
 Ciao,
 Sheldon.
State-Changed-From-To: open->feedback  
State-Changed-By: gerald 
State-Changed-When: Sun Apr 6 14:22:12 PDT 2003 
State-Changed-Why:  
Have you reported this back to the GCC developers using 
http://gcc.gnu.org/bugs.html ? 
This does not seem to be a FreeBSD-specific issue, so I'll 
probably close this PR (ideally, once you have submitted the 
report to the GCC folks). 

http://www.freebsd.org/cgi/query-pr.cgi?pr=13525 
State-Changed-From-To: feedback->closed 
State-Changed-By: gerald 
State-Changed-When: Wed May 21 06:41:18 PDT 2003 
State-Changed-Why:  
I debugged this in further depth, and it is apparently operator error: As 
soon as you use any C++ library routines (whether directly or indirectly) 
you need to link the final binary using g++, not gcc, and the g++ driver 
then will link any additional libraries required. 

The following would have worked for the example provided: 
gcc -Wall -c -fpic a.c 
c++ -Wall -c -fpic b.cc 
gcc -shared -o libab.so a.o b.o 
gcc -Wall -c c.c 
c++ -o c c.o ./libab.so 

http://www.freebsd.org/cgi/query-pr.cgi?pr=13525 
>Unformatted:
