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

[Jonathan Wakely]

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.