Linker symbol overriding

[ghost]

The shared library exposes commonly used symbols that can be accidentally overridden by the linker. Here's an example:

#include <lwan/lwan.h>

struct config {
	int dummy;
};

struct config *config_open(const char *path)
{
	// TODO: To be implemented.
	return NULL;
}

int main(void)
{
	struct lwan lwan;
	lwan_init(&lwan);
}

After successfully compiling this code, the output of the executable will always be:

27630 lwan-job.c:96 lwan_job_thread_init() Initializing low priority job thread.
27630 lwan-tables.c:40 lwan_tables_init() Uncompressing MIME type table.
27630 lwan.c:370 setup_from_config() Loading configuration file: main.conf.
27630 lwan.c:532 lwan_init_with_config() Could not read config file: (null).

Lwan will always fail to read the configuration file because the linker has replaced its implementation of config_open with this one.

Other seemingly harmless names include str_find, parse_int, list_check and hash_add. Names like that are common in application code. Users have to either mark their functions static or use prefixes to avoid naming conflicts.

Are there any plans to add the lwan_ prefix or to not expose these symbols from the library?

[lpereira]

This kind of plumbing work is something I've been postponing for a while. (There are plenty of other things to clean up in the source code that have a similar nature; the header files for instance are a mess.)

For things that are lwan-specific, like the configuration file parser, yes, adding a prefix would help. For things that are implementation details, such as the linked list, string pattern matcher, and hash table functions -- I guess the best solution would be to just use a linker version script in the ELF targets.

[lpereira]

e2b3ce2 added a version script. Only some symbols are being exposed right now. Next on the list is to determine what other symbols without the lwan_ prefix should be exposed, rename them so that they have the proper prefix, and update the version script.