Re: Multiple definition of gnulib symbols

[Ralf Wildenhues]

* Simon Josefsson wrote on Thu, Apr 26, 2007 at 01:30:02PM CEST:
> Ralf Wildenhues <address@hidden> writes:
> >
> > 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?

Because a linker cannot split an object file into pieces.  There is just
no way to do that.

> That would avoid bringing in unrelated symbols that are known
> to not be needed (or?) and can cause collisions.

Maybe.  But it would not alleviate the need for ABI stability: whereever
the linker gets a specific symbol from, all users of it need to expect
and get the same semantics.

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

If someone links statically against those libs (and you haven't renamed
all nonlocal gnulib symbols): yes, there will 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.

ACK.

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

ACK.

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

No, I think you are getting it right.  That's why I asked for a general
purpose renaming mechanism earlier.  I guess it could be implemented in
gnulib-tool.

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

Yes.

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

Yes, I would encourage you very strongly to disallow any such usage
(by policy, not by technical means).

Cheers,
Ralf