Path: utzoo!mnetor!uunet!lll-winken!lll-lcc!ames!elroy!cit-vax!cit-vlsi!wen-king From: wen-king@cit-vlsi.Caltech.Edu (Wen-King Su) Newsgroups: comp.unix.wizards Subject: Re: making a library breaks the code??? Message-ID: <5613@cit-vax.Caltech.Edu> Date: 1 Mar 88 19:31:47 GMT References: <4079@megaron.arizona.edu> Sender: news@cit-vax.Caltech.Edu Reply-To: wen-king@cit-vlsi.UUCP (Wen-King Su) Organization: California Institute of Technology Lines: 30 In article <4079@megaron.arizona.edu> lm@megaron.arizona.edu (Larry McVoy) writes: some C code in about 5 files. Normally I do things like this: < >$ cc application.c *.o ../lib/Tlib.a -o application < >Eventually "*.o" wil have to go into a library, so I tried this: < >$ ar cr stardoto.a `lorder *.o | tsort` <$ ranlib stardoto.a >$ cc application.c stardoto.a ../lib/Tlib.a -o application < >and the code breaks. Your description is not very specific. My guess is that some .o files in stardoto.a were not used by the loader when the loader is finished with it. In the first 'cc', you force the loader to use all the .o files; whereas, in the second 'cc', you let the loader pick only those .o files that are needed at the time. If the second 'cc' terminates with an error, then symbols in the .o files skipped by the loader are referenced by the other libraries following it (Tlib.a, for example). The loader will then complain because it could not find the symbol. The loader does not go back to rescan its list of library files. If the second 'cc' terminates without error, the .o files that were skipped contain symbols having the name as those found in the libraries that comes after stardoto.a. In that case, the wrong .o file will be used. Most compiler has a flag that tells you what is being loaded from which library. /*------------------------------------------------------------------------*\ | Wen-King Su wen-king@vlsi.caltech.edu Caltech Corp of Cosmic Engineers | \*------------------------------------------------------------------------*/