From mboxrd@z Thu Jan 1 00:00:00 1970 From: hjl@nynexst.com (H.J. Lu) To: ian@cygnus.com (Ian Lance Taylor), raeburn@cygnus.com (Ken Raeburn), gas2@cygnus.com Subject: some more problems with binutils/gcc/libc (fwd) Date: Sun, 23 Oct 1994 02:03:00 -0000 Message-id: <9410230902.AA01564@titanic.nynexst.com> X-SW-Source: 1994/msg00140.html 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 < #include 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 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