Re: Migration from GCC3.4.3 to GCC4.1.2

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi ruks,

> I am doing migration from GCC 3.4.3 to GCC 4.1.2.While doing that compilation
> is success after some errors.

I'm not quite sure what you mean by "success after some errors".

I *presume* that you mean there were some errors compiling your source code
with GCC 4.1.2, and that you have since resolved those errors, and now your
source code compiles cleanly with GCC 4.1.2.

If that is not what you meant, please clarify.

> But while linking, it throws tons to "undefined reference to" errors.

Hard to say given the information you have provided.  Could be many things.

My best guess (which may be entirely mistaken) is that you have some C++
link libraries (.a or .so) which are still compiled with GCC 3.4.3.

Note that C code should link, regardless if compiled with GCC 3.4.3 or GCC
4.1.2.

But all the C++ source code should use the same compiler, even the C++
source code in the static and dynamic libraries.  (There are exceptions to
this guideline, but take it as a general rule-of-thumb if you want to
eliminate bothersome worry tracking down exactly which versions of GCC's C++
can be linked together.)

I'm just guessing here, though.  You did not specify whether your source
code is in C, C++, Fortran, Pascal, Ada, D, Java, Objective-C, or some other
front-end language supported* by GCC.

* I'm using "supported" to include both FSF provided front-end languages to
GCC, as well as third-party front-end languages which use GCC as their
back-end.

> I am using libtool as well but the version is 1.5.10. Whether I need to
> upgrade libtool too?

Should not hurt to upgrade.  May or may not be necessary, though.

> How to solve this problem ("undefined reference to")?

For a start, it is helpful to know what the linker is indicating is
undefined.

Then it is helpful to track down what part of the code has the unresolved
reference.

Then it is helpful to track down the part of the code which is supposed to
be providing that symbol.

Lastly, figure out why the that symbol is not available during link time.
Could be that there is a missing foo.o on the link line which contains the
desired Foo symbol.  Or that a foo.a library is in the wrong parameter order
on the GCC link line -- order of parameters is significant.

HTH,
--Eljay



[Index of Archives]     [Linux C Programming]     [Linux Kernel]     [eCos]     [Fedora Development]     [Fedora Announce]     [Autoconf]     [The DWARVES Debugging Tools]     [Yosemite Campsites]     [Yosemite News]     [Linux GCC]

  Powered by Linux