Date: Sun, 20 Oct 2002 18:40:53 -0400 (EDT) From: Andrew Gallatin <gallatin@cs.duke.edu> To: John Baldwin <jhb@FreeBSD.org> Cc: current@FreeBSD.org, ru@FreeBSD.org, obrien@FreeBSD.org Subject: Re: New groff breaks alpha world Message-ID: <15795.12533.559894.717547@grasshopper.cs.duke.edu> In-Reply-To: <XFMail.20021019180048.jhb@FreeBSD.org> References: <XFMail.20021019180048.jhb@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
John Baldwin writes:
> groff just fails silently. However, groff does seem to give the
> runtime linker heartache for both succesfful and failing runs:
<..>
> /usr/libexec/ld-elf.so.1: groff: too few PT_LOAD segments
> *** Error code 1
This is a fatal error for the rtld:
if (nsegs < 2) {
_rtld_error("%s: too few PT_LOAD segments", path);
return NULL;
}
I spent a little time looking at this, and it appears that there
really is only one PT_LOAD segment in the groff binary, so I think ld
is at fault here. There's nothing alpha-specific in the code which
reads the elf header, so I don't think we can blame the rtld for this
one.
But I have no idea WTF ld is doing and that's about as far as I can
take it. FWIW, mounting my -stable partition and using the ld from
there produces a working binary. As does linking statically:
% ld --eh-frame-hdr -dynamic-linker /usr/libexec/ld-elf.so.1 -o groff /usr/lib/crt1.o /usr/lib/crti.o /usr/lib/crtbegin.o -L/usr/lib groff.o pipeline.o /usr/src/gnu/usr.bin/groff/src/libs/libgroff/libgroff.a -lstdc++ -lm -lgcc -lc -lgcc /usr/lib/crtend.o /usr/lib/crtn.o
% ldd ./groff
./groff:
/usr/libexec/ld-elf.so.1: ./groff: too few PT_LOAD segments
./groff: exit status 1
% /mnt/bin/ld --eh-frame-hdr -dynamic-linker /usr/libexec/ld-elf.so.1 -o groff /usr/lib/crt1.o /usr/lib/crti.o /usr/lib/crtbegin.o -L/usr/lib groff.o pipeline.o /usr/src/gnu/usr.bin/groff/src/libs/libgroff/libgroff.a -lstdc++ -lm -lgcc -lc -lgcc /usr/lib/crtend.o /usr/lib/crtn.o
% ldd ./groff
./groff:
libstdc++.so.4 => /usr/lib/libstdc++.so.4 (0x16004c000)
libm.so.2 => /usr/lib/libm.so.2 (0x160102000)
libc.so.5 => /usr/lib/libc.so.5 (0x16013e000)
Would it be acceptable to apply the following patch to link groff
statically so as to unbreak the alpha world while the binutils
maintainer figures out why ld is broken?
Drew
Index: Makefile
===================================================================
RCS file: /home/ncvs/src/gnu/usr.bin/groff/src/roff/groff/Makefile,v
retrieving revision 1.3
diff -u -r1.3 Makefile
--- Makefile 11 Apr 2002 11:06:05 -0000 1.3
+++ Makefile 20 Oct 2002 22:29:48 -0000
@@ -6,4 +6,10 @@
LDADD= ${LIBGROFF} -lm
CLEANFILES= ${MAN}
+.if ${MACHINE_ARCH} == "alpha"
+#XXXX ld produces only one PT_LOAD segment when this binary
+#XXXX is linked dynamically, which confuses the rtld
+LDFLAGS+= -static
+.endif
+
.include <bsd.prog.mk>
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?15795.12533.559894.717547>