🚀 go-pugleaf

Novice wrote:

> I'm attempting to compile, link and then execute some C++ code I've
> written - I've executed it in the past, but recently made some changes to
> it on one platform and then ported it BACK over to Mandrake (i.e. I have
> compiled, linked and executed the code previously on the same Mandrake
> computer that I'm trying to do now) and attempted to re-compile and link
> on
> the same Mandrake computer I had it running on before.  Unfortunately, I
> can't get ride of the following linker errors:
> 
> TimSystem.o(.text+0x1bf): In function
> `__static_initialization_and_destruction_0(int, int)':
> : undefined reference to
> `txl::io::BufferedOutputStream::BufferedOutputStream[in-charge]()'
> collect2: ld returned 1 exit status
> 
> I've done some google'ing on the phrases:
> "undefined reference" and "in-charge"

The "undefined reference" is what it appears - the linker can't locate the
symbol it emits.

Read "in-charge" as "ctor" and "not-in-charge" as "dtor".

That lengthy "static_init..." (or very similar depending on gcc version) is
used internally by gcc to handle construction and destruction of objects
which your code has declared static. These are the ones that have their
ctor invoked prior to entering main() and their dtor invoked after leaving
it. In other words, those pesky uncatchables.

The error can than be read as...

TimSystem defines a static object for which the txl::io:
BufferedOutputStream default ctor has been declared but for which no such
definition can be found.

The .text+0x1bf tells you exactly where to locate the problem should you
desire to wade into the object code.

> In most cases, it appears the user wasn't:
> 1. using g++ or
> 2. using the proper form for includes or
> 3. not using namespaces properly

Or, as a realised on second reading, 'cos you overwrote the file. ;-)

[snip]
 
> using namespace txl::io;
> 
> SmtPrintStreamPtr System::out = SmtPrintStreamPtr (new
> PrintStream(SmtBufferedOutputStreamPtr (new
> txl::io::BufferedOutputStream()), true));
^^^
Unless you've any more static objects not posted then this is it. It could
do with losing its txl::io:: prefix as your 'using' that by this point
anyway (?is it txl::io or txl::io::txl::io?). It ought not be a showstopper
though, just vagueness for the compiler to sort out.

You'll need a handler for the above unless you can guarantee no exceptions
will occur (easier to use auto_ptr).

[snip]

> Here is the definition of the default constructor from
> txl::io::BufferedOutputStream
> -----------------------------------------
>             txl::io::BufferedOutputStream::BufferedOutputStream (){
>             }

There is an occasional problem with gcc which is what originally prompted my
reply.

namespace txl   {
        namespace io    {
                BufferedOutputStream::BufferedOutputStream() {
                }
        }
}

I've always used the more verbose latter form so it's never bitten me which
means someone else will have to fill in the details. Unlikely an issue -
see below.

> -----------------------------------------
> 
> Here is the way I'm compiling:
> -----------------------------------------
> g++ -DVERIFY -DNO_VERISOFT -c *.cpp
> -----------------------------------------

It'll work.
 
> No errors from the compilation.  Then here is the way I'm linking:
> -----------------------------------------
> g++ -DVERIFY -DNO_VERISOFT -o *.o
> -----------------------------------------

I assumed that was a typo. Bugger! It wasn't was it? You've specified the
executable name to be the first object filename that the shell returns for
*.o and now that I do the above I get exactly the same error.

> I've also attempted ordering all of the .o files explicitly (i.e. not
> using *.o) with no better results.
> 
> Any suggestions?

Automate it. Here's a get-you-started (GNU make) 'makefile'. Preserve the
tabs.

CPPFLAGS        ?=-DVERIFY -DNO_VERISOFT
CXXFLAGS        ?=-ansi -pedantic -W -Wall -Werror -g -O0
LDFLAGS         ?=

NAM             =c
ITM             =foo bar
OBJ             =$(ITM:%=%.o)
DEP             =$(ITM:%=%.d)
EXE             =$(NAM)

%.o : %.cpp
                $(CXX) -MMD -c -o $@ $(CPPFLAGS) $(CXXFLAGS) $<

.PHONY:         all clean allclean

all:            $(EXE)

clean:
                rm -f $(OBJ)

allclean:       clean
                rm -f $(DEP) $(EXE)

$(EXE): $(OBJ)
                $(CXX) -o $(EXE) $(OBJ) $(LDFLAGS)

