[Mingw-users] Error: undefined reference to Newbie::C++ in MinGW-Users

[Devin Carless]

Hello all,

Of recent, as a way of doing something useful with my time, I've begun to
teach myself C++. (Those of you wincing already need read no further.)
The only book available is eight years out of date and has no index to speak
of. Despite this and other travails, I've managed to defeat just about
every 'gotcha!' the language, libraries and compiler have thrown at me
so far.
Until the other day. I started getting linker errors that I simply could
not explain. They go away when I do things that, by all rights, shouldn't
do anything. So although I've managed to defeat these entymological
horrors, I have the feeling they're symptoms of a deeper problem, one
that I'm at a loss to diagnose or fix.

Specifics: I'm using the Bloodshed Dev-C++ 4 IDE and MinGW
2.95.2-1 MSVCRT on Windows98. The project I'm working on is
a fairly simple game, based on the old Lost Worlds booklets. (If you
don't know those, it's kind of a cross between Battleship and World
Fantasy Wrestling.)
The problem is that I keep getting undefined references to functions
in the source code, even though functions similar in all but name pass
unscathed. These disappear when I move the function definition from
the .cpp to the .h.
A virtual deconstructor caused an undefined reference error.. until
the declaration was moved from the bottom of the public: section of the
class to third, right after the constructors. What's more, this fix got rid
of another undefined reference error in the same class. I've also had
similar problems with the inline statement and a typedef.

As you can see, I've managed to get rid of these annoying errors, at the
cost of making my code less readable. But I'm concerned that there's
something bigger going on - all of these errors went away when perfectly
good C++ code was cosmetically changed. So whatever the matter is,
if there is a common cause, it's beyond my ken. (Anything inside the linker
may as well be voodoo to me: 'tlink -o -v blackcockerel.o'.)

I've trawled the Net back and forth looking for any sort of explanation.
It's probably not the compiler; the errors persist when I compile as Cygwin
(an option Dev-C++ gives you.) All the problems other people seem to be
having are with linking to libraries. My problem is linking to functions
the compiler recognizes and has passed on as valid to the linker.

I always get the hard ones.

--Devin Carless

