From: jwinstea@fenris.claremont.edu (Jim Winstead Jr.) Subject: Re: Trouble compiling gzip-1.0.3 Date: 21 Feb 1993 21:53:32 GMT
In article <1993Feb21.133120.16902@kth.se> md88-cms@hemul.nada.kth.se (Carl Michael Skoog) writes:
In <1m7tbhINN13t@uwm.edu> rick@ee.uwm.edu (Rick Miller, Linux Device Registrar) writes:
>I run the configure script, and everything seems to go all right, until it
>tries to execute the config.status script which it has created. That gives
>the first error I see:
>discus:: command not found (My `hostname` is discus.)
I noted this too. The problem is that 'hostname' is returning a
false return value. 'configure' is trying to execute something like
(hostname || uname -n)
to determine the hostname, and since 'hostname' returns a non-zero
status, uname -n is executed too.
Therefore, ensure that 'hostname' is not executed.
Um, basically, but that's not quite all of it. What happens is that
when configure builds config.status, it ends up running both hostname
and uname -n, so you get two lines like this in config.status (plus
some context):
# This directory was configured as follows,
# on host holli
holli:
#
The first 'holli' is from hostname, the second (on a line without a
comment indicator) is from 'uname -n'.
When configure goes on to run config.status (to generate the makefile)
it tries to execute the 'holli:', which it then reports it can't find.
It's perfectly harmless, and is basically just an extraneous error
message that you can ignore. 'hostname' should be fixed to return the
correct exit value, though, so this doesn't become a FAQ.
>But it creates a Makefile anyway... So I "make", and after compiling all
>of the stuff it comes back to me at the end with a linker error saying
>ld: No such file or directory for libg
>What gives?
Dunno about this one, but if memory doesn't fail me sed was broken
by libc4.2. Check how the Makefile comes out, and you might be
able to spot the fault.
This one is way off the mark.
What happens is that by default, configure uses the '-g' flag for
compiling and linking (CFLAGS and LDFLAGS). This tells gcc, the C
compiler, to add debugging code (lots of it) to the output, and when
linking, to link against libg.a instead of libc.a. libg.a is usually
the C library ocmpiled with debugging information.
So, unless you have install extra-4.3.tar.z, which contains the
debugging version of libc.a (libg.a)m it will come up with the above
error when you try and link a program with the -g flag.
There are two ways to fix the problem - the best would be to take -g
out of the Makefile unless you plan on doing some debugging on the
program using gdb (the GNU debugger). The other solution would be to
make a symlink from libc.a to libg.a so that it links against the
'regular' C library. That way you can debug your program using gdb,
but you won't be debugging the C library (and it will cut down on the
size of the linked executable quite a bit). The third solution is, of
course, to get extra-4.3.tar.z from tsx-11.mit.edu or elsewhere, and
link with the debuggable version of the C library. You're going to
get some really hefty executables, though.
(Also, if you just make a link from libc.a to libg.a, any binaries you
link with -g will end up being linked statically instead of against
the dynamic libs. That means you'll have huge binaries that contain
all the library code versus having small binaries that use the shared
libraries.)