undefined reference 3

[caboodles87]

to whom it may concern,

hi. my program compiles and runs. however, when i transferred it to linux/unix environment and compiled it using g++, i came across some errors. can someone help me out a bit, please. THANKS!!!


Sincerely,
Jennifer


heart:~> ssh linux
[jdejesua@ecs416lin214 ~]$ cd proj5
[jdejesua@ecs416lin214 ~/proj5]$ g++ proj5.cpp
/tmp/cclwXhTF.o: In function `main':
/tmp/cclwXhTF.o(.text+0x1c): undefined reference to `convert::convert(void)'
/tmp/cclwXhTF.o: In function `getInfixEx(convert &)':
/tmp/cclwXhTF.o(.text+0x37e): undefined reference to `convert::getInfix(char *)'
/tmp/cclwXhTF.o(.text+0x404): undefined reference to `convert::getInfix(char *)'
/tmp/cclwXhTF.o(.text+0x445): undefined reference to `convert::showInfix(char *)
'
/tmp/cclwXhTF.o(.text+0x486): undefined reference to `convert::convertToPostfix(
char *, char *)'
/tmp/cclwXhTF.o(.text+0x4b0): undefined reference to `convert::showPostfix(char
*)'
collect2: ld returned 1 exit status
[jdejesua@ecs416lin214 ~/proj5]$

my code is posted in here

http://www.noidea128.org/cgi-bin/framesource.cgi?id=6124&type=html

 

[Salem]

You need to compile ALL your source code
[tt]g++ proj5.cpp myclass.cpp[/tt]

--

 

[caboodles87]

I will try that but I don't see any point in doing that cuz everything is connected to each other. But I will try your suggestion.

 

[caboodles87]

I tried it and it gave me even more error messages. Have you looked at my code? Maybe there is something there that's missing in a UNIX environment.

 

[jstreich]

You need to compile them together to get them to link, anything that you compiled to objects before didn't type check (yet) against the other modules. Compiling them together is necessary. Any errors from doing this are most likely real errors that occur durring linking. I'd guess this is a symbolic referncing error... header files not matching your cpp files (Note the copile line shouldn't include .h files -- these are looked at when linking automatically by the includes).

Post the errors and the code if you cantinue to have trouble.

 

[caboodles87]

i did all that...its all good i got it...it was the NULL in the for loops that made those crappy errors...i had to remove those NULL's and replace them with all 0. thank you for taking the time. i really appreciate ur kindness.

 

[chipperMDW]

None of your errors say anything about not understanding NULL, so I doubt that could have been the problem. That said, you probably don't want to assign NULL (a pointer value) to an element of a character array. Instead, you want to be assigning '\0', the NUL ASCII character. You say you're now assigning an integer value, 0, to them; that's probably acceptable, as well.


Previous posts have already told you the real reason you were getting the original errors you posted: you weren't building your project correctly. If you got it working by changing NULLs, you must just have inadvertently built it correctly.

You said that you don't see any point in compiling all the source files because they're all connected. I assume from that statement that you're probably used to using Visual C++ or some other IDE that manages your project for you automatically.

In *nix, you normally don't use an IDE that manages an entire project automatically, and you most certainly do need to compile every one of your source files (though you normally don't do it manually). The way the build process should look is (as described above in word form by jstreich) something like this:

[tt]proj5.cpp --COMPILE--> proj5.o
|
|
LINK--> a.out*
|
|
myclass.cpp --COMPILE--> myclass.o

* a.out is the default name for the executable
[/tt]

That is, you compile each source (.cpp) file into an object (.o) file. You then LINK the object files together to form an executable.

When you COMPILE, it's okay to have stuff "missing." That is, you can call a function in one source file even though it's defined in another.

When you LINK everything together, it's not okay to have stuff missing. That is, if one of your object files is using a function it doesn't define, it has to be defined in one of the other object files that's being LINKED or you're going to get errors.


You got your original set of errors because this is what happened when you typed [tt]g++ proj5.cpp[/tt]:

[tt]proj5.cpp --COMPILE--> proj5.o --LINK--> a.out[/tt]

