🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: gnu.gcc.help
Article #50128

Final stages of gcc under SCO

#50128
From: R. Day
Date: Sun, 14 Nov 1993 16:20
56 lines
3016 bytes
  I need a couple final pieces of advice to complete my
project of building a full gcc development system 
for SCO, and it should be fairly easy -- I think it just
involves the linker.  Keep in mind as you read through this
that I am not a compiler wizard (but, gosh darn it, after
all this, I'm getting better).
  I've built gcc-2.4.5 and glibc-1.06 on my SCO ODT 3.0
box and moved stuff over to my generic SCO UNIX 3.2v4.0
host to test it.  The compiler part seems to be fine.
In fact, the runtime libs also seem to be fine -- it's just
the linker phase that is not as clean as it could be, and
I suspect I just need to know which flags to add to the
"gcc" command line.  Or something to that effect.
  On the 3.2v4 host (that has no dev sys but only gcc stuff
I've moved from the ODT box), I have the following setup
with respect to runtime libs:

   /usr/local/lib/libc.a	(built from glibc, of course)
   /usr/local/lib/gcc-lib/i386-sco3.2v4/2.4.5/libgcc.a

  For convenience, I copied libgcc.a to /usr/local/lib so
I can link more conveniently later.
  There are NO libs in /lib -- remember, this host has no
dev sys whatsoever; only what I've put on it from the other
machine.
  Create the ubiquitous "hello.c" program, and

    % gcc hello.c

    ld *command line* fatal: Can't open file crt1.o for input

  OK, this is understandable, there is no such file and gcc
clearly wants it.  But why?  I suspect that the linker needs
an object file with the symbol "_start" to know where the
executable must begin execution.  (Correct?)
  The lib /usr/local/lib/libc.a already has "_start" defined
so I suspect that I don't really need crt1.o, do I?  I can 
be more specific with the linker with:

    $ gcc -c hello.c
    $ ld hello.o -L/usr/local/lib -lc -lgcc -o hello
    $ ./hello

  SUCCESS! Clearly, doing it this way forces ld not to look
for crt1.o, since it doesn't really need it anyway.
Is there a command line option for gcc that suppresses the
search for crt1.o?  Or was there an option I should have used
during the build of gcc that would have had the same effect?
  Except for this nuisance, it seems to work.  If I can
clear up this last point, I will be happy to create a tar
distribution and put it on someone's ftp site for others.
Any advice?  Any offers for an ftp site?  Cheers.

Robert Day
Calgary Unix User's Group
Authorized SCO Instructor
Technical Details
Message-ID: <CGHpDL.KIJ@cuug.ab.ca>
Path: arc1-ca.pugleaf.net!gmd.de!xlink.net!howland.reston.ans.net!math.ohio-state.edu!cyber2.cyberstore.ca!nntp.cs.ubc.ca!alberta!fantom!crs-sys!nextedm!spl4!cuugnet!rpjday

Show Full Headers
Complete Article Headers
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 11318c,b8251001257465d7,start
X-Google-Attributes: gid11318c,public
X-Google-ArrivalTime: 1993-11-15 23:26:36 PST
Newsgroups: gnu.gcc.help
Path: arc1-ca.pugleaf.net!gmd.de!xlink.net!howland.reston.ans.net!math.ohio-state.edu!cyber2.cyberstore.ca!nntp.cs.ubc.ca!alberta!fantom!crs-sys!nextedm!spl4!cuugnet!rpjday
From: rpjday@cuug.ab.ca (R. Day)
Subject: Final stages of gcc under SCO
Message-ID: <CGHpDL.KIJ@cuug.ab.ca>
Date: Sun, 14 Nov 1993 16:20:07 GMT
Organization: Calgary UNIX User's Group
X-Newsreader: TIN [version 1.1 PL8]
Lines: 56