(P.S. Due to some sort of aberration with my usual mail server, I'm sending
this through my Yahoo account. I'm still receiving messages perfectly well,
but get errors when I try to send. So, in the assumption that the problem
will eventually be fixed, please send any mail to me at:
***@calum.csclub.uwaterloo.ca
Thank you. And please don't flame me for having a Yahoo account. I
haven't used it in months, I swear.)



_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

[Oscar Fuentes]

Post by Devin Carless
Hello all,
Of recent, as a way of doing something useful with my time, I've begun to
teach myself C++. (Those of you wincing already need read no further.)
The only book available is eight years out of date and has no index to speak
of.

Be careful with what you use to learn. There are very bad C++ books
out there that can harm you for a long time. You can take a look to
the ACCU book reviews to know some qualified opinion about your book:

http://www.accu.org/bookreviews/public/index.htm

There is a decent book published in electronic format:

http://www.mindview.net/Books

Look for "Thinking in C++".

[snip]

Post by Devin Carless
I have the feeling they're symptoms of a deeper problem, one
that I'm at a loss to diagnose or fix.

You could try to make a small code snippet that should compile and
that shows your problem, post here and expect than somebody explains
why it doesn't work.

[snip]

Post by Devin Carless
A virtual deconstructor caused an undefined reference error.. until
the declaration was moved from the bottom of the public: section of the
class to third, right after the constructors. What's more, this fix got rid
of another undefined reference error in the same class. I've also had
similar problems with the inline statement and a typedef.

You are facing the typical problems every newbie has.

Post by Devin Carless
As you can see, I've managed to get rid of these annoying errors, at the
cost of making my code less readable.

Well, it would be better if you undestand why this changes are
necessary, don't you think? You have a lot of ngs and mailing lists
where you can ask.

[snip]

Post by Devin Carless
(Anything inside the linker > may as well be voodoo to me: 'tlink -o
-v blackcockerel.o'.)

tlink? Hmmmm... shouldn't it be 'ld' or 'gcc'?

Post by Devin Carless
I've trawled the Net back and forth looking for any sort of explanation.
It's probably not the compiler; the errors persist when I compile as Cygwin
(an option Dev-C++ gives you.) All the problems other people seem to be
having are with linking to libraries. My problem is linking to functions
the compiler recognizes and has passed on as valid to the linker.

Well, without seeing a _complete_ and _minimal_ example (less than 50
lines, please) one can't help much.

[snip]

[Devin Carless]

Post by Oscar Fuentes
Be careful with what you use to learn. There are very bad C++ books
out there that can harm you for a long time. You can take a look to

I can already give a qualified opinion of the book I'm currently using, as
my most recent review involved hurling it across the room. But _every_
other introduction-to-C++ book in the library was out. The C++ section is
a quarter the size of the cobol section, even though there are 200+ books
listed in the library index...they're that popular.

Post by Oscar Fuentes
http://www.accu.org/bookreviews/public/index.htm
http://www.mindview.net/Books
Look for "Thinking in C++".

Thank you very much.

Post by Oscar Fuentes
You could try to make a small code snippet that should compile and
that shows your problem, post here and expect than somebody explains
why it doesn't work.

That's one of the problems. The project is now fairly expansive
(15 files) and the error only happens when I add new things. It's like a
Heisenbug: affecting an unrelated part of the program causes it to
appear. A code fragment wouldn't be informative, because that same
fragment worked yesterday, before I included foo.h in my project.
This leads me to your next point...

Post by Oscar Fuentes
Well, it would be better if you undestand why this changes are
necessary, don't you think? You have a lot of ngs and mailing lists
where you can ask.

Absolutely - even if I could get rid of this error, I'd still like to know
what the problem is, so it doesn't recur (and to satisfy my own
curiousity.) So I did some further digging.
It turns out when I compile with the -v flag enabled that stl_vector.h
turns up with suspicious regularity in the error messages (see previous
post.) Aha! Maybe it's not the compiler at all, and I'm bothering the
wrong list.
I found quotes to the effect that STL symbol sizes can get very large
(from an archived FOX-STL post) and that some systems have
limits on symbol sizes. Other posts lead me to suspect a symbol table
overrun - when I rearrange the code, the errors go away until I add
more, because I've managed to fit things in so the symbol table doesn't
get mulched. And the G++ FAQ mentions that G++ doesn't like HP's
free version of STL...my library headers are listed as being HP, 1994,
and Silicon Graphics 1996. Hmmm.
Unless anyone has anything to add, I'm going to install STLport or
libg++-2.6.2. If that doesn't work, I'll go bug the folks on the STL
list instead, since it seems that MinGW isn't really the problem (as I
first thought it might be.)

Post by Oscar Fuentes
[snip]

Post by Devin Carless
(Anything inside the linker > may as well be voodoo to me: 'tlink -o
-v blackcockerel.o'.)

tlink? Hmmmm... shouldn't it be 'ld' or 'gcc'?

Whoops. I grew up with Borland TurboC v. 3.0.

Thank you very much, by the way.

--Devin



_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

[Oscar Fuentes]

"Devin Carless" <***@yahoo.com> writes:

[snip]

Post by Devin Carless

Post by Oscar Fuentes
Well, it would be better if you undestand why this changes are
necessary, don't you think? You have a lot of ngs and mailing lists
where you can ask.

Absolutely - even if I could get rid of this error, I'd still like to know
what the problem is, so it doesn't recur (and to satisfy my own
curiousity.) So I did some further digging.
It turns out when I compile with the -v flag enabled that stl_vector.h
turns up with suspicious regularity in the error messages (see previous
post.) Aha! Maybe it's not the compiler at all, and I'm bothering the
wrong list.

-v flag? Do you mean the -g flag for producing debug symbols?

You will find that STL-related errors (and template errors in general)
are the hardest to diagnose. Sometimes an error on your code produces
a compiler msg referring to a piece of code deeply buried on the
STL. g++ does a better work than BCC here, but still is a PITA to
clean those bugs.

Post by Devin Carless
I found quotes to the effect that STL symbol sizes can get very
large (from an archived FOX-STL post) and that some systems have
limits on symbol sizes.

Almost every modern compiler can deal with much more than 15 files
full of STL intensive code (unless each file has more than 20,000
lines :-)

Post by Devin Carless
Other posts lead me to suspect a symbol table overrun - when I
rearrange the code, the errors go away until I add more, because
I've managed to fit things in so the symbol table doesn't get
mulched.

