Re: Preview: portable dumper

[Reini Urban]

> > C programmers are a dying breed
> I don't agree, as C is an essential component of GNU/Linux and is 
> robustly represented in the practical and research programming 
> communities. (For what it's worth, C's popularity is ranked #7 in PyPL 
> and #2 in TIOBE.)

>When did you last try to hire a C or C++ programmer?

>As another data point, just look in the logs at the names of people
>who make C-level changes, and count them.

>I didn't say I like this, but leading a project to be viable in the
>future needs to look at the reality, not at our wishful thinking.

Maybe I should tell you, that interestingly Emacs is not the only project 
affected by this glibc/dumper dispute.

I added the stone-old unexec patches for perl to my cperl fork, to be able to 
dump/compile perl scripts to native binaries the fast way.

Improved dumpers are here: 
https://github.com/perl11/cperl/commits/feature/gh176-unexec 
I guess I’m the only one who touched this code in the last decades, nobody in 
emacs and nobody in perl.

Mostly unified error handling and a few darwin segment instabilities. It is 
very fragile to use with a static library, but ok as dynamic library. Emacs 
uses the dumper in the main exe, not in a library. Solaris is the easiest to 
use.

So I know a little bit of the troubles they are talking about here. Dan's 
portable dumper would be nice to have, XEmacs had this decades ago, but it 
never made it over here. Wonder why :)

So looking at the new pdump, it really is horrible. I don't think I want to do 
that. I'll rather add a proper static malloc to cperl, such ptmalloc3, which is 
better than glibc malloc, i.e. ptmalloc2, anyway. They never switched to the 
better version, because it had more memory overhead. And I really can make use 
of the arena support there. Emacs should try the same. Much easier and much 
faster. Good bye glibc.

Reini Urban
address@hidden