symbol versioning, take 2

Benjamin Kosnik bkoz@redhat.com
Wed Feb 13 21:49:00 GMT 2002


Sorry Phil, I'm just getting to this. This is great work, thanks.

> I don't know why this didn't occur to me until now:  one obvious suggestion
> would be to version the contents of libsupc++ separately.  At the source
> code level they've taken clear steps to provide "C++ ABI version 1" and
> it seems like doing the same thing at the linker level would be in line.
> A tag like CXXABI_1.0 or something.

Right. The libstdc++ bits should be versioned distinctly.

> I have also worked up a patch to provide --enable-symvers for those of us
> experimenting with this functionality.  It's a minor tweak to
> src/Makefile.am, and the script below is assumed to be
> "config/linker-map.gnu".  There are minimal tests in the enable switch for
> GNU ld; they also need improvement before going live. 

This sounds like a good plan. I think the goal should be to 
have --enable-symvers default to on for supported platforms as soon as 
the testresults match. 

> The idea behind the tests and the name of the version script is that, if
> someone wants to provide a script which does not require GNU ld, we can
> drop that in config/linker-map.foo and --enable-symvers will DTRT. 

Or do you want to have it default to off, and have --enable-symvers=gnu or
--enable-symvers=mach-o switch appropriately? The configure bits can probe
for required functionality, and flip it on it the correct bits are found.
Doing The Right Thing is cool and all, but it's really a good idea to have
a configure option to turn it off completely, or explicitly configure 
for specific configurations, if desired. 

Something to think about.

> What needs to happen next:  we may need more symbols exported.  We may
> need fewer symbols exported.  About 90% of the script below is guesswork.
> In short, we need the C++ ABI experts to attack it.

Ok. Can you post the complete patch, so I can work on it?

Also, what is the status on the binutils patch?

-benjamin




More information about the Libstdc++ mailing list