That got it to compile which is nice ...now to try and see if it works.
Thanks again,
Logan
On 7/28/05, Logan Shaw <[EMAIL PROTECTED]> wrote:
> 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/
>
--
For information on using the PalmSource Developer Forums, or to unsubscribe,
please see http://www.palmos.com/dev/support/forums/
