Devin_E_Ben-Hur@cup.portal.com (03/29/89)
> I think that this discussion of external linkages has missed the point of > the original poster, although I could be missing the point too. > > If I read the original correctly, he is saying that given: > > MY.LIB <== A.OBJ entry points A1 A2 A3 externals C1 > B.OBJ entry points B1 B2 B3 > C.OBJ entry points C1 C2 C3 > Nope, the original poster made no mention of libraries. He wished the linker to treat: LINK A+B+C,P.EXE; as if all the functions in A,B,&C were independantly compiled then made into a library and linked only if referenced. > and given > > main () { a1(); a3(); } > > then the Turbo C linker will include ALL 3 modules in the resulting > executable, whereas it is plain that B.OBJ is not required. If this > is, in fact, the case, then the Turbo C linker is _broken_. The Microsoft > Linker will include only A.OBJ and C.OBJ in the executable. > The turbo linker will perform just link the uSoft linker for this. Even if it did include B.OBJ, it would not be _broken_ merely an inferior implementation. A broken linker produces an incorect program, including b.obj does not make the output incorrect, merely larger than neccessary. > Now, if A, B, and C are all modules on a single OBJ, and that OBJ is fed > to the linker, then one would expect all three to appear on the executable. > I don't think that was the question, however. > > Tim_CDC_Roberts@cup.portal.com | Control Data... > ...!sun!portal!cup.portal.com!tim_cdc_roberts | ...or it will control you. Devin_Ben-Hur@Cup.Portal.Com ...ucbvax!sun!portal!cup.portal.com!devin_ben-hur
dg@lakart.UUCP (David Goodenough) (04/14/89)
Guts of argument:
file1: proc1() { proc3(); }
file2: proc2() { }
file3: proc3() { }
N.B. file2 is not necessary to resolve inclusion of file1.
The question: Should inclusion of file2 on the command line cause
inclusion of the code for proc2, even though it is not needed to
resolve any undefined labels?
The answer: (IMHO) Yes.
There is a difference between object files (UNIX .o) and Libraries (UNIX .a)
ALL stuff in a .o should be included because it may be needed to resolve
a forward reference. When I write programs, I can produce just 14K of
object from 20 source files (OK I'm using Z80 assembler, but the principle
still holds true in any environment), and I have external references all
over hell's half acre. Now I don't want any damn linker trying to second
guess what I mean. As far as I know, the L80 linker ( father of the MS-DOS
mess????? ) had a /S option to search:
So if I said:
L80 FILE1,FILE2,FILE3/S .....
FILE1.REL and FILE2.REL would be linked in their entirity, needed or not,
but FILE3 would be searched, and only used to resolve current undefined
labels. The linker I use now (ZLINK) does it, but automatically, based on
the filename extension: .O for mandatory linkage, and .L for libraries.
Also the internal format of a .L file is a little different, but that's
another story.
--
dg@lakart.UUCP - David Goodenough +---+
IHS | +-+-+
....... !harvard!xait!lakart!dg +-+-+ |
AKA: dg%lakart.uucp@xait.xerox.com +---+