This is the mail archive of the
mailing list for the libstdc++ project.
Re: preliminary libstdc++ ABI docs
- From: Phil Edwards <phil at jaj dot com>
- To: Benjamin Kosnik <bkoz at redhat dot com>
- Cc: libstdc++ at gcc dot gnu dot org
- Date: Mon, 8 Jul 2002 10:01:58 -0400
- Subject: Re: preliminary libstdc++ ABI docs
- References: <200207050022.g650MGc11444@waller.constant.com>
> Mostly incomplete. Posted in a plea for help only. At some point, this
> information should be posted on the main web page, say right after
> configure options.
I'll add some hooks for this.
> the complete list), but there is no version switch. Sorry. The GNU
> Project recommends that
Was there more here that got dropped, or is this one of the bits that
needs filling in?
> If you see symbols in the resulting output with "GLIBCPP_3.x" as part
> of the name, then the executable is versioned. Here's an example:
> U _ZNSt8ios_base4InitC1Ev@@GLIBCPP_3.1
Should that ABI version number be changed on the trunk?
Should that number have any relation to configure.in's libtool_VERSION,
which also tracks the ABI? (Everyone remember that the "version" in the map
file is just a text string and does not need to be able to be "calculated"
like a libtool version would, or any other version for that matter. I would
think that "3.1" should be either "3.2" or "5".)
Should a new GLIBCPP_foo inherit the symbols from GLIBCPP_3.1? I think it's
supposed to work that way, but this breaks new ground for me.
If ye love wealth greater than liberty, the tranquility of servitude greater
than the animating contest for freedom, go home and leave us in peace. We seek
not your counsel, nor your arms. Crouch down and lick the hand that feeds you;
and may posterity forget that ye were our countrymen. - Samuel Adams