Re: Multiple definition of gnulib symbols

[Simon Josefsson]

Ralf Wildenhues <address@hidden> writes:

>>>> 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.

Ah, I understand, thanks for the explanation.  I wonder why the linker
doesn't pull out only the needed symbol(s) from each object file
instead?  That would avoid bringing in unrelated symbols that are known
to not be needed (or?) and can cause collisions.

> 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.

gc-gnulib.c and gc-libgcrypt.c both use gc.h for the prototypes, and the
intention is that these API/ABIs will be the same in both files.

I cannot guarantee that the API/ABI will be the same in gnulib forever,
though.  If I ever make an API change here, and let's say someone
install GNU SASL with the old gnulib files and GnuTLS with the new
files, will there be problems?  Given my understanding now, I would
think that yes, there will be problems.  Only one of the incompatible
gc-libgcrypt.o/gc-gnulib.o will be included, and either one will break
something.

Hm.  I don't see what this problem would only be related to gc-* though.
I would imagine that if there is a API/ABI difference of _any_ function
included in gnulib inside GNU SASL compared to gnulib inside GNU TLS,
there will be problems?  Looking at the gnulib NEWS, a problematic
change here would be the one adding a new parameter to
gl_list_create_empty().  Let's say GNU SASL link to the old
gl_list_create_empty() and GnuTLS link to the the new
gl_list_create_empty().  That will break.  Or am I missing or forgetting
something?

>> 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.

I believe I agree.  It is important that each project (GNU SASL and
GnuTLS) get the gnulib symbols from their own package and not from
somewhere else.

Hm.  It may not be sufficient for the gnulib namespace to change to
gsasl_* and gnutls_* respectively, since it is known to happen that some
applications end up linking to two different versions of GnuTLS at the
same time.  One fix would be to change the namespace to gsasl0_2_16_*
and gnutls_1_7_8_* etc instead.  Then if someone links to an older
GnuTLS, the gnulib symbols will be called gnutls_1_9_42_* or whatever.
However, I recall that linking to two versions of the same library has
been known to create all kinds of other bad problems, so that we may
simply declare that such a configuration is not supported at all.

/Simon