Fix compiler error "undefined reference to dtls_package_version"
Status: Alpha
Brought to you by:
obgm
Menu
▾
▴
1 Attachments
#18 Fix compiler error "undefined reference to dtls_package_version"
If tindydtls is configured with --witout-debug flag it gives "undefined reference to dtls_package_version" compiler error. To fix this error moved definition of
functions dtls_package_version & dtls_package_name to debug.h from debug.c
Samples like 'tests/dtls-server.c' uses method 'dtls_package_version()'. Currently, the definition of this method exists in debug.c. BUT, debug.c is not included in libtinydtls.a when tinydtls is configured with '--without-debug'. The Fix added by Shilpa is to move the definition in debug.h so that it is available in Release/Debug builds.
As debug.h defines a public API, making the internal symbols PACKAGE_* visible is a bad idea. There are two options from here:
Make dtls_package_{name,version}() just return NULL if NDEBUG is defined (this was pretty much the original intention of not defining the function for this case at all.
Include debug.c (or required parts thereof) with the library.
I opt for option #1 and have a patch for it in a local feature branch that could be merged into branch develop easily. Option #2 would be more robust and the cleaner way.
What do you think?
I think #2 option is better way of addressing the problem as the behaviour of the sample like 'tests/dtls-server.c' will stay same in debug or release build.
Olaf, can you please elaborate more on why exposing internal symbols like PACKAGE_ is a bad idea in release build and ok idea in debug build. The apis, dtls_package_name & dtls_package_version, are only reading these internal symbols so exposing them in either builds should be fine in my opinion. If these apis were to change the internal symbols like PACKAGE_ then certainly exposing them in either relase or debug build will not be a good idea.
Also the apis like dtls_package_name & dtls_package_version should behave similarly in both release and debug build. IMO returning null in release build and returning the proper values in debug build leads to special case handling for developers.
I also think, currently as we don't need other functionality of debug.c file in release build, just including dtls_package_name & dtls_package_version in debug.h file can be a good option.
What are your thoughts?
Sure: Autotools generate PACKAGE_* for your applications and the pre-processor will complain about multiple definitions if you include debug.h. To avoid this, these macros are used only inside the .c file.
It is reasonable thinking that dtls_package_name() and dtls_package_version() should behave the same for the debug build and the release build. However, this was never the case as you can see. The reason is that the debug module was intended for debugging purposes only and not to be used in a release version because of its memory-consuming functions (e.g. printf).
At some point, this intention got lost during development (of the ECC support, I think), and now the logging functions are used all over the library. That is why I offered option #2 as the clean solution.
Commit 6a6264c in branch develop fixes this issue by including debug.c in the final library (aka option #2).