Re: Preview: portable dumper

[Reini Urban <reini.urban@gmail.com>]

> > 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
rurban@cpan.org