Blackfin and version scripts

Russ Allbery rra at
Wed Jun 23 07:29:30 CEST 2010

Ralf Wildenhues <Ralf.Wildenhues at> writes:
> * Russ Allbery wrote on Tue, Jun 22, 2010 at 11:00:04PM CEST:

>> I would dearly, dearly love for libtool to pick up a --version-script
>> option that would pass in the full version script on platforms with
>> linkers that understand it, turn it into a symbol export list on
>> platforms that only support that,

> is this doable programmatically?  Without a full version script parser?

You would need a parser, but I don't think the parser needs to be
particularly complicated.

>> and suppress it entirely if the linker doesn't have any relevant
>> capabilities.  That would save me a ton of maintenance burden on some
>> of my packages, and it would then be easy to add a feature like the
>> above as well.

> Can somebody try to come up with a more detailed set of semantics, so we
> can judge a bit better whether this is feasible?  If it is, any
> volunteers on implementing this?

I can take a pass at starting.  All that I need for my packages is to
support the basic version syntax:

    <version> {

On platforms with linkers that support regular ELF versioning, libtool
would need to figure out the right flag to pass to the linker and then add
it to the link line.  On platforms that don't support that sort of version
script, libtool should extract the symbols listed in the global section
and then treat this flag as equivalent to -export-symbols pointing to a
file containing just the list of symbols in the global section.

Obviously, there are a bunch of other things you can do with symbol
versioning and this wouldn't be a replacement for what, say, glibc does.
But I bet it would be a good 80% solution.  

> Do you know the gnulib module lib-symbol-versions?  (No, it's not a
> complete solution.)

I hadn't looked at it before.  It looks like all that does is check
whether --version-script is supported by the linker.  I suspect that will
only cover GNU ld and Solaris ld on ELF.  The fallback to -export-symbols
is the main feature that I'd really like to see, since that's supported on
more platforms and satisfies another major reason why people use version

I suppose one could use lib-symbol-versions in conjunction with a
separately-maintained or generated export symbols map and apply both of
them.  I haven't tried that to see if there are any bad interactions
between -export-symbols and versioned symbols.

Russ Allbery (rra at             <>

More information about the Gcrypt-devel mailing list