Hello Steve!

Friday October 15 2004 12:36, you wrote to me:

 SR> Before we get much further I would like to thank you for your
 SR> assistance.

Absolutely no problem..

 BS>> Hm. I'm not a C++ fan my self, but did you post the error?

 SR> The pattern seems to repeat for each module in btree.

 SR> gcc -shared -nostartfiles btree.o bt_open.o bt_look.o bt_ins.o
 SR> bt_rem.o btnode.o palist.o btreec.o blkio.o bbuf.o blkiobuf.o dllc.o
 SR> -o libmaxbt.so btree.o(.text+0xc):btree.cc: undefined reference to
 SR> `___gxx_personality_sj0' btree.o(.text+0x17a):btree.cc: undefined
 SR> reference to `___gxx_personality_sj0' btree.o(.text+0x3a1):btree.cc:
 SR> undefined reference to
 SR> `___gxx_personality_sj0' btree.o(.text+0x62e):btree.cc: undefined
 SR> reference to `___gxx_personality_sj0' btree.o(.text+0x6c3):btree.cc:
 SR> undefined reference to
 SR> `___cxa_begin_catch' btree.o(.text+0x6d2):btree.cc: undefined
 SR> reference to `___cxa_end_catch' btree.o(.text+0x703):btree.cc:
 SR> undefined reference to
 SR> `___gxx_personality_sj0' btree.o(.text+0x993):btree.cc: undefined
 SR> reference to `___gxx_personality_sj0' btree.o(.text+0xbfc):btree.cc:
 SR> undefined reference to
 SR> `___gxx_personality_sj0' btree.o(.text+0xc92):btree.cc: undefined
 SR> reference to `___cxa_begin_catch' btree.o(.text+0xca1):btree.cc:
 SR> undefined reference to `___cxa_end_catch'

 BS>> And g++ is just a wrapper for gcc, which automatically adds
 BS>> -lstdc++ on the linking. :)

 SR> I also follow the Cygwin area (it sounds like Cygwin doubles as a test
 SR> bed for Redhat) and have been told that at some time in the past
 SR> things were broken and we are to use g++ for C++ code.

The main problem is that -lstdc++ is missing in the make file, try to add
it manually and report to be if it works. :)

 SR> When I changed maximus/btree/Makefile to use g++ things seemed to get
 SR> better except that now I get warning messages grumbling about some
 SR> pointer code:

 SR> bbuf.cc: In member function `int BLOCKBUF::deinit()':
 SR> bbuf.cc:83: warning: deleting `void*' is undefined
 SR> bbuf.cc: In member function `int BLOCKBUF::get_lru(NNUM*, void*,
 SR> unsigned int*)
 SR>    ':
 SR> bbuf.cc:247: warning: deleting `void*' is undefined

 SR> The function prototypes in btree/track.h and btree/trackcom.h give
 SR> messages I have not seen before but am including them in case they are
 SR> confusing the linker:

 SR> track.h:45: warning: non-local function `int
 SR> TRACKER::AddMsg(TRK_MSG_NDX*)'
 SR>    uses anonymous type
 SR> trackcom.h:107: warning: `typedef struct  TRK_MSG_NDX' does
 SR> not
 SR>    refer to the unqualified type, so it is not used for linkage

 SR> At the end of btree/Makefile things really start to fall apart:

 SR> g++ -shared -nostartfiles dbase.o dbasec.o track.o trackc.o dllc.o -o
 SR> libmaxdb.so dbase.o(.text+0x15):dbase.cc: undefined reference to
 SR> `BLKIOBUF::BLKIOBUF[not-in-charge](unsigned)' dbase.o(.text+0x4f):dbas
 SR> e.cc: undefined reference to
 SR> `BLKIOBUF::BLKIOBUF[not-in-charge](unsigned)' dbase.o(.text+0xf8):dbas
 SR> e.cc: undefined reference to `BLKIOBUF::~BLKIOBUF
 SR> [not-in-charge]()' dbase.o(.text+0x122):dbase.cc: undefined reference
 SR> to `BLKIOBUF::~BLKIOBUF [not-in-charge]()'

 SR> Included in these are errors complaining about not being able to find
 SR> standard C library functions such as close() and size().

Hmm.. let's hope -lstdc++ would do it.

Bo


--- GoldED+/LNX 1.1.5