Subject: Re: C++: aaaaaarrrrggghh!
To: David Bushong <dbushong@cory.eecs.berkeley.edu>
From: Jason Thorpe <thorpej@nas.nasa.gov>
List: port-mac68k
Date: 12/20/1996 15:26:35
[ I've CC'd Paul Kranenburg, the author of our a.out shared library
  implementation, and J.T. Conklin, who knows quite a lot about
  the m68k toolchain.  J.T. and Paul, I'd really appreciate it if
  you guys could read this and comment... ]

On Fri, 20 Dec 1996 15:17:25 -0800 (PST) 
 David Bushong <dbushong@cory.EECS.Berkeley.EDU> wrote:

 > OK, I'm really at my wits' end on this one.  I have completely reinstalled
 > base12 and comp12.  I've done everything short of formatting the hard
 > drive.  As a recap: *any* C++ program (even a text file with no includes,
 > just "main() { return 0; }"), will compile and link ok, but when I run it
 > (or any existing pre-compiled c++ apps I have), I get:
 > 
 > % ./foo
 > /usr/libexec/ld.so: Undefined symbol "_tgetstr" in foo:/usr/lib/libcurses.so.2.1
 > 
 > I am *not* including, implicitly linking, or in any way involving
 > libcurses!!  What on earth is going on???

It looks like libg++ implicitly includes libcurses, for the CursesW stuff.

This is _actually_ a bug in the dynamic linker... You're not actually
using anything that uses funtions in libcurses (and thus libtermcap), but
the dynamic linker seems to _think_ that you are.. You'll notice, this
problem does not exist undet NetBSD/sparc:

lestat (thorpej) /tmp 613% uname -sm
NetBSD sparc
lestat (thorpej) /tmp 614% cat foo.cc
main() { return 0; }
lestat (thorpej) /tmp 615% g++ foo.cc -o foo
lestat (thorpej) /tmp 616% ldd ./foo
./foo:
        -lg++.3 => /usr/lib/libg++.so.3.0 (0x10040000)
	-lstdc++.0 => /usr/lib/libstdc++.so.0.0 (0x10080000)
	-lm.0 => /usr/lib/libm.so.0.1 (0x100d0000)
	-lc.12 => /usr/lib/libc.so.12.8 (0x10100000)
	-lcurses.2 => /usr/lib/libcurses.so.2.1 (0x10180000)
lestat (thorpej) /tmp 617% ./foo

...i.e. it runs ok.

I noticed something like this problem while building X11R6.1 under
NetBSD/hp300 and NetBSD/sun3.  As far as I can tell, this is specific
to the m68k ports, and it seemed to appear when we upgraded to
gcc 2.7.2.

I must admit that I don't know where to start looking to solve the
problem... In the mean time, it may be worth also implcitly including
libtermcap with libg++.  This is a simple Makefile trick,

Jason R. Thorpe                                       thorpej@nas.nasa.gov
NASA Ames Research Center                               Home: 408.866.1912
NAS: M/S 258-6                                          Work: 415.604.0935
Moffett Field, CA 94035                                Pager: 415.428.6939