Version scripts (was Re: -retain-symbols-file question, libtool errors)

[Jakub Jelinek <jakub at redhat dot com>]

On Mon, Dec 10, 2001 at 10:32:56AM -0800, Ian Lance Taylor wrote:
> > --retain-symbols-file only kills .symtab symbols not present in the list,
> > but doesn't kill any .dynsym symbols.
> > Is that the desired behaviour?
> > E.g. libtool trustfully uses --retain-symbols-file when passed
> > -export-symbols option.
> > Or should libtool just create a version script on the fly?
> > Or should there be a different option, like --retain-dynsyms-file which
> > would do the same for dynamic symbols?
> 
> I don't think the behaviour of --retain-symbols-file should be changed
> to also apply to dynamic symbols.  As you note, there is already a
> different way to control dynamic symbol visibility, which is to use a
> version script.
> 
> Creating a version script which simply controls visibility on the fly
> is no harder than creating the input file for --retain-symbols-file on
> the fly, so I don't see a need for a --retain-dynsyms-file option.
> But if people really want it, it's OK with me.

Using version script is preferable, though unlike Solaris version scripts
which happily use
{ global: foo; local: *; }
GNU ld doesn't handle this at all (requires that there is some version
string defined).
In Solaris linker, this leads into all global symbols in the unnamed
to get VER_NDX_GLOBAL Versym (and unless there is another version defined in
that file, no VERDEF section is created).

If libtool was using -Wl,--version-map,on-the-fly-created-version-script
for --export-symbols with GNU ld, it would have to synthetize some magic
version name, but then all undefined references against such library global
symbols would end up with that magic name too which is probably not what the
user of --export-symbols wants.

Should I hack support for these anonymous versions into GNU version scripts
or do you propose something else?

	Jakub