The name display_error is very common and may be overlapped by programs linking to this library, and thus introduce unexpected behaviour. E.g. caesium-clt has also a display_error, then when libcaesium calls display_error, the one from caesium-clt was called.
There are also other solutions,
Using compiler/linker-specific options
For example, with the GCC extension, __attribute__ ((visibility ("hidden"))) hides the function. Alternatively it is possible to pass a list of functions to be exported. See also: https://developer.ibm.com/articles/au-aix-symbol-visibility/
However, this fashion is compiler/linker-specific, so that will lead to nightmare maintenance troubles. One thousand configuration for one thousand compilers.
Code amalgamation. This technique is used by sqlite, where 100+ source files were merged into a single 7.5MB 220,000+ LOC sqlite3.c by script, then symbols not desired to be exported can just be marked static. See also: https://www.sqlite.org/amalgamation.html
I believe this may be the best option, however I am too lazy for it. :)
The name
display_error
is very common and may be overlapped by programs linking to this library, and thus introduce unexpected behaviour. E.g. caesium-clt has also adisplay_error
, then when libcaesium callsdisplay_error
, the one from caesium-clt was called.There are also other solutions,
__attribute__ ((visibility ("hidden")))
hides the function. Alternatively it is possible to pass a list of functions to be exported. See also: https://developer.ibm.com/articles/au-aix-symbol-visibility/However, this fashion is compiler/linker-specific, so that will lead to nightmare maintenance troubles. One thousand configuration for one thousand compilers.
sqlite3.c
by script, then symbols not desired to be exported can just be markedstatic
. See also: https://www.sqlite.org/amalgamation.htmlI believe this may be the best option, however I am too lazy for it. :)