@dim, I marked you as a subscriber in case you might have a comment on the right fix for this. We use -Wredundant-decls for gcc builds and so gcc complains about __throw_runtime_error in libc++. If you have an idea about which header ought to have the decl upstream (or some other fix) I can work up a patch for that.

Rather use:

CWARNFLAGS.gcc+= -Wno-error=shadow

or better:

CWARNFLAGS.gcc+= -Wno-shadow

if the warning(s) are not actionable.

We're probably the only ones in the world compiling libc++'s headers with -Wsystem-headers, so these kind of warnings are only seen by us...

In any case, shutting up the warning is fine with me, I never saw the value in warning about redundant declarations anyway: if they declarations are the same, it does not matter at all, and if they are different, it is (or at least should be) a compile error.

Similar to above, you can use:

CWARNFLAGS.gcc+= -Wno-error=redundant-decls

or better:

CWARNFLAGS.gcc+= -Wno-redundant-decls

if the warnings are non-actionable.

This kind of nastiness would not be needed if you'd use new[] and delete[]. ;-)

Okay. I'll check that that works. The shadowing occurs in the API (name collision between public procedure name and structure name) and it's probably not worth making an API change to suppress this.

Right, it's a bit of a pain to maintain, since we don't specify the equivalent warning from clang. Maybe we should just stop specifying it for gcc.

Anyway, my concern was that as FreeBSD grows more C++ code, we may run into this some more.

Yes, this one is also not actionable. I'll test your suggestion.

Yes...

I made the minimal fix here because it wasn't clear to me where (or if???) this memory is freed--or if it is just leaked.

You're welcome to "fix". But aggressively freeing things on exit() doesn't strike me as particularly good use of one's attention.

Ah, it's only called once?

No, I'll let it be, I'm just trying to get the build working, I'm not trying to police anything here :)