-include        $(DEP)

It's the minimal I can dream up which will generate header dependancies for
you (the *.d files that appear). Refer to gmake/g++/gcc manuals. You may at
least have to tweek CXXFLAGS (lookup what ?= does btw), sometimes -pedantic
barfs inside system headers.

Plonk your executable name into NAM in place of 'c' and all your sourcefile
names (minus their extenders) into ITM in place of 'foo' and 'bar'.

It's just one of a zillion ways to do such a thing. Consider it a generic
template useful for quickly building source - ordinarily you'd write a
customised one (or use autotools).

Note I've cut it down to the extent it won't handle anything but C++ *.cpp
files "correctly" and it's easy to break dependancy generation by fiddling
with the build rule (hint: duplicate it rather than adding %.cc %.C to it).


-- 
Guy Harrison

"Guy Harrison" <swamp-DEL-dog@ntlworld.com> wrote in message
news:49a971-7i42.ln1@sd.swampdog...
| Novice wrote:
|

[snip]

|
| Read "in-charge" as "ctor" and "not-in-charge" as "dtor".
|
| That lengthy "static_init..." (or very similar depending on gcc version)
is
| used internally by gcc to handle construction and destruction of objects
| which your code has declared static. These are the ones that have their
| ctor invoked prior to entering main() and their dtor invoked after leaving
| it. In other words, those pesky uncatchables.
|
| The error can than be read as...
|
| TimSystem defines a static object for which the txl::io:
| BufferedOutputStream default ctor has been declared but for which no such
| definition can be found.
|
| The .text+0x1bf tells you exactly where to locate the problem should you
| desire to wade into the object code.
|
| > In most cases, it appears the user wasn't:
| > 1. using g++ or
| > 2. using the proper form for includes or
| > 3. not using namespaces properly
|
|


Sorry I don't really get this:
| Or, as a realised on second reading, 'cos you overwrote the file. ;-)

Do you mean that is another frequent problem is that users building/linking
code overwrite some of the necessary files?


| [snip]
|
| > using namespace txl::io;
| >
| > SmtPrintStreamPtr System::out = SmtPrintStreamPtr (new
| > PrintStream(SmtBufferedOutputStreamPtr (new
| > txl::io::BufferedOutputStream()), true));
| ^^^
| Unless you've any more static objects not posted then this is it. It could
| do with losing its txl::io:: prefix as your 'using' that by this point
| anyway (?is it txl::io or txl::io::txl::io?). It ought not be a
showstopper
| though, just vagueness for the compiler to sort out.

It is txl::io as you correctly deduced in this code:
 namespace txl   {
         namespace io    {
                 BufferedOutputStream::BufferedOutputStream() {
                 }
         }
 }


|
| You'll need a handler for the above unless you can guarantee no exceptions
| will occur (easier to use auto_ptr).

I am using smart pointers - though instead of auto_ptr I'm using my own
specialized version.

|
| [snip]
|
| > Here is the definition of the default constructor from
| > txl::io::BufferedOutputStream
| > -----------------------------------------
| >             txl::io::BufferedOutputStream::BufferedOutputStream (){
| >             }
|
| There is an occasional problem with gcc which is what originally prompted
my
| reply.
|
| namespace txl   {
|         namespace io    {
|                 BufferedOutputStream::BufferedOutputStream() {
|                 }
|         }
| }
|
| I've always used the more verbose latter form so it's never bitten me
which
| means someone else will have to fill in the details. Unlikely an issue -
| see below.

[snip]

| > No errors from the compilation.  Then here is the way I'm linking:
| > -----------------------------------------
| > g++ -DVERIFY -DNO_VERISOFT -o *.o
| > -----------------------------------------
|
| I assumed that was a typo. Bugger! It wasn't was it? You've specified the
| executable name to be the first object filename that the shell returns for
| *.o and now that I do the above I get exactly the same error.
|
| > I've also attempted ordering all of the .o files explicitly (i.e. not
| > using *.o) with no better results.
| >
| > Any suggestions?
|
| Automate it. Here's a get-you-started (GNU make) 'makefile'. Preserve the
| tabs.
|

[snip]

Thanks for the makefile template - I should have been making use of one to
start with - but I was hoping to avoid having to learn how to write
makefiles for this project.

