Re: per-file symbol versioning

[Phil Edwards <phil at jaj dot com>]

On Fri, Dec 20, 2002 at 12:33:23PM -0600, Benjamin Kosnik wrote:
> Is there a way to do per-file symbol versioning? Say there exists a new
> implementation of libsupc++/demangle.o that has a bunch of std::vector
> instantiations that need to be internal-linkage only. Currently, they
> are versioned with GLIBCPP_3.2 due to the way the symbol versioning file
> (link-map.gnu) is set up.
> 
> I could do more edits to the symbol-versioning file, but
> am wondering if there is a cleaner solution.

I think you're SOL on this one.

> Is there a way to say, hey, for this file only use these rules? Or is
> there a way to break apart the libstdc++ and libsupc++ symbol versioning
> (which are now done at the same time as libsupc++ is a convenience
> library) so that in the libsupc++ symbol-versioning file all the
> namespace std:: symbols are not exported, and internal only?

The convenience library is just a .a, isn't it?  Urgh...

Since versioning is done on a per-output file, not per-input, it might
be possible to insert an intermediate step in our build process, where
multiple .so's are created and thus can use multiple version scripts.
Then we take all the .so's and relink them into a single .so.  (Dunno whether
that would preserve versions on the symbols or not.)

No idea how to implement that within libtool, though.


Phil

-- 
I would therefore like to posit that computing's central challenge, viz. "How
not to make a mess of it," has /not/ been met.
                                                 - Edsger Dijkstra, 1930-2002