arduino library build system feedback

hi!

first of all, i am really happy with the arduino, nice little thing... ;D

but it gave me a hard time when i wanted to integrate some c-code - so for your reference or (even better) so that you can change this behaviour, i'll give you more details.

i used the test.zip i found on the website to get started. i was sure the code runs (tested it outside the arduino environment), but i kept receiving linker errors in arduino. the problem was the following: since i wrote c code, the filename suffix was ".c". but the arduino toolchain doesn't seem to retain the #include-directive when c files are given in the library, so my pde was translated to an unusable cpp file. when i changed my filenames to ".cpp" suffixes, everything went fine.

so, is there an explanation for this behaviour (i'm new to arduino, so maybe i don't see the point) or is this a not-intended behaviour?

thanks, -mathias

This is good feedback to get, but I need a few more details to understand exactly what was happening. Can you post the linker errors you were getting? Which file had a .c suffix (one in a library or in the sketch)? The problem may have to do with the difference in linker behavior between C and C++. A .c file with function named foo() will be compiled into an object file (.o) with a function named foo(). The same function in a C++ file will get "mangled" when it's compiled, the function in the .o file will be called something weird like __Blah_foo. Thus, when a C++ file is linked against an object file generated from a C file, the C++ compiler needs to be told of this fact, so it won't look for mangled function names. An easy way to do this is putting:

#ifdef __cplusplus
extern "C"{
#endif

in the header file corresponding to your .c file before the function declarations. After the function declarations, say:

#ifdef __cplusplus
} // extern "C"
#endif

Sorry, I enabled the notification of the forum and I expected to receive an email on any replies, so this took me a while…

This is good feedback to get, but I need a few more details to understand exactly what was happening. Can you post the linker errors you were getting? Which file had a .c suffix (one in a library or in the sketch)?

Unfortunately, I do not have the old files because I continued with C++ code. As far as I remember, the compiler complained about undefined references. The .c file was in the library, the reference was reported to be missing within the sketch in the “loop” function.

I think you can reproduce this by renaming the Test.cpp from the example library to Test.c - apart from the other errors, you get

o: In function `loop':
undefined reference to `Test::doSomething()'

which is the same I received.

The problem may have to do with the difference in linker behavior between C and C++. A .c file with function named foo() will be compiled into an object file (.o) with a function named foo(). The same function in a C++ file will get “mangled” when it’s compiled, the function in the .o file will be called something weird like __Blah_foo. Thus, when a C++ file is linked against an object file generated from a C file, the C++ compiler needs to be told of this fact, so it won’t look for mangled function names. An easy way to do this is putting:

#ifdef __cplusplus

extern “C”{
#endif




in the header file corresponding to your .c file before the function declarations. After the function declarations, say:



#ifdef __cplusplus
} // extern “C”
#endif

This is interesting, I didn’t know. Thank you!