|
| It's just one of a zillion ways to do such a thing. Consider it a generic
| template useful for quickly building source - ordinarily you'd write a
| customised one (or use autotools).
|
| Note I've cut it down to the extent it won't handle anything but C++ *.cpp
| files "correctly" and it's easy to break dependancy generation by fiddling
| with the build rule (hint: duplicate it rather than adding %.cc %.C to
it).
|

When I use your makefile after compiling all of the cpp files I get the
following:
[cassidy@txl thesisCode]$ make
g++ -o timsProgram Throwable.o BufferedOutputStream.o BufferedWriter.o
Hashtable.o MainEntry.o MonitorDataLINUX.o TimDynamic.o TimMonitor.o
TimObject.o TimString.o TimSystem.o
BufferedOutputStream.o(.text+0xe): In function
`txl::io::BufferedOutputStream::BufferedOutputStream[not-in-charge]()':
: undefined reference to
`txl::io::FilterOutputStream::FilterOutputStream[not-in-charge]()'
BufferedOutputStream.o(.text+0x74): In function
`txl::io::BufferedOutputStream::BufferedOutputStream[in-charge]()':
: undefined reference to
`txl::io::FilterOutputStream::FilterOutputStream[not-in-charge]()'
BufferedOutputStream.o(.gnu.linkonce.d._ZTVN4txl2io20BufferedOutputStreamE+0
x50): undefined reference to `txl::io::FilterOutputStream::close()'
BufferedOutputStream.o(.gnu.linkonce.t._ZN4txl2io18FilterOutputStreamD2Ev+0x
b): In function `txl::io::FilterOutputStream::~FilterOutputStream
[not-in-charge]()':
: undefined reference to `vtable for txl::io::FilterOutputStream'
BufferedOutputStream.o(.gnu.linkonce.t._ZN4txl2io18FilterOutputStreamD2Ev+0x
17): In function `txl::io::FilterOutputStream::~FilterOutputStream
[not-in-charge]()':
: undefined reference to `vtable for txl::io::FilterOutputStream'
BufferedOutputStream.o(.gnu.linkonce.d._ZTIN4txl2io20BufferedOutputStreamE+0
x8): undefined reference to `typeinfo for txl::io::FilterOutputStream'
TimSystem.o(.gnu.linkonce.t._ZN4txl2io11PrintStreamC1E8SmartPtrINS0_12Output
StreamEiEb+0x14): In function
`txl::io::PrintStream::PrintStream[in-charge](SmartPtr<txl::io::OutputStream
, int>, bool)':
: undefined reference to
`txl::io::FilterOutputStream::FilterOutputStream[not-in-charge]()'
TimSystem.o(.gnu.linkonce.d._ZTIN4txl2io11PrintStreamE+0x8): undefined
reference to `typeinfo for txl::io::FilterOutputStream'
collect2: ld returned 1 exit status
make: *** [timsProgram] Error 1

To me it looks like the generated destructor (as denoted by [not-in-charge])
and constructor (as denoted by [in-charge] only for BufferedOutputStream)
for BufferedOutputStream and FilterOutputStream is causing problems.  In
addition, the FilterOutputStream close function and the reference that
TimSystem has to PrintStream.  Though all the errors are likely derived from
one problem - perhaps the generated destructor for BufferedOutputStream?

Thanks again,
Novice

[snip]

"Novice" <cassidy@cs.queensuDOTca> wrote in message
news:bnu3b2$gun$1@knot.queensu.ca...
|
| "Guy Harrison" <swamp-DEL-dog@ntlworld.com> wrote in message
| news:49a971-7i42.ln1@sd.swampdog...
| | Novice wrote:

[snip]

|
| When I use your makefile after compiling all of the cpp files I get the
| following:
| [cassidy@txl thesisCode]$ make
| g++ -o timsProgram Throwable.o BufferedOutputStream.o BufferedWriter.o
| Hashtable.o MainEntry.o MonitorDataLINUX.o TimDynamic.o TimMonitor.o
| TimObject.o TimString.o TimSystem.o
| BufferedOutputStream.o(.text+0xe): In function
| `txl::io::BufferedOutputStream::BufferedOutputStream[not-in-charge]()':
| : undefined reference to
| `txl::io::FilterOutputStream::FilterOutputStream[not-in-charge]()'
| BufferedOutputStream.o(.text+0x74): In function
| `txl::io::BufferedOutputStream::BufferedOutputStream[in-charge]()':
| : undefined reference to
| `txl::io::FilterOutputStream::FilterOutputStream[not-in-charge]()'
|
BufferedOutputStream.o(.gnu.linkonce.d._ZTVN4txl2io20BufferedOutputStreamE+0
| x50): undefined reference to `txl::io::FilterOutputStream::close()'
|
BufferedOutputStream.o(.gnu.linkonce.t._ZN4txl2io18FilterOutputStreamD2Ev+0x
| b): In function `txl::io::FilterOutputStream::~FilterOutputStream
| [not-in-charge]()':
| : undefined reference to `vtable for txl::io::FilterOutputStream'
|
BufferedOutputStream.o(.gnu.linkonce.t._ZN4txl2io18FilterOutputStreamD2Ev+0x
| 17): In function `txl::io::FilterOutputStream::~FilterOutputStream
| [not-in-charge]()':
| : undefined reference to `vtable for txl::io::FilterOutputStream'
|
BufferedOutputStream.o(.gnu.linkonce.d._ZTIN4txl2io20BufferedOutputStreamE+0
| x8): undefined reference to `typeinfo for txl::io::FilterOutputStream'
|
TimSystem.o(.gnu.linkonce.t._ZN4txl2io11PrintStreamC1E8SmartPtrINS0_12Output
| StreamEiEb+0x14): In function
|
`txl::io::PrintStream::PrintStream[in-charge](SmartPtr<txl::io::OutputStream
| , int>, bool)':
| : undefined reference to
| `txl::io::FilterOutputStream::FilterOutputStream[not-in-charge]()'
| TimSystem.o(.gnu.linkonce.d._ZTIN4txl2io11PrintStreamE+0x8): undefined
| reference to `typeinfo for txl::io::FilterOutputStream'
| collect2: ld returned 1 exit status
| make: *** [timsProgram] Error 1
|