Either the compiler is really broken or you shouldn't care about this.

Post by Devin Carless
And the G++ FAQ mentions that G++ doesn't like HP's free version of
STL...my library headers are listed as being HP, 1994, and Silicon
Graphics 1996. Hmmm.

Actually, every STL implementation I know derives from the HP one,
including that one. HP forces to preserve theit copyright notice so
you should see it everywhere. Of course, the implementation that comes
with gcc comes from HP too (via SGI). The FAQ is talking about the
original HP implementation, not the modified one that comes with g++.

Post by Devin Carless
Unless anyone has anything to add, I'm going to install STLport or
libg++-2.6.2.

Try STLport first. Be carefull not to mix the STLport files with the
old headers you have. Put them on their directory and modify your
makefile so they appear first on the INCLUDE path and LIBRARY path
options.

Post by Devin Carless
If that doesn't work, I'll go bug the folks on the STL
list instead, since it seems that MinGW isn't really the problem (as I
first thought it might be.)

It _could_ be. There are some chances that the culprit is gcc. Even
more that the culprit is the STL implementation. But my bet is that it
is a bug on your code wich causes confussion to the compiler :-)

Post by Devin Carless

Post by Oscar Fuentes
tlink? Hmmmm... shouldn't it be 'ld' or 'gcc'?

Whoops. I grew up with Borland TurboC v. 3.0.

Well, TurboC v2 here ;-)

Post by Devin Carless
Thank you very much, by the way.

You are welcomed.

[Devin Carless]

Post by Oscar Fuentes
-v flag? Do you mean the -g flag for producing debug symbols?

No, the verbose flag. (Mumit Khan specifically suggests using these.)
But...

Post by Oscar Fuentes
You will find that STL-related errors (and template errors in general)
are the hardest to diagnose. Sometimes an error on your code produces

I changed implementations from vectors to arrays and got identical
errors. (I was ready to blame vectors because I've found them to be
exceedingly finicky; mine don't seem to like push_back() on empty
vectors.) So it's not STL's fault.
My second hypothesis is that it is indeed a linker ordering error.
I have a main module, BaseBook, that depends upon three others:
PictParch, MoveParch and Maneuver. But the Dev-C++ linker
puts them in this order:
Maneuver.o MoveParch.o BaseBook.o PictParch.o (etc.)
But only a few of the errors refer to PictParch at all. Many occur
in two files which contain subclasses of BaseBook, and refer to
BaseBook. All the undefined references refer to files /earlier/ in the
link order (if indeed it goes left-to-right.)
I've tried to muck about with the order anyways, but my IDE seems
to imply it doesn't allow it, and the make files it generates give
'**18: Multiple targets' errors. I don't want to have to build one by
hand, but I'm running out of options.

Post by Oscar Fuentes
Almost every modern compiler can deal with much more than 15 files
full of STL intensive code (unless each file has more than 20,000
lines :-)

I'm nowhere near that large - 15 files, with 150 lines in the biggest (a
lot
of which is whitespace and commenting.)

Post by Oscar Fuentes
Either the compiler is really broken or you shouldn't care about this.

That's good news, in that a symbol table overrun sounded like bad
news.

Post by Oscar Fuentes
with gcc comes from HP too (via SGI). The FAQ is talking about the
original HP implementation, not the modified one that comes with g++.

Curses.

Post by Oscar Fuentes

Post by Devin Carless
Unless anyone has anything to add, I'm going to install STLport or
libg++-2.6.2.

Try STLport first. Be carefull not to mix the STLport files with the
old headers you have. Put them on their directory and modify your
makefile so they appear first on the INCLUDE path and LIBRARY path
options.

I haven't tried it yet - for one, I'm having trouble getting make to work
with -anything- (and I've been reading the Gnu docs, which look pretty
good.) And it appears that I've been too quick to blame STL.

Post by Oscar Fuentes
It _could_ be. There are some chances that the culprit is gcc. Even
more that the culprit is the STL implementation. But my bet is that it
is a bug on your code wich causes confussion to the compiler :-)

