some more problems with binutils/gcc/libc (fwd)

[hjl@nynexst.com (H.J. Lu)]

Forwarded message:
>From riepe@ifwsn4.ifw.uni-hannover.de Sat Oct 22 21:35:21 1994
Date: Sun, 23 Oct 94 02:38:33 +0100
From: riepe@ifwsn4.ifw.uni-hannover.de (Michael Riepe)
Message-Id: <9410230138.AA02201@ifwsn4.ifw.uni-hannover.de>
To: eric@aib.com, hjl@nynexst.com
Subject: some more problems with binutils/gcc/libc
Cc: riepe@ifwsn4.ifw.uni-hannover.de

Hello!

During the past week I encountered the following problems:

1) ld (both gas-9410* and binutils-2.5) has problems with .comm symbols
   when a.out format is used:

	$ cat >test.c <<EOF
	#include <stdio.h>
	#include <unistd.h>
	char **environ;	/* this should work... */
	int main(void) { return 0; }
	EOF
	$ gcc test.c
	environ.o(*IND*+0x0): multiple definition of `environ'
	$ 

   Using `extern char **environ;' works. ELF works, too.
   Binutils-1.9* worked. Libc was 4.6.16, gcc 2.6.0-941014

2) ld -m elf_i386 -static is broken (this is sln.c from util-linux-1.10):

	$ gcc-elf -static -O2 -m486 -fomit-frame-pointer -s -N sln.c -o sln
	$ ./sln
	bash: ./sln: No such file or directory
	$ ldd ./sln /sbin/sln
	./sln:
	/sbin/sln:
		statically linked (ELF)
	$ readelf -S /sbin/sln # this is the correct one, for reference
	There are 12 section headers, starting at offset 3acc:
	[0]            NULL            00000000 00000 00000 00 / 0 0 0 0 
	[1] .init      PROGBITS        08000080 00080 00059 00 / 6 0 0 10 
	[2] .text      PROGBITS        080000e0 000e0 02a64 00 / 6 0 0 10 
	[3] .fini      PROGBITS        08002b44 02b44 00003 00 / 6 0 0 1 
	[4] .ctors     PROGBITS        08002b48 02b48 00008 00 / 2 0 0 4 
	[5] .dtors     PROGBITS        08002b50 02b50 00008 00 / 2 0 0 4 
	[6] .data      PROGBITS        08002b58 02b58 002d8 00 / 3 0 0 4 
	[7] .bss       NOBITS          08002e30 02e30 000bc 00 / 3 0 0 10 
	[8] .stab      PROGBITS        00000000 02e30 002a0 0c / 0 9 0 4 
	[9] .stabstr   STRTAB          00000000 030d0 0066b 00 / 0 0 0 1 
	[a] .comment   PROGBITS        00000000 0373b 00330 00 / 0 0 0 1 
	[b] .shstrtab  STRTAB          00000000 03a6b 0005e 00 / 0 0 0 1 
	$ readelf -S ./sln
	There are 18 section headers, starting at offset 3328:
	[0]            NULL            00000000 00000 00000 00 / 0 0 0 0 
	[1] .interp    PROGBITS        080000d4 000d4 00013 00 / 2 0 0 1 
	[2] .hash      HASH            080000e8 000e8 00014 04 / 2 3 0 4 
	[3] .dynsym    DYNSYM          080000fc 000fc 00020 10 / 2 4 1 4 
	[4] .dynstr    STRTAB          0800011c 0011c 00008 00 / 2 0 0 1 
	[5] .rel.plt   REL             08000124 00124 00008 08 / 2 3 7 4 
	[6] .init      PROGBITS        08000130 00130 00051 00 / 6 0 0 10 
	[7] .plt       PROGBITS        08000184 00184 00020 04 / 6 0 0 4 
	[8] .text      PROGBITS        080001b0 001b0 02a70 00 / 6 0 0 10 
	[9] .fini      PROGBITS        08002c20 02c20 00003 00 / 6 0 0 1 
	[a] .ctors     PROGBITS        08002c24 02c24 00008 00 / 3 0 0 4 
	[b] .dtors     PROGBITS        08002c2c 02c2c 0000c 00 / 3 0 0 4 
	[c] .data      PROGBITS        08002c38 02c38 002d8 00 / 3 0 0 4 
	[d] .got       PROGBITS        08002f10 02f10 00010 04 / 3 0 0 4 
	[e] .dynamic   DYNAMIC         08002f20 02f20 00070 08 / 3 4 0 4 
	[f] .bss       NOBITS          08002f90 02f90 000b8 00 / 3 0 0 10 
	[10] .comment   PROGBITS        00000000 02f90 0030e 00 / 0 0 0 1 
	[11] .shstrtab  STRTAB          00000000 0329e 00089 00 / 0 0 0 1 
	$ 

3) I couldn't get tcl7.3/tk3.6pl1 to work yet. More exactly, if I link
   wish with libtk.so, the program will dump core whenever I close a
   window or hit the OK or quit buttons. If linked with libtk.a, wish
   works fine.  It doesn't matter how libtcl is linked. I guess this is
   yet another function pointer problem (probably a very weird one) - tk
   passes functions to tcl, and tcl is expected to call them back, but
   that never happens in some cases. While dealing with this, I also
   found out that I can't debug a shared library with gdb 4.13 - it just
   tells me a lot of nonsense :(

   I have another problem here I can't solve - one of the tk demos
   reliably kills my X server with a floating point exception (SIGFPE),
   but *only if I use the ELF server* - the a.out server works fine. It
   doesn't matter whether I use a.out or ELF versions of tk, it always
   kills the ELF server but never the a.out one. Linking the server with
   -mieee-fp helped, but I'm still curious what happened. Strange, huh?

4) Finally, an easy one ;) libc 4.6.16 needs the following patch:

--- chainsaw ---
diff -ru libc-linux.orig/rpc/clnt_simple.c libc-linux/rpc/clnt_simple.c
--- libc-linux.orig/rpc/clnt_simple.c	Fri Nov 20 07:11:24 1992
+++ libc-linux/rpc/clnt_simple.c	Wed Oct 19 20:24:19 1994
@@ -57,12 +57,13 @@
 } *callrpc_private;
 
 int callrpc(host, prognum, versnum, procnum, inproc, in, outproc, out)
-	char *host;
+	__const char *host;
 	u_long prognum;
 	u_long versnum;
 	u_long procnum;
 	xdrproc_t inproc, outproc;
-	char *in, *out;
+	__const char *in;
+	char *out;
 {
 	register struct callrpc_private *crp = callrpc_private;
 	struct sockaddr_in server_addr;
diff -ru libc-linux.orig/rpc/getrpcport.c libc-linux/rpc/getrpcport.c
--- libc-linux.orig/rpc/getrpcport.c	Fri Nov 20 07:11:25 1992
+++ libc-linux/rpc/getrpcport.c	Wed Oct 19 20:24:19 1994
@@ -46,7 +46,7 @@
 	u_long prognum;
 	u_long versnum;
 	u_int proto;
-	char *host;
+	__const char *host;
 {
 	struct sockaddr_in addr;
 	struct hostent *hp;
--- chainsaw ---

Michael.
-- 
 Michael Riepe               <riepe@ifwsn4.ifw.uni-hannover.de>
 Universit"at Hannover
 Institut f"ur Fertigungstechnik und Spanende Werkzeugmaschinen
 Schlosswender Str. 5                  30159 Hannover (Germany)
 ... beware the storm that gathers here ("The Prophet's Song")


-- 
H.J. Lu
NYNEX Science and Technology, Inc.			hjl@nynexst.com