pinard@EDDIE.MIT.EDU (Francois Pinard) (08/12/89)
On 386/ix 2.0.1, I'm trying to get gcc 1.35 and gas 1.31 to work. Trying the raw compiler, GNU ld complained of /lib/crt1.o not being in correct format. README-ENCAP, in binutils, only mention /lib/crt0.o for convertion. So I robotussin'ed /lib/crt1.o and /lib/crtn.o also. I got this diagnostic: $ robotussin /lib/crt1.o /usr/gnu/lib/gcc-crt1.o robotussin: Oops! possible bug - reloc reference to ignored symbol GNU ld further complain about a troncated gcc-crt1.o. My copy of robotussin.c is dated March 3. I would probably have to learn about COFF and binary formats, would it be only to understand what is going on. In the meantime, if the problem is already known or solved, please let me know. I presume that crt0.o, crt1.o and crtn.o are related to initializing and/or terminating a C program. What are their exact purpose? Thanks. -- Franc,ois Pinard pinard@iro.umontreal.ca (514) 588-4656 ``Vivement GNU!'' ...!uunet!iros1!pinard
james@raid.dell.com (James Van Artsdalen) (08/14/89)
In <8908120056.AA03499@kovic.IRO.UMontreal.CA>, mcgill-vision!IROS1!pinard@EDDIE.MIT.EDU (Francois Pinard) wrote: > I presume that crt0.o, crt1.o and crtn.o are related to initializing > and/or terminating a C program. What are their exact purpose? Under SysVr3, crt0.o can be used by itself when there are no shared libraries. When shared libraries are used, crt1.o must be the first object linked and crtn.o the last (after all libraries). Since GNU ld doesn't know about SysV shared libraries, you can just use crt0.o and ignore crt[1n].o (and not use shared libraries). -- James R. Van Artsdalen james@raid.dell.com "Live Free or Die" DCC Corporation 9505 Arboretum Blvd Austin TX 78759 512-338-8789
pell@isy.liu.se (P{r Emanuelsson) (08/14/89)
There is another robotussin problem which manifests itself on Sun386i systems.
An ABSolute symbol will not get the correct definition and ld will complain.
Unfortunately, ld still generates a.out's that core dumps immediately. If
someone has a solution for this, please mail me or post.
Included is also a patch for libconvert. Remember that ar truncates file
names to 14 characters. Thus, it may extract files that look like
"long_filename.". libconvert then fed robotussin all *.o files, which meant
that some files didn't get converted.
diff -rc2 binutils/a.out.gnu.h /a/src/gnu/binutils/a.out.gnu.h
*** binutils/a.out.gnu.h Thu Mar 2 21:49:14 1989
--- /a/src/gnu/binutils/a.out.gnu.h Sat Aug 5 22:01:26 1989
***************
*** 114,117 ****
--- 114,118 ----
#define N_UNDF 0
#define N_ABS 2
+ #define N_ABSOLUTE 2 /* Used in robotussin, N_ABS conflicts with COFF */
#define N_TEXT 4
#define N_DATA 6
diff -rc2 binutils/libconvert /a/src/gnu/binutils/libconvert
*** binutils/libconvert Mon Jan 9 16:26:43 1989
--- /a/src/gnu/binutils/libconvert Fri Aug 4 21:54:38 1989
***************
*** 35,39 ****
cd libconvert-tmp
/bin/ar x $rel_fromlib
! for i in *.o
do
echo $i
--- 35,39 ----
cd libconvert-tmp
/bin/ar x $rel_fromlib
! for i in *
do
echo $i
diff -rc2 binutils/robotussin.c /a/src/gnu/binutils/robotussin.c
*** binutils/robotussin.c Fri Mar 3 16:43:41 1989
--- /a/src/gnu/binutils/robotussin.c Sat Aug 5 22:01:50 1989
***************
*** 51,56 ****
#include "a.out.encap.h"
! #define N_ABSOLUTE N_ABS /* N_ABS will be redefined in syms.h */
! #undef N_ABS
#include <filehdr.h>
--- 51,55 ----
#include "a.out.encap.h"
! #undef N_ABS /* N_ABS will be redefined in syms.h */
#include <filehdr.h>
--
"Don't think; let the machine do it for you!"
-- E. C. Berkeley
Dept. of Electrical Engineering pell@isy.liu.se
University of Linkoping, Sweden ...!uunet!isy.liu.se!pell