Re: libification: how to avoid symbol collisions?

[Junio C Hamano <gitster@pobox.com>]

Kyle Lippincott <spectral@google.com> writes:

> struct/enum/typedef/union names. That's going to be quite annoying to
> maintain; even if we don't end up having to do all 3,500 symbols, for
> the files that are part of some public library, we'd add maintenance
> burden because we'd need to remember to either make every new function
> be static, or add it to this list. I assume we could create a test
> that would enforce this ("static, named with <prefix>, or added to
> <list>"), so the issue is catchable, but it will be exceedingly
> annoying every time one encounters this.

No matter how we do this, we'd need to maintain that list, so the
choices are between "#define" and "objcopy --redefine-sym" if we
limit ourselves to static linking, I think.  The former may be more
portable but makes me feel dirty.  The debuggers will not see the
names we want to use, for one thing.  "rename selected symbols in *.o
files" approach, if it can be done on platforms we want the lib thing
on, would be more preferable.

We also should be able to create a single linkable object (e.g., Z.o
out of X.o and Y.o from the previous example---it could be Z.so that
is dynamically linked at runtime) to resolve the symbols that need
to be shared only among the object files (like "foo" that is defined
in X.o whose address is needed in Y.o) and after such a linking is
done, these "internal" symbols can be stripped away from the
resulting object file.  For that, we'd also need to maintain that
list of internal symbols that are needed in order to link our
objects together.