You might remember my problem with C++ especially on servers; yes that’s a post of almost two years ago. Well today I was able to go one step further, and kill another piece of C*+ from at least my main system (it’s going to take a little more for it to apply to the critical systems). And that piece is nothing less than groff.
Indeed, last night we were talking in #gentoo-it about FreeBSD’s base system and the fact that, for them similarly to us, their only piece of C++ code in base system is groff; an user pointed out that they were considering switching to something else, so a Google run later I come up with the heirloom project website.
The heirloom project contains some tools ported from the OpenSolaris code base, but working fine on Linux and other OSes; indeed, they work quite well in Gentoo, after creating an ebuild for them, removed groff from profiles, and fixed the dependencies of man and zsh.
A few notes though:
- the work is not complete yet so pleas don’t start already complaining if something doesn’t look right;
- man is not configured out of the box; I’m currently wondering what’s the best way to do this;
- after configuring (manually) man, you should be able to read most man pages without glitches;
- for some reason, we currently install man pages in different encodings (for instance man’s own man page in Italian is written in latin-1); heirloom-doctools use UTF-8 by default, which is a good thing, I guess; groff does seem to have a lot of problems with UTF-8 (and man as well, since the localised Italian output often have broken encoding!);
- groff (and man) both have special handling of Japanese for some reason, I don’t know whether the heirloom utilities are better or worse for Japanese, somebody should look into it.
Yeah, it would be great. Groff produce totally broken russian man pages.
Thanks for the great work. Was never a big fan of Groff.
Hi Diego,Based on your post of two years ago, I’m not sure what your intentions are. Could you please clearify?- libstdc++ is part and core of the c++ runtime (soon and more to be extended with c++0x features)- there is a difference in using stl or not- libsupc++.a is a static archive for minimalistic C++ support (mainly binary distros without use of stl)Cheers,Hans
I think the main problem is the tone of the entry. It’s not a crusade as in: destroy C++! It’s just a step towards enabling server builds without any C++ support to save space and compilation time there.In fact I’m a big fan of C++ but I’d love to see C++ bindings which are not in used not getting built on my system. Why should they if nobody uses them? Of course, it’s a bit hard to say wheter they’ll be required and asking for them to be split out into seperate packages where mainstream doesn’t provide them is a bit much.
The disabilities of groff regarding UTF-8 handling have been a showstopper for a complete migration to UTF-8 for quite some time now.Getting around this with using an UTF-8 enabled classic nroff indeed is an excelent way out. This doesn’t affect gentoo only, but any other distro. If there are no license issue blocking this, it definitely is the way to go.As a bonus we will get a leaner, less bloated tool.The only remaining bloat-piece in my minimal server setups now is glibc, but with heated current advance in µlibc I see hope.
Will you push the Heirloom Tools into the main tree? Overall, their UTF-8 compatibility seems well developed — much better than
prand other tools in GNU coreutils.@David PhilippiIf the goal is to optionally build c++ bindings, I could not agree more. I got the strong impression a basic server system should not have c++ stuff at all, my bad 🙂 (In my humble experience C++ gets more and more used in serverland even if other tools are available) But like earlier stated to make it fool prove, one has to check if gcc has c++ support or not. Also a useflag nocxx vs python,perl,ruby is a bit weird no? I have no experience with it, but asking upstream gently to make their C++ bindings optional should not be a big problem no?Regarding libstdc++, check out:=== test.cpp ===int main () { throw 10; return 0;}Fail: gcc test.cppLimited: gcc test.cpp -lsupc++Equal: gcc test.cpp -lstdc++Safe: g++ test.cpp
Could you please fix the dependencies of man-db for heirloom as you did for man?
Actually, it’s a bit difficult since the code is bugged when not using groff… I’ll see what I can do though, I need to get it fixed for upstream as well.
And actually man-db has a forced dependency on groff during the build, I’ll see what I can do but it doesn’t look promising for now 🙁
Okay, in tree it is, but there are quite a few notes I have to make here: * man-db needed to be fixed because upstream does not even compile-test it with non-groff interpreters; * for the same reason, the line-length (and page-length) setting is not working on anything but groff, which means that the man pages look very old-style, bloated and difficult to read; * I hate the roff language!