Most likely. Unfortunately, I have no idea what it could be - the
messages are no help. (They say there is an undefined reference to
'GetName()' when 'GetDesc()', an identical function referring to the same
object, passes by unnoticed. So it's likely not really in GetName().)

Post by Oscar Fuentes

Post by Devin Carless

Post by Oscar Fuentes
tlink? Hmmmm... shouldn't it be 'ld' or 'gcc'?

Whoops. I grew up with Borland TurboC v. 3.0.

Well, TurboC v2 here ;-)

<laugh> I'd play with TurboC again if I had a machine with a 5 1/4"
floppy drive.

Post by Oscar Fuentes

Post by Devin Carless
Thank you very much, by the way.

You are welcomed.

I came up with one idea which might help, but because it requires
weeding through the code, I'd rather not try unless I have to.
Most of the errors are coming up in functions that refer to my container
objects. BaseBook contains one instantiation each of ManeuverList,
PictParchList and MoveParchList in the private section. In BaseBook's
public interface are several functions that refer to these containers, e.g.,
GetManName(idx) takes an index number as an argument and passes it to
ManeuverList, which has a similar function, GetName(idx), that calls a
the GetName() function of the object in the vector stored at the appropriate
index. So there is a lot of daisy-chaining back and forth within BaseBook;
I do it this way because (a) BaseBook's subclasses might redefine some
of these functions and (b) it incorporates data hiding which, I am told, is
a
Good Thing. (And I can see why.) I could rewrite things to move the
three vector containers to the public: section and have them directly
accessed, instead of going through a proxy method on BaseBook.
That is, instead of ExampleBook.GetManName(11) I'd have something like
ExampleBook.ManeuverList.GetName(11) instead. Would this do anything?
(I've had no luck with multiple dot operators, unfortunately.)

--Devin



_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

[Oscar Fuentes]

"Devin Carless" <***@yahoo.com> writes:

[snip]

Without seeing the code one could speculate forever. If your IDE
supports configurations for other compilers you could try to build the
project with Borland and see what happens (keep using mingw
afterwards! ;-)

[Devin Carless]

Post by Oscar Fuentes
Without seeing the code one could speculate forever. If your IDE
supports configurations for other compilers you could try to build the
project with Borland and see what happens (keep using mingw
afterwards! ;-)

Well - I'd cheerfully give you an example, but I managed to find and
fix the problems. (Whoopee!) In fact, I managed to do in an hour
what had been stalling me for three days.
There were actually three errors. The first was that I'd declared a
destructor as

~BaseBook();

...without remembering that Destructors Are Functions Too, and Deserve
To Have A Real Definition, with parentheses and everything.
The second was more embarassing. "Gee," I thought (yes, I do think 'gee'
on occasion) "Let's look at the functions the errors are referring to
instead of
BaseBook." I'd been assuming the real error was in BaseBook because it
was mentioned in all the error messages.
In fact, I hadn't written a function that I thought I had. I'd been
perplexed
as to why the linker was complaining about it and not an identical function;
the reason was, one was there and the other wasn't. Whoops again.
The third was more subtle. I've learned the hard way: don't use 'inline'
when
you don't have to. That was the cause of the last couple of errors. I
don't
understand it, but (with flawless post hoc logic) since the problem went
away
when I took away the 'inline', that must have been the cause.
So it compiles. Whee! Now I get to hunt the *runtime* bugs. :)

--Devin


_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

[Oscar Fuentes]

"Devin Carless" <***@yahoo.com> writes:

[snip]

Post by Devin Carless
The third was more subtle. I've learned the hard way: don't use
'inline' when you don't have to. That was the cause of the last
couple of errors. I don't understand it, but (with flawless post
hoc logic) since the problem went away when I took away the
'inline', that must have been the cause. So it compiles. Whee!

Do you put 'inline' in front of funtions defined in non-header files?
This is the only cause I can imagine to produce the error.

[Devin Carless]

Post by Oscar Fuentes
Do you put 'inline' in front of funtions defined in non-header files?
This is the only cause I can imagine to produce the error.

The answer to that question begins with 'Y' and rhymes with 'mess'.
None of the sources I've read ever told me not to do that, the
compiler didn't mind, and I got away with it for a while. Owch!
That's one I'm not going to forget, ever.

Thanks for your help, again. I'm doing my best to return the favour
on Dev-C++-users by helping someone who sounds even more
newbie than me. :)

--Devin Carless


_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com