Help with linking error
VargChu
but I unfortunately have some legacy code which I would like to compile
and run on my OS X machine. The code complies correctly and all the
correct headers have been incldued. I have managed to get rid of all
but one of my linking errors, which was no small feat, but I can't seem
to figure this last one out.
The error is as follows:
/usr/bin/ld: Undefined symbols:
PointLight::glDraw(unsigned int) const
DirectionalLight::glDraw(unsigned int) const
collect2: ld returned 1 exit status
Where PointLight and DirectionalLight are both classes created in a
single header file.
class Light : public Element
{
public:
//some virtual methods
virtual void glDraw(GLenum lightID) const { }
virtual void glDraw() const { }
protected:
//some methods and variables
};
class DirectionalLight : public Light
{
public:
//constructor and methods
void glDraw(GLenum lightID) const;
void glDraw() const;
protected:
//some methods and variables
};
class PointLight : public Light
{
public:
//constructor and methods
void glDraw(GLenum lightID) const;
void glDraw() const;
protected:
//some methods and variables
};
So, glDraw for both of the subclasses should use the glDraw of the
Light class, which doesn't do anything, but is defined. Any
suggestions on how can I eliminate my linking problem?
Thank you.
Michael Ash
You declare glDraw() but never implement it in the two subclasses. If you
intend to use the inherited version, then I think you should avoid
declaring it as well. You don't need to declare inherited methods in the
subclass.
--
Michael Ash
Rogue Amoeba Software
VargChu
Thank you for the response. I'm hoping I finally figured this problem
out. The group from which I inherited this code has a very different
definition for "object-oriented" and "portable" than do I. It seems
that they definted all these different classes in one .h file and then
proceeded to spread the implementation across many different .cpp
files. Instead of creating a .h and .cpp file for each object, they
kind of mixed several classes in several .cpp / .h files. This seems
to be creating chaos for the Apple complier. I don't know why, but g++
seems to accept it under Linux. I guess the Apple compiler is simply a
bit more strict about these things. I've already had to go back through
the code to clean it up so I could get this far. Maybe I'll just give
up and go back to building it on Linux :(.
Cheers,
Andrew
Patrick Machielse
> I've already had to go back through the code to clean it up so I could get
> this far. Maybe I'll just give up and go back to building it on Linux :(.
[I'm not a C++ expert by any means, but I'll give it a try anyway...]
What versions of GCC are you comparing (Linux vs. Apple)? Are these
classes in a library or in the main application? (maybe you're doing
something like dead code stripping at the wrong moment in time...).
Also, since the Light class has an empty implementation the intention
_may_ have been to have a pure virtual class, so what happens if you say
class Light : public Element
{
public:
// pure virtual methods
virtual void glDraw(GLenum lightID) const = 0;
virtual void glDraw() const = 0;
protected:
// some methods and variables
};
When looking at the output of ld it says
PointLight::glDraw(unsigned int) const
Maybe you're calling it with an unsigned int parameter in the code when
you should be using GLenum, and maybe those things are the same on Linux
but not on Mac OS X?
Do the implemenation and the declaration of the methods match?
Just some stabs in the dark...
patrick
Sherm Pendley
> to be creating chaos for the Apple complier. I don't know why, but g++
> seems to accept it under Linux. I guess the Apple compiler is simply a
> bit more strict about these things.
Um... The Apple compiler *is* g++. :-)
Are you using GCC 3.x under Linux, by any chance? GCC 4.x, in my experience
at least, is quite a bit stricter about the code it accepts. But that's true
regardless of the OS.
sherm--
--
Web Hosting by West Virginians, for West Virginians: http://wv-www.net
Cocoa programming in Perl: http://camelbones.sourceforge.net
Sherm Pendley
> Maybe you're calling it with an unsigned int parameter in the code when
> you should be using GLenum, and maybe those things are the same on Linux
> but not on Mac OS X?
From gl.h on Mac OS X:
typedef unsigned long GLenum;
From gl.h on Linux:
typedef unsigned int GLenum;
The C and C++ standards define 'int' as being at least 16 bits wide, and
'long' as at least 32 bits wide. So no, GLenum is not defined the same way
on both platforms.
Patrick Machielse
> nor...@mail.invalid (Patrick Machielse) writes:
>
> > Maybe you're calling it with an unsigned int parameter in the code when
> > you should be using GLenum, and maybe those things are the same on Linux
> > but not on Mac OS X?
>
> From gl.h on Mac OS X:
>
> typedef unsigned long GLenum;
>
> From gl.h on Linux:
>
> typedef unsigned int GLenum;
>
> The C and C++ standards define 'int' as being at least 16 bits wide, and
> 'long' as at least 32 bits wide. So no, GLenum is not defined the same way
> on both platforms.
Aha! This looks like something the compiler should/could catch. If the
OP would enable _all_ compiler warnings, gcc might point out the
offending code...
patrick