Path: utzoo!utgpu!water!watmath!clyde!rutgers!cmcl2!brl-adm!husc6!sri-unix!quintus!ok
From: ok@quintus.UUCP (Richard A. O'Keefe)
Newsgroups: comp.software-eng
Subject: Re: Question Re: Configuration Management
Summary: wrong
Message-ID: <679@cresswell.quintus.UUCP>
Date: 22 Feb 88 06:31:35 GMT
References: <497@aimt.UUCP> <5257@well.UUCP> <2984@metavax.UUCP>
Organization: Quintus Computer Systems, Mountain View, CA
Lines: 53

In article <2984@metavax.UUCP>, chris@metavax.UUCP ( PSA) writes:
> In article <5257@well.UUCP> pokey@well.UUCP (Jef Poskanzer) writes:
>  
> >One problem peculiar to Unix is caused by the brain-damaged library
> >system.  Let's say you have a .c file with 20 marginally related
> >routines in it.  You make it into a library, then write a program
> >that uses only one of those routines.  When you link it, guess what
> >happens?  All 20 routines get pulled into your executable.
>  
> I hate to say this, but why isn't such a linker the standard on Unix?
> It seems to me that if Unix is _the_ system for programmers, as it has
> been described to me several times, why does this idiocy exist?  What
> good is a linker that is so stupid, other than it's all there is?  One
> supposed Unix guru tried to tell me that this actually made the linker
> smarter!!!!!!   (I replied by asking how he removed his lobotomy scar.)
> 
Why not RTM?  If you want to be able to pull individual functions out of
a library, ***YOU CAN***.  What you do is
	cc -c foo.c baz.c ugh.c		# one file for each CLUSTER
	ar q lib.a foo.o baz.o ugh.o	# collect the .o files
	ranlib lib.a			# build a table of contents
Now, if you do
	cc user.c stuff.c lib.a
you will not get the "ugh" cluster out of lib.a unless you need it.

Now, why can't you do this with a single file such as what
	cc -c ugh.c
gives you?  Not because the linker is stupid, but because it is in
general impossible.  Suppose you have

	cat <<EOF >foo.c
	static f(...){...}
	static g(...){...}
	h(...){... f() ...}
	i(...){... g() ...}
	EOF

If you use h(), you'd like just h() and f(), right?  But how is the
linker supposed to know that h() uses f()?  The compiler has to tell
it, and UNIX compilers don't do that.  In fact, there's no law that
says a smart compiler can't notice that h() and i() look pretty similar
and decide to share some code between them.  Indeed, in the special
case of string literals, there are lots of C compilers that DO this.

The thing is, if you put 20 functions in one file (and nobody is
twisting your arm to do this, there is nothing at all stopping you
putting them each in its own file), you are telling the C compiler
"I *chose* to put these together, I *want* them loaded as a unit,
and if you can do something clever because of that, fine!".

Instead of flaming the UNIX linker, why not tell us the name of a
linker that does what you want?  Before doing that, though, you'll
want to check that it doesn't limit this facility to Fortran...