Re: Multiple definition of gnulib symbols

[Ralf Wildenhues]

* Simon Josefsson wrote on Thu, Apr 26, 2007 at 10:44:41AM CEST:
> On 26 apr 2007, at 01.04, Bruno Haible wrote:
>> Simon Josefsson wrote:
>
> But yes, gc-libgcrypt and gc-gnulib are intended to be two mutually 
> exclusive modules, since they provide the same symbols, but I wouldn't have 
> thought that could lead to problem between two projects that each use 
> gc-libgcrypt and gc-gnulib.  I would have thought that these symbols would 
> not be externally visible, but I guess there is no such concept with static 
> libraries.

No, there isn't.

>>> Or is there some libtool/ld/etc setting that gnulib or my
>>> projects should use, to avoid causing this situation?
>>
>> Such errors when linking statically typically occur when you have object
>> files defining more than one symbol. The rest of gnulib doesn't see this
>> kind of error because most .o files define one and only one function.
>
> Oh!  I had no idea that defining multiple symbols in a single object file 
> could lead to trouble.  Sigh.

It's roughly like this: the linker goes through the archive.  For each
object file, it decides whether it needs symbols from it.  If yes, that
object is added to the output file, i.e., all symbols defined in that
object file.  As the added object file may also add new symbols to the
list of undefined symbols, the linker may have to reiterate through the
previous objects in that same archive.  (In practice, archives have an
index, which helps keep the complexity of this down.)  Note that link
editors never reiterate through other archives listed earlier on the
link command line, unless you list them again later.

If each object defines only one symbol, then you avoid the situation
where
  a.o   defines A and C
  b.o   defines B and C

and symbol A and B are needed at some point.

HOWEVER.  With static linking you effectively have to consider all
symbols as global.  If you go the route of fixing things by splitting
files to only define one symbol, and not renaming them, then you still
make the assumption that the gc_init symbol defined in libgnutls.a and
the gc_init defined in libgsasl.a are compatible (ABI + API).  Two
libraries which may have been compiled at quite different times, from
different snapshots of gnulib, yet one uses the gc_init defined by the
other.

In other words: when going that route only, effectively this creates the
need for a stable gnulib interface.[1]

>> How can you turn a module that defines 10 functions into a module that
>> defines just 1 symbol? Combine the 10 functions into a vtable (= struct
>> containing function pointers). See the 'list' module for an example:
>>   - The header file defines inline functions or macros that access 
>> individual
>>     elements of this function pointer table,
>>   - Any .o file only defines a named function pointer table.
>> (This is not to say that here you won't have versioning problems: If at
>> some moment you add an 11th function pointer, two compiled versions of
>> this module will be binary incompatible.)

Yes, and any such binary incompatibility may hurt programs using two
different libraries that themselves use gnulib modules.

>>> One solution might be for gnulib-tool to change the namespace of all
>>> gnulib functions to 'gnutls_*' and 'gsasl_*' respectively, when
>>> importing them into each project.
>>
>> Yes. Ralf was the first one to realize the need for such a renaming. It 
>> can be done in a Makefile.am rule without special help from
>> gnulib-tool. See gettext/gettext-tools/libgettextpo/Makefile.am.
>
> Aha!  Ok, I think that approach may be simpler, if it already can be 
> automated easily.  I'll wait with implementing it until I can confirm and 
> understand why it would be needed though, it seems I can learn something 
> here.

Until gnulib is ready for a stable interface scheme, I suppose this
(slight?) bloating of libraries may be the easier way.

Cheers,
Ralf

[1] At which point one may as well consider making gnulib a proper
installed, versioned library with a well-defined API and ABI.
FWIW, I don't think it's time for this yet.