Landon Cunningham wrote:
When I do the -c bit I get this error:
Now am I suppose to compile the BitmapRsrc files into a BitmapRsrc.o
and then into my main program like the above compilation text. Because
this is where I get the errors regarding the above inline functions
which are defined in the BitmapRsrc.h file. The functions aren't even
in Neoslate.c so I don't get why it meantions that code.
One possibility is that gcc is somehow deciding not to inline the
functions. I believe the "inline" keyword just advises the compiler
to consider inlining and it isn't required to.
If that were the case, gcc would be treating them as regular
function definitions and including the function definitions in
each file in which you do '#include "BitmapRsrc.h"', which would
cause the same function bodies to be compiled into two different
object files, which would cause a link error.
A simple thing you could try would be to replace every occurrence
of "inline" in BitmapRsrc.h with "static inline". The "static"
keyword ensures that a function's name is not visible outside
the object file being compiled, so that it's OK for two different
object files to have functions with the same name, since the
definition and usage of the function are isolated from each other.
If gcc is choosing not to make them inline, it should at least
honor the static keyword and that should prevent link errors.
(That is, unless there's some technicality with C where the
combination of "static" and "inline" does something unexpected.
My gut feeling is that "inline" should imply "static", but
that doesn't mean it really does.)
A totally different idea is to put "-O2" on the two lines so
that the optimizer is turned on. It will probably choose to
put those functions as inline functions at which point the
problem would go away.
Now also in
the BitmapRsrc.h file there is the following:
#ifdef __cplusplus
extern "C"
{
#endif
Functions work differently in C than in C++. In C, the argument
list (types) aren't used to disambiguate function calls, i.e.
there is no function-name overloading. In C++, there is. This
presents "interesting" issues when you want to link, especially
if you want to be able to link C with C++ and use the same linker
your system had before somebody went and invented C++ and tried
to make your life more complex.
As a result, there is the concept of "name mangling", which
basically means C++ compilers create a new function name that
encapsulates the function plus the types of the arguments. This
trick allows the linker to worry only about function names and
not arguments and still implement function-name overloading.
But sometimes you don't want this encapsulation, because you
aren't using function-name overloading, and you want your C++
files that include the C header file to skip the name mangling
process and just leave function names as-is.
In that case, you wrap everything with 'extern "C" { }', which
causes the compiler to generate C-compatible function names.
And since "__cplusplus" is only defined when compiling C++
and not when compiling C, "#ifdef __cplusplus" trick allows
you to include your BitmapRsrc.h in either C or C++ source code
and not have name mangling happen either way, which allows
either C or C++ source code to #include that .h file and
for the prototypes to generate the right non-mangled function
names that will be properly resolved at link time.
- Logan
--
For information on using the PalmSource Developer Forums, or to unsubscribe,
please see http://www.palmos.com/dev/support/forums/
