Re: control of symbols exported by shared libraries

[Simon Josefsson]

> Simon Josefsson wrote:
>> it appeared to me that a
>> preferable approach would be to fix libtool, and I thought that had
>> been done.  Joe Orton of RedHat even asked me to use Libtool's
>> --export-symbols-regex in GnuTLS, for instance.  I have been using it
>> all of my libraries for a long time.  No non-external symbols are
>> exported, from what I can tell.  Output below.
>
> You're right. For Linux systems, it has been fixed in revision 1.29 of
> libtool/m4/libtool.m4, on 2004-01-07, i.e. since libtool-1.5.2.

Ok.

> Still, this implementation of symbol export control optimizes only the
> symbol tables, and has no opportunity to optimize the code, because the
> compiler doesn't know which symbols will be exported when it compiles
> from .c to .lo.

I didn't completely buy/understand that argument.  I mean, the symbols
that are not intended to be exported should all be marked with "static"
anyway.  I'm travelling, but IIRC the paper had an example for this, and
it was some global variable 'int last' or something, which the compiler
couldn't be sure whether it was an external symbol or not, so it had to
assume the worst case (i.e., set it up as an external symbol).  I think
for my projects, that assumption isn't problematic, the global
variables/functions are exported.  If I'm not going to export them, I mark
them as static.  I'm probably missing something.  Internal helper
functions perhaps?

Regards,
Simon