[snip]

I've since created more cpp files for each of the header files and added
those arguments and now I get:
[cassidy@txl thesisCode]$ make
g++ -o timsProgram OutputStream.o FilterOutputStream.o
BufferedOutputStream.o Throwable.o BufferedWriter.o Hashtable.o MainEntry.o
MonitorDataLINUX.o TimDynamic.o TimMonitor.o TimObject.o TimString.o
TimSystem.o
BufferedOutputStream.o(.text+0x1a): In function
`txl::io::BufferedOutputStream::BufferedOutputStream[not-in-charge]()':
: undefined reference to `vtable for txl::io::BufferedOutputStream'
BufferedOutputStream.o(.text+0x26): In function
`txl::io::BufferedOutputStream::BufferedOutputStream[not-in-charge]()':
: undefined reference to `vtable for txl::io::BufferedOutputStream'
BufferedOutputStream.o(.text+0x80): In function
`txl::io::BufferedOutputStream::BufferedOutputStream[in-charge]()':
: undefined reference to `vtable for txl::io::BufferedOutputStream'
BufferedOutputStream.o(.text+0x8c): In function
`txl::io::BufferedOutputStream::BufferedOutputStream[in-charge]()':
: undefined reference to `vtable for txl::io::BufferedOutputStream'
BufferedOutputStream.o(.text+0xe6): In function
`txl::io::BufferedOutputStream::BufferedOutputStream[not-in-charge](SmartPtr
<txl::io::OutputStream, int>)':
: undefined reference to `vtable for txl::io::BufferedOutputStream'
BufferedOutputStream.o(.text+0xf2): more undefined references to `vtable for
txl::io::BufferedOutputStream' follow
collect2: ld returned 1 exit status
make: *** [timsProgram] Error 1

I don't know why - but the linker seems to be having a problem with the
constructor and destructor of BufferedOutputStream - I'm now explicitly
writing the implementation of the default constructor and the destructor in
the implementation/source file of BufferedOutputStream and
FilterOutputStream (which BufferedOutputStream extends).

Thanks,
Novice

[snip]

I have no idea why, but after deleting all the files from the directory,
restarting the machine, re-sending the files to the machine, then
re-compiling fixed my woes.

But thanks to Guy for some good suggestions - especially the makefile - but
also the "proper" way to put methods that are in classes within namespaces
in implementation files (i.e. not the header files):

namespace a {
  namespace b {
    void SomeClass::foo (){
    }
  }
}

Thanks again,
Novice