[lxc-devel] Duplicate definitions of `lxc_log_define`

[Daniel Lezcano]

Ciprian Dorin, Craciun wrote:
>     Hy all!
> 
>     Yesterday I've played around with LXC containers, and I've wanted
> to statically build the lxc tools.
> 
>     While doing this (after messing with the `Makefile.am` from
> `src/lxc` to replace the `.so` with a `.a`), I've hit the following
> problem: in most `.c` files belonging to the applications (like
> `lxc_start.c`), there is a definition (that I'm assuming creates an
> exportable function) like: `lxc_log_define(lxc_start, lxc);`, but the
> same definition is also found in the library `.c` files (like
> `start.c`), which reads exactly the same.
> 
>     Now I assume that when dynamically linking the executables no
> conflict is found, but when statically linking them I get multiple
> definitions errors.
> 
>     I've fixed this by adding a `_` at the end of the name in the
> `lxc_*.c` files, like: `lxc_log_define(lxc_start_, lxc);`
> 
>     So if anyone has time to look this up would be nice.

It would be simple to define lxc_log_define(start, lxc) for start.c and 
lxc_log_define(lxc_start, lxc) for lxc_start.c and so on for the rest of 
the lxc_log_define eg. lxc_log_define(lxc_namespace, lxc) => 
lxc_log_define(namespace, lxc).

>     P.S.: Could you also consider adding the option to statically
> build the tools? (My need for them is for an minimal Linux
> distribution that would only bootstrap the containers, and I would
> prefer to have the binaries self-contained and not to bother about
> missing `.so`.)

Yep, looks feasible.

Thanks
   -- Daniel