Re: Help with adding header w/ non-template functions to libstdc++

[Jonathan Wakely <jwakely at redhat dot com>]

On 06/08/18 23:22 +0000, Andrew Marmaduke wrote:
> Hello!
>
> I'm very green to working on GCC, but nonetheless I've been working on the
> contracts proposal (p0542). I feel like I've come a long way but I've been
> struggling with adding symbols to libstdc++.

Ugh, contracts. Yuck.

> Basically, I added a new header in include/std/ with the boilerplate
> modeled after the exception header. I added the source code in src/c++11
> and cheated by changing the Makefile to compile these files with gnu++1z

That should be gnu++17 now. Contracts are not part of C++17 though. I
suppose we can put it in src/c++17 if the contracts implementation
doesn't require any C++2a features yet.

> (obviously I should just make a new folder but I wanted to minimize reasons

There's already a src/c++17 directory, and all sources in there are
built with -std=gnu++17 automatically.


> things were going wrong). I modified the Makefiles to add the necessary
> contract.cc file and contract header as well. I can attach these files if
> anyone thinks they will be helpful but from my experiments I don't honestly
> think the contents of _these_ files are the problem.
>
> I read the documentation at
> /path/to/my/build/doc/html/manual/appendix_porting.html#appendix.porting.build_hacking
> and _mostly_ followed the steps:
> * I didn't run autoreconf,
> * I didn't run check-abi (though I did add the new version to the actual
> test file based of a previous patch),

You shouldn't be adding a new version, GLIBCXX_3.4.26 is the current
version and is still "open" for new symbols.

The docs say "When new symbols are added to the library they must be
added to a new symbol version, which must be created the first time
new symbols are added after a release."

New symbols have already been added since the last release.

> * I didn't update the documentation, and
> * I didn't generate baseline_symbol.txt.

Don't regenerate that file either. That happens before the release,
not every time new symbols are added.

> The above is a small white lie, because I _did_ run autoreconf, after
> changing override.m4 to use my local version. This is the only way I've
> been able to get the build to generate my version of the library. However,
> I still have to link the correct version for the executable that is built.
> I also tried running exactly auroreconf2.64 from a docker image of Ubuntu
> but it only changed one line! And the line it did change seemed more or
> less meaningless:

You need to use the right versions of autoconf and automake. It's
trivial to install them locally and set your PATH to find those
versions when working on GCC.

> if test "${with_gcc_major_version_only+set}" = set; then :
> >   withval=$with_gcc_major_version_only; if test
> > x$with_gcc_major_version_only = xyes ; then
> > +        get_gcc_base_ver="sed -e 's/^\([0-9]*\).*/\1/'"
> > -        get_gcc_base_ver="sed -e 's/^\([0-9]*\).*\$\$/\1/'"
> >       fi
> > fi
>
> Not only that, but the build still didn't generate the correct standard
> library version! It instead builds the older version.

What do you mean by older version? Do you mean it's still building
libstdc++.so.3.4.25 instead of libstdc++.so.3.4.26?

If you updated the libtool_VERSION and ran autoreconf then it should
work. Since you've told us you aren't following the steps properly I
can only assume that's the problem.

Anyway, libtool_VERSION was changed to 3.4.26 more than a month ago on
trunk (by https://gcc.gnu.org/r261866), so if you just use the current
trunk (which you should be doing anyway for new development) you
should get libstdc++.so.3.4.26 without needing to do anything.