kubiak@bach.csg.uiuc.edu (Ken Kubiak) (10/16/89)
I've been trying to build g++ (near-1.36 version from labrea) on the unixpc.
I began by using the 1.36 gcc compiler avaliable from cheops. Since g++
requires the gcc .o files anyway, Istarted rebuilding gcc 1.36 myself using
gcc 1.35 (which I built earlier using the gcc 1.30 compiler from umn ?).
Anyway, the problem I have with gcc 1.36 on the unixpc applies to both the
binaries from cheops and the first-level binary I built.
When gcc is called as a loader (i.e., with a bunch of .o's), I get an error:
*** ld: command line *** -l can't find /libc.a
*** ld: command line *** -l can't find /libg++.a
Two questions: (1) why is it looking for these? Doesn't it just need gnulib?
(2) why can't it find libc.a anyway?
By the way, I edited the linker spec in gcc.c so as not to put -lc and -lg++
on the line, but then I have a bunch of undefineds, like "exit" and "fprintf"
w/o leading underscores.
I suppose I can use ld directly, but I'm curious about this problem.
Perhaps the kind person who built the 1.36 binary on cheops can give be a hint
on how he/she got past stage1.
Of course, if anybody has already built g++ for the unix-pc (aka 3b1, 7300),
that would save me a lot of headache. If so, perhaps we could have the
binaries posted to cheops.
Thanks in advance,
Ken Kubiak
kubiak@csg.uiuc.edu
Ken Kubiak
Computer Systems Group
University of Illinois at Urbana-Champaign
kubiak@csg.uiuc.edukdb@chinet.chi.il.us (Karl Botts) (10/17/89)
In article <1989Oct16.143219.29485@ux1.cso.uiuc.edu> kubiak@bach.csg.uiuc.edu.UUCP (Ken Kubiak) writes: >I've been trying to build g++ (near-1.36 version from labrea) on the unixpc. ... >When gcc is called as a loader (i.e., with a bunch of .o's), I get an error: > >*** ld: command line *** -l can't find /libc.a >*** ld: command line *** -l can't find /libg++.a > >Two questions: (1) why is it looking for these? Doesn't it just need gnulib? > (2) why can't it find libc.a anyway? 1) gnulib is just a helper lib with some multi-precision aritmetic and such stuff; the standard C lib on the local machine is stil needed. 2) If you have reproduced the error messages correctly, ld is looking for the libs in the root directory; they aren't there. On the 3b1 ld has the knowledge to search in /lib and /usr/lib hard-coded into it, except that the value of the LIBROOT envar, if set, is prepended. Therefore I don't see how the default search dir can be changed to the root; hence somebody must be passing those explicit filenames to ld. The culprit must be gcc. >By the way, I edited the linker spec in gcc.c so as not to put -lc and -lg++ >on the line, but then I have a bunch of undefineds, like "exit" and "fprintf" >w/o leading underscores. I'll bet this is part of the problem. You should not be editing .c files. If you cn't configure it in the makefile or, at last resort, in the .h files, you are inevitably going to blow away the portability which is the best feature of gcc. The 3b1 does require some special link handling, at least if you are going to use the shared lib (and you definitely should). I have gcc, binaries only, and I have managed after considerable effort to get an escellent environment working. I have fixed up make so that it reads some config files that tell it how to link with shcc, the excellent linker which is PD equivalent for cc but handles the shared lib very well -- and it takes a fair amount of finagling to do it right. I have also built front ends for the system header files to make it look quite ansi; it gets along very nicely with gcc. The result is that most usenet code compiles with gcc and links with shcc with no changes to the stock makefiles if they use macros for the compiler and linker or use the avaliable rules; otherwise I have to change perhaps two lines. >Of course, if anybody has already built g++ for the unix-pc (aka 3b1, 7300), >that would save me a lot of headache. If so, perhaps we could have the >binaries posted to cheops. I too would love to see the g++ binaries. Karl Botts ...{gargoyle|mcdchg|nucsrl|...}!chinet!kdb kdb@chinet.chi.il.us