Re: Retiring WITHOUT_CXX

On 2 Dec 2021, at 17:02, John Baldwin wrote:

> On 11/26/21 11:06 AM, Bjoern A. Zeeb wrote:
>> On Fri, 26 Nov 2021, Ed Maste wrote:
>>
>>> On Fri, 26 Nov 2021 at 04:09, Rodney W. Grimes
>>> <freebsd-rwg@gndrsh.dnsmgr.net> wrote:
>>>>
>>>> So is the feature model of FreeBSD becoming, oh it gets broken
>>>> cause it is not regularly tested, so lets remove that feature.
>>>
>>> I don't agree with that. We have a large and growing CI 
>>> infrastructure
>>> to regularly test functionality and are continually adding to it 
>>> over
>>> time. But it's important to test and maintain what is actually used
>>> and is useful. Disabling C++ support made sense when obrien@ added 
>>> the
>>> original knob in 2000, but it makes less sense today when parts of
>>> FreeBSD are written in C++.
>>
>> I used to disable it in my images but started to need devd and that 
>> is
>> really the only reason its there currently
>>
>> #WITHOUT_CXX=   # devd needs it
>>
>> I used to have a conversation with Warner a while ago about it and 
>> the
>> conclusion was the bits of C++ could be reimplemented in C if needed
>> but obviously no one ever got to that.
>
> I honestly think that's the wrong direction.  I'm currently hacking on
> a libiscsi for shared bits of iscsid and ctld and right now it has 
> some
> home-grown containers (struct keys) that would be much better as a
> std::vector<> of a struct with two strings.  It would also benefit 
> from
> having an actual class for the instead of the typical C inheritance 
> I've
> added.  Similarly, I've wanted to use std::unordered_map in truss to
> handle the syscall counts since hash tables in C require a lot of
> boilerplate code.  This is no longer 1985, or even 2003.  I'm not 
> ready
> to write a kernel in C++ with templates, but I think for userspace
> utilities you can buy a fair bit of robustness with RAII, unique_ptr,
> etc. and we shouldn't be crippling ourselves.

I am not saying you should.
But with the current set of essential things in base its a waste for 
tiny installs.

> Also, have you looked at what WITHOUT_CXX actually removes?

yes, I believe it was even in the email you quoted.

> c++ is just
> a hard link to clang.  That's the big space eater, not libc++.so.1 or
> libcxxrt.so.1.  For reference, on my 13.x desktop, libc.so.7 is about 
> 3
> times the size of libc++.so.1:

And I tried a few times in the past to see if we can anything about this 
and was explained “no”;  if libc will be ever growing it’ll be a 
huge problem one day;  we even had an option which never worked for 
SYMVER (you may remember removing last year; thanks for that!).

> -r--r--r--  1 root  wheel  1986208 Aug 19 15:28 /lib/libc.so.7
> -r--r--r--  1 root  wheel   112200 Aug 19 15:29 /lib/libcxxrt.so.1
> -r--r--r--  1 root  wheel   846200 Aug 19 15:29 /usr/lib/libc++.so.1

If you are running a 32M/40M (once was in the 20MB) user space you will 
notice every MB and especially every library you don’t have to care 
about removes complexity of stripping things down.


If we want to remove options to limit the mess (which was the other part 
of the discussion) there’s a lot of historic stuff which could be all 
or nothing really, like BOOTPARAMD BOOTPD RBOOTD …  all just disabling 
a 1 single binary and not a “set of things”/subsystem (like 
Toolchain, ntp, nis, kerberos, ..) which reducing the number of options 
would stop heating the world at least some.

/bz