From owner-freebsd-current Sun Oct 20 15:41:31 2002 Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1578337B401; Sun, 20 Oct 2002 15:41:29 -0700 (PDT) Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3562F43E8A; Sun, 20 Oct 2002 15:41:24 -0700 (PDT) (envelope-from gallatin@cs.duke.edu) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.9.3/8.9.3) with ESMTP id SAA25947; Sun, 20 Oct 2002 18:41:23 -0400 (EDT) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.11.6/8.9.1) id g9KMere04606; Sun, 20 Oct 2002 18:40:53 -0400 (EDT) (envelope-from gallatin@cs.duke.edu) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15795.12533.559894.717547@grasshopper.cs.duke.edu> Date: Sun, 20 Oct 2002 18:40:53 -0400 (EDT) To: John Baldwin Cc: current@FreeBSD.org, ru@FreeBSD.org, obrien@FreeBSD.org Subject: Re: New groff breaks alpha world In-Reply-To: References: X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG 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 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message