Jan> Of course. That is the whole idea. In fact last time I built an XEmacs Jan> from scratch that was also the case. What is the problem? I build with mule. AFAIK, you cannot build a Mule-enabled binary without having the compiled mule-base package around, which you cannot generate without a Mule-enabled XEmacs... The other packages that need to be dumped (egg-its and skk, I think), are not that problematic, because you rebuild XEmacs once you compiled them. Jan> You points about building the packages from source are valid. However Jan> the current situation is already an improvement. It used to be that Jan> you could ONLY build ALL the packages from scratch. The clever preload Jan> stuff needed for that made it in impossible to build just a single Jan> package. Moreover you needed yo make your environment almost an exact Jan> copy of that of Steve's. These requirements no longer apply. If this Jan> has been achieved at the cost of only some fixable dependency problems Jan> in the from-scratch build that is a positive thing. I just found out it fails for me (with Stephen Turnbull's hints leading the way). I build the packages (from a clean source) with make STAGING=/home/xemacs/package-staging bindist The bindist rule doesn't build the autoloads beforehand (like "make all" does), and therefore fails like that. Maybe one should have a target "autoloads", and have bindist depend on that. Doing a "make all; make bindist" sucks, because then some packages get bytecompiled twice, and it takes long enough already. leo