Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cornell!uw-beaver!rice!sun-spots-request
From: mac@mrk.ardent.com (Michael McNamara)
Newsgroups: comp.sys.sun
Subject: Re: Shared libraries linker error
Message-ID: <2221@ardent.UUCP>
Date: 8 Feb 89 08:03:19 GMT
References: <615@dutrun.UUCP>
Sender: usenet@rice.edu
Organization: Ardent Computer Corporation, Sunnyvale, CA
Lines: 70
Approved: Sun-Spots@rice.edu
Original-Date: 28 Jan 89 21:57:42 GMT
X-Sun-Spots-Digest: Volume 7, Issue 142, message 2 of 8
X-Issue-Reference: v7n125

In article <615@dutrun.UUCP> mcvax!duttnph!hans@uunet.uu.net (Hans Buurman) writes:
>One user on a Sun 3/60 that has recently been upgraded to SunOS 4.0 was
>complaining about a function dumping core that should not have been used
>at all. It turned out that he had a function called select() in his
>program....
>Could somebody out there
>a) tell me which rules the linker uses ?

There is this neat facility on UNIX. :-) It's called man. :-) If you want
to know how something works, you type man. :-) Try man ld. :-)

The program works as coded.  From your decription, it sounds like his
compile command was

cc -o myprog myprog1.o myprog2.o -lsunwindow

This is automatically expanded to:

cc -o myprog myprog1.o myprog2.o -lsunwindow -lc

One of the  linker's job is to link up references to external routines.
It's rules are well defined. Look in the manual for ld.  This behaviour is
unchanged since early unix days:
...
     If a named file is a library, it is searched exactly once at
     the  point  it  is  encountered  in the argument list.  Only
     those routines defining an unresolved external reference are loaded...
	                        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
You've already supplied select(), hence your version is used.

As your fictious programmer supplied a routine called select(), and linked
it ahead of the libraries, his select() would be used instead of any
select defined in any library.  Although he didn't call select, one of the
library routines did, and got his instead of the one in libc.a.

This is all as it should be, and allows one to quietly overload routine
names in any library.  Note that if select() was multiply defined in
object files, a warning would be posted.

Now the ability to quietly override library routines is of somewhat
questionable utility, and violates the principle of least suprize;
although I have used this feature on occasion.  

I used it once to attach statistics collecting to fopen/fclose.  I
supplyed my fopen/fclose, which jot down statistics, then call
openf/closef.

Then I extracted the systems versions of fopen/fclose via "ar x libc.a"
and used emacs to change the names of the procedure definitions in the .o
from fopen/fclose to openf/closef. (being careful not to change calls to
fopen/fclose lurking in the library).

Then when I link, everything calls my fopen, which calls openf, from my
doctored .o's extracted from libc.a and the extra fopen definition (from
libc.a) is not used.

>b) guess where Sun screwed up ?  

Sorry.  Not Sun's mistake.  Program works as coded.  

Sun (and every other Unix vedor) might want to change ld so that it issues
a warning message when a procedure supplied in a library is already
defined from some earlier object or library...

[[ That would be nice.  I have often been tempted to name a function
"wait" for whatever reason, and I'm sure that naive users have made
similar mistakes.  --wnl ]]

Michael McNamara 
  mac@ardent.com