Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!tut.cis.ohio-state.edu!zaphod.mps.ohio-state.edu!wuarchive!rice!rice!sun-spots-request
From: schoch@trident.arc.nasa.gov (Steve Schoch)
Newsgroups: comp.sys.sun
Subject: linking on SPARCstation 1+
Keywords: Miscellaneous
Message-ID: <1990Oct7.231236.3894@rice.edu>
Date: 7 Oct 90 21:30:00 GMT
Sender: sun-spots-request@rice.edu
Organization: Sun-Spots
Lines: 15
Approved: Sun-Spots@rice.edu
Originator: spots@walhalla.rice.edu
X-Sun-Spots-Digest: Volume 9, Issue 338, message 9

Given that an object file resides in a .so file and an archive, both
specified in an ld step with the .so file specified first, is there any
reason that ld would resolve a reference from the archive instead of the
.so shared object?

Is it a problem with the reference somehow not "global" and therefore not
seen by the loader?  The shared object is being create just like specified
in Chapter 1 - Shared Libraries in the Programming Utilities and Libraries
manual.

A "-M" on the ld step doesn't help much; it doesn't list the reason a
particular .so was pulled in.

dueker@xenon.arc.nasa.gov        |   Chris Dueker (The Code Slinger)
chris@chuck.arc.nasa.gov         |   Mtn. View, CA  (Sillycon Valley!)