Re: [PATCH] new option for objcopy: --keep-global-symbol

[Nick Clifton <nickc at cambridge dot redhat dot com>]

Hi Honda,

> > >     project --+-- system --+-- main.c
> > >               |            +-- sub.c
> > >               +-- libfoo --+-- foo1.c : foo_init(), foo_doit()
> > >               |            +-- foo2.c : subroutine1(), subroutine2()
> > >               +-- libbar --+-- bar1.c : bar_init(), bar_doit()
> > >                            +-- bar2.c : subroutine1(), subroutine2()
> > >
> > > Now look at `libfoo' directory.  It has four global symbols (foo_init,
> > > foo_doit, subroutine1, subroutine2), but we want to export only the
> > > former two (foo_init, foo_doit).
> > >
> > > [Proposal for new objcopy option to selectively 
> > >  make some symbols local].
> > 
> > I am not sure that this is such a good idea.  It would mean that
> > your library could only be built with a patched version of objcopy
> > (or a release after 2.11) which would make it less portable.
> 
> Hmm, so the question is whether or not the advantage of my proposal
> is greater than the disadvantage of portability restriction.

Well that, plus the fact that this is the first time (to my knowledge)
that a patch like this has been proposed.  But people having been
building libraries for ages, so how has this problem been solved
before now ?


> > Instead why not just prefix the local-to-the-library subroutines,
> > so that a name clash does not occur.  ie rename subroutine1() on
> > foo2.c to libfoo_subroutine1(), and so on.
> 
> Theoretically it suffices, but in practice it is inconvenient.
> 
> When libfoo has 10 files and 50 global symbols, and when we want to
> export only 5 symbols, we should prefix 45 local-to-the-library
> subroutines, which is awkward and makes the source code less readable.

Well a script could easily handle the renaming, and I seriously doubt
that a small prefix to function names would make the code less
readable.

> Or, when some of the local-to-the-library subroutines are generic
> mini-libraries (e.g. hash_lookup, lzw_decode, ...) taken from
> elsewhere, we don't want to spend tedious time renaming those
> mini-library subroutines.

Although a set of hash defines could handle that for you.


> In normal cases, we have relatively small number of export symbols
> while there are many local-to-the-library ones.  Moreover, during the
> library development, we rarely add/remove export symbols while we
> frequently add/remove local-to-the-library ones (i.e. we rarely change
> external API while we frequently change internal implementation).
> Therefore, in the Makefile, it is more convenient to specify export
> symbols than to specify local-to-the-library ones.

True, but I am suggesting that you do not do anything in the
Makefile.  You just keep your local-to-the-library functions out of
the way by prefixing them with private-to-the-library prefix.  In
fact if you are coding in C++ you can use namespaces to achieve the
same kind of effect as well.


Another problem that occurs to me if you strip all of the non-exported
global symbols out the library by using this proposed patch, you will
be forced to do this on a fully resolved binary.  Otherwise the final
link of the application will fail because there will be internal
references in the library that cannot be resolved.  But by fully
resolving the library you are forcing the application to link with the
entire library, not just those components that it uses.  This may not
be a problem for applications linking against shared libraries, but
static links in means that the application can become unnecessarily
bloated.


> An ideal solution will be to support selective specification of
> externally visible symbols not for object files but for archive files.
> However, it will require considerable amount of changes to binutils,
> and will introduce binary incompatibilities on archive file formats.
> So I propose the patch for objcopy as a second solution.
> 
> I hope you agree with me and accept the patch.

I am sorry but I still have serious misgivings about accepting this
patch.  I am still open to persuasion however, and I hope that this
email will start some discussion on the binutils list to see what
other people think.

Cheers
        Nick