That is, the COMPILE worked fine. You then tried to turn proj5.o into an executable by LINKING it (which is a bit of a confusing term when there's only one object file), but it still has undefined references. Specifically, it's trying to call the constructor, getInfix, showInfinx, convertToPostfix, and ShowPostfix member functions of the convert class.

(Error messages are designed to try to tell you exactly what's wrong. They're not just "complaining"; they're trying to help you fix the problem. It pays to read them).

Those functions are simply not there in proj5.o. Those definitions live over in myclass.o, which you got from compiling myclass.cpp. In order to get something complete, you'll need those, too.


Salem's command, by the way, is essentially a way to combine the compile and link steps. You'll never see the object files if you go that route, but they still temporarily exist.

 

[jstreich]

Since we're going into compiler design... I suppose mentoning that there is also an assemble stage may be useful... ;p

 *.h       *.cpp
   |          |
   |      [Compile]
   |          |
   |         *.o
   |          |  
   +--------[link]
              |
        Intermediate asmbly code,
        with g++ and most compiler
        you can get this into a file 
        if you want, by adding flags
        to the command line (g++ -S)
              |
              |
          [assemble]
              |
             a.out (or any name specified with -o option)

Generally you'll want to make a Makefile for things that are more than a file long. The Make system is a powerful tool...

 

[caboodles87]

thanks a lot you guys...i actually did a make file later on...chip, i know changing the nulls to zeros has nothing to do with the errors that was posted...i think my project wasn't compiled completely...it is weird that i have to include convert.cpp when i compile proj5.cpp, but it sure did work when i tried it...

g++ proj5.cpp convert.cpp

then i made a few more revisions...

void convert::convertToPostfix (char Infix [], char Postfix [])

{
stack <char> stack;
char symbol1, symbol2;
int counter = 0;
unsigned int i;

for (i = 0; i < strlen (Infix); i ++)
----> // changed i=NULL to i=0
{
symbol1 = Infix ;

if(symbol1 == ' ' || symbol1 == ';') continue;

if (IsOperand(symbol1))
Postfix [counter++] = symbol1;
else
{
while ((! stack.empty()) &&
(precedence(stack.top(), symbol1)))
{
symbol2 = stack.top();
stack.pop();
Postfix [counter++] = symbol2;
}
if ((! stack.empty()) && (symbol1 == ')'))
stack.pop();
else
stack.push(symbol1);
}
}

while (! stack.empty())
{
symbol2 = stack.top();
stack.pop();
Postfix [counter++] = symbol2;
}
----> Postfix[counter] = '\0'; // added the NULL ascii
// character
};

then, my last revision was adding the #include <ctype.h> because i used isspace in shotInfix function. then i made a few spaces after the whole code cuz the compiler asks for new line after the end. after those revisions were made, the program compiled and it works like a charm! so yeah umm, i ended up not continuing with the make file later on and just stuck with the changes i had to make. consequently, i have to give the points to chip since his post gives solution to a couple of my errors. although, thanks also to js for making a point and tryin to explain how the compiling works. mad props to all of you and thanks a lot.

 

[Salem]

Your diagram is wrong jstreich
.h files are read by the compiler

compiler takes .cpp and .h files, and produces a .s file (this is the input to the assembler)
assember takes .s files and produces .o files (this is the input to the linker)
linker takes .o files and library files and produces an executable.

[tt]gcc -v prog.c[/tt]
Shows the compilation stages in verbose detail.

--

 

[chipperMDW]

jstreich,

There's also a Preprocessing stage that occurs before Compilation proper. I think that's the stage where the arrow from the (.h) should be pointing in your diagram, since the preprocessor handles all the #include directives. Headers will have been used long before you hit the linking step. In fact, you could delete the headers and successfully Link together some object files generated from source that included those headers.

One valid way of thinking about headers is just as a hack that you can use to make things compile without writing a lot. Oh, sure, specifying the interface to a module is important, too, but let's not forget the real reason. ;-)


You bring up a good point with Assembling: Compile and Link are just two steps in the total process of getting from source code to a working executable. However, they are also the ones most likely to be visible to a programmer. While they should realize that there's a lot more magic happening behind the scenes, they don't necessarily need to understand it all... at least at first.

 

[jstreich]

It often doesn't give me symbol referencing errors within a class untill I link, I suppose it could assume that because the const (or what ever doesn't match) was left out I mean write the definition to use a function with the same name declared in another class -- so I assumed that headers were used for linking... Now that I think about it, I've always known that it looked at headers before that-- just must not have been thinking.

Oh, Chipper, what is this interface thingy you talk about... ;p ... You someone might want to know how to use the modules they are linking to?

To be honest, one of the things that I love about java is not to have to protype things and the documentation tool... I am supprised there isn't a tool that does what javaDoc does except instead of HTML it generates the headers... Not quite sure how it would figgure out what is supposed to be public/private/protected.