[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: XEmacs

John Goerzen writes:
 > It did not help the problem for me, unfortunately.  Keep blugging away
 > on the install disks, but if you have a chance, any help you can
 > provide would be appreciated.

Your right, there seems to be a problem with the latest compiler on
xemacs, it does not build either for me. Reverting to a egcs-1.0.3
based compiling environement seems to workfor me (at least for
nomule-build and mule-build, the other can-wnn6-build seems to fail
because I did not installed some required lib, I did not try to
investigate which).

I will try to upload it that soon (then after slink, we can try to
identify the compiler problem).

Anyway a small status on the boot-floppies: I am actually trying to
focus on getting a bootable CDROM working for every archs, because
these days floppy disks sometimes becomes rare :-)

First a suggestion about the future (not applicable to slink): finally
I feel it is bad to use  MILO for people using SRM, because the
palcode given by SRM is generally more uptodate than the one included
in MILO (search for instance the comment on MILO by the NETBSD people,
which may be exagerated, but has probably a good part of truth in

For slink we cannot do this because kernel 2.0 are either for MILO or
for "native" SRM ("native" means here without going trough milo), and
as I do not want to  generate 40 rescue disk instead of 23 which is
enough, I suggest we always go through MILO. So that means any kernel
we ship is for MILO (except for no-MILO-archs). This also has the
advantage for testing that we only have one kernel per arch. 

Another solution would be to switch to 2.2 kernels, but it is probably 
to late for that.

There is also the issue of the user interface, ultimately, it would be 
nice if milo and aboot could share the same user interface, with only
a different backend (SRM console for aboot, linux subset + custom pal
for MILO), but this is not doable for slink. And the MILO interface
looks easier and more intuitive.

Now, going back to the bootable CDROM, for ARC or AlphaBIOS no
problem, we just have to make the milo and linux file available in
some directory. For SRM, being able to boot different MILO from the
same CDROM is not trivial. I am trying to modify aboot to do this,
I may or may not succeed to do it (if there is any expert on palcode
or aboot: does anybody know if the JTOPAL entry for cserve is
implemented on standard SRM console after switching to OSPAL? Or how
to enable the physical mapping under the original VMS palcode, or how
if we can switch back to VMS palcode after being under the OSFPAL?

Anyway a fallback is to provide one 2.2.1 generic kernel on the CDROM
that will be used for SRM people. This has both pros and cons against
modifying aboot to boot a MILO.


Reply to: