On Wed, Oct 23, 2002 at 01:35:30PM -0400, Andrew Gallatin wrote: > > Ruslan Ermilov writes: > > Nice. I was going to ask Peter to upgrade beast with this fix, but > > now that you've already tested it, I'd like to back out the hack in > > groff/src/roff/groff/Makefile, if there are no objections. > > OK.. with the new rtld, a shared groff works. > > Before you backout the static hack, can you explain the upgrading > implications? > > Since both a new rtld and a new kernel are required to be able > to buildworld from an alpha older than yesterday, do we just > note that in UPDATING, or do we somehow build groff statically > in the early phase, so that a the early stages of buildworld > will not depend on having a updated rtld? > OK, to summarize things. There was a single problem with two symptoms: 1) groff, if built dynamically, could not be run by ld-elf.so; 2) groff, if built statically, always failed with ``out of memory'', apparently due to the same bug.
Static hack is safe to delete because:
1. groff that is built as part of the bootstrap-tools during
buildworld will be built static anyway (see -DNOSHARED in
BMAKE in Makefile.inc1)
2. if you have a vulnerable kernel and rtld-elf, static
linkage does not address the problem -- you get spurious
``out of memory'' even if you link groff statically.
If you agree, please feel free to commit the backout of
the hack yourself -- I'm going to leave the computer now. :-)
So, to successfully upgrade your Alpha, you must either
upgrade your kernel and rtld first (which might be a bit
tricky), or to avoid running the bootstrapped groff during
the "transitional" buildworld. All consumers of groff
are manpages and share/doc documents, with only one nasty
exception -- usr.sbin/lpr/SMM.doc/Makefile, so it should
be possible to buildworld with -DNOMAN, -DNO_SHAREDOCS,
and -DNO_LPR to achieve this -- avoid running groff during
the transitional upgrade.
PS.
Someone could tell me what is different with Alpha so
that it produces only one PT_LOAD segment, compared
to i386? Just wondering...
Cheers,
--
Ruslan Ermilov Sysadmin and DBA,
[EMAIL PROTECTED] Sunbay Software AG,
[EMAIL PROTECTED] FreeBSD committer,
+380.652.512.251 Simferopol, Ukraine
http://www.FreeBSD.org The Power To Serve
http://www.oracle.com Enabling The Information Age
msg44828/pgp00000.pgp
Description: PGP signature
