buck@shell.UUCP (Lester Buck) (08/02/85)
I have a private library of C routines which I want to link into various
programs. The loader ld(1) *insists* on searching only /lib/lib*.a,
/usr/lib/lib*.a, /usr/local/lib/lib*.a and then gives up.
Ok, what am I missing? Our local superuser generated a link from
/usr/local/lib/... to the private library I want to search, but
he couldn't see any other way short of hacking ld(1).
Does your garden variety system allow users to write into
/usr/local/lib, or are ordinary mortals not supposed to develop programs?
Is there some kind of user-mode loader out there somewhere?
A. Lester Buck @ Shell Development Co.
{ihnp4, pur-ee, ut-sally}!shell!buckchris@umcp-cs.UUCP (Chris Torek) (08/03/85)
Try, e.g., $ cc -O -c file1.c $ cc -O -c file2.c $ ar cr mylib.a file[12].o $ ranlib mylib.a # BSD systems $ cc -O -c t.c $ cc -o t t.o mylib.a # link with mylib.a -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 4251) UUCP: seismo!umcp-cs!chris CSNet: chris@umcp-cs ARPA: chris@maryland
gwyn@brl-tgr.ARPA (Doug Gwyn <gwyn>) (08/04/85)
Some versions of "ld" support the "-Llibpath" option to specify an additional directory to search for libraries. You can always just name the library in the "ld" or "cc" command: cc -o myprog myprog.o mysub.o mylib.a -lm -lplot
rfb@cmu-cs-h.ARPA (Rick Busdiecker) (08/08/85)
> Some versions of "ld" support the "-Llibpath" option to specify an > additional directory to search for libraries. > > You can always just name the library in the "ld" or "cc" command: > cc -o myprog myprog.o mysub.o mylib.a -lm -lplot I was under the impression that libraries specified in the way that mylib.a is have the entire library linked in rather than just those routines which are needed because of undefined identifiers. Does anyone know if this is actually the case? Rick Busdiecker rfb@cmu-cs-h.arpa
ark@alice.UUCP (Andrew Koenig) (08/09/85)
>> Some versions of "ld" support the "-Llibpath" option to specify an >> additional directory to search for libraries. >> >> You can always just name the library in the "ld" or "cc" command: >> cc -o myprog myprog.o mysub.o mylib.a -lm -lplot > I was under the impression that libraries specified in the way that mylib.a > is have the entire library linked in rather than just those routines which > are needed because of undefined identifiers. Does anyone know if this is > actually the case? > Rick Busdiecker > rfb@cmu-cs-h.arpa It is not actually the case. When you name a library as an argument to ld, it picks out only the components it needs.
peter@kitty.UUCP (Peter DaSilva) (08/09/85)
> I was under the impression that libraries specified in the way that mylib.a > is have the entire library linked in rather than just those routines which > are needed because of undefined identifiers. Does anyone know if this is > actually the case? Not if the library is built right. (speakin in terms of the pdp-11 linker) Only those object files containing symbols that have been referenced by the main program or other modules get loaded. Of course with enough cross references the whole thing CAN get pulled in. There is no difference thet I know of in the way mylib.a and /usr/lib/foolib.a are treated.
guy@sun.uucp (Guy Harris) (08/10/85)
> > Some versions of "ld" support the "-Llibpath" option to specify an > > additional directory to search for libraries. > > > > You can always just name the library in the "ld" or "cc" command: > > cc -o myprog myprog.o mysub.o mylib.a -lm -lplot > > I was under the impression that libraries specified in the way that mylib.a > is have the entire library linked in rather than just those routines which > are needed because of undefined identifiers. Does anyone know if this is > actually the case? It is absolutely not the case. "ld" distinguishes object files from libraries by their contents (to be specific, by the header that archive files such as libraries have), not by the syntax used to specify them. Guy Harris
dave@lsuc.UUCP (David Sherman) (08/12/85)
In article <240@cmu-cs-h.ARPA> rfb@cmu-cs-h.ARPA (Rick Busdiecker) writes: >> You can always just name the library in the "ld" or "cc" command: >> cc -o myprog myprog.o mysub.o mylib.a -lm -lplot > >I was under the impression that libraries specified in the way that mylib.a >is have the entire library linked in rather than just those routines which >are needed because of undefined identifiers. Does anyone know if this is >actually the case? No, it's not the case. What you're probably thinking of is what happens with "mysub.o" in the above example. All routines in mysub.o will indeed get linked into your binary; the files in mylib.a will only be taken as needed. Of course, once you take any .o file (whether on the command line or from a .a archive), you get ALL the routines in that file whether you want them or not. Dave Sherman The Law Society of Upper Canada Toronto -- { ihnp4!utzoo pesnta utcs hcr decvax!utcsri } !lsuc!dave
psc@lzwi.UUCP (Paul S. R. Chisholm) (08/13/85)
In article <125@shell.UUCP>, buck@shell.UUCP (Lester Buck) writes: > I have a private library of C routines which I want to link into various > programs. The loader ld(1) *insists* on searching only /lib/lib*.a, > /usr/lib/lib*.a, /usr/local/lib/lib*.a and then gives up. > > Ok, what am I missing? Well, in System V ld(1) has a -L option, followed by the name of a directory to be searched before /lib and /usr/lib. Usage cc -c foo.c && ld -o foo -L/usr/jrandom/lib -lglarch -lc or cc -o foo foo.c -Wl,-L/usr/jrandom/lib -lglarch (-Wl can be used to pass arguments to the linker from cc(1); there were so many options to each, cc could no longer just assume all linker commands were unrecognized and vice versa, and don't flame at me for it!) Note for Unix history buffs: this feature wasn't in System III, so it's quite recent. -Paul S. R. Chisholm The above opinions are my own, {pegasus,vax135}!lzwi!psc not necessarily those of any {mtgzz,ihnp4}!lznv!psc telecommunications company. (*sigh* ihnp4!lzwi!psc does *NOT* work!!! Use above paths.) "Of *course* it's the murder weapon. Who would frame someone with a fake?"
feldman@ccvaxa.UUCP (08/14/85)
[] >> Some versions of "ld" support the "-Llibpath" option to specify an >> additional directory to search for libraries. >> >> You can always just name the library in the "ld" or "cc" command: >> cc -o myprog myprog.o mysub.o mylib.a -lm -lplot > I was under the impression that libraries specified in the way that mylib.a > is have the entire library linked in rather than just those routines which > are needed because of undefined identifiers. Does anyone know if this is > actually the case? File arguments to BSD derived versions of ld are examined for a "magic number"; if the file is an a.out file, it is loaded. If it is a ar archive file things are more complicated. In general, the ar file has been ranlib'ed since it was last ar'ed. In this case, only what is needed gets loaded. Otherwise, ld complains about the library being out of date or not having been ranlib'ed and makes a single pass through the library, which often leaves undefineds. Ld pays no attention to filename suffixes, so for example, -lg (/usr/lib/libg.a) is really a .o file and gets loaded no matter what. Ld will also use the size of a common symbol (undefined external with non-zero value) from a library member WITHOUT loading library member if that member resolves no other undefined references. This can cause the resulting a.out file to be unexpectedly big. I'm waiting to see if this is fixed in 4.3. Mike Feldman Gould Computer Systems Urbana, IL {ihnp4|pur-ee}!uiucdcs!ccvaxa!feldman
feldman@ccvaxa.UUCP (08/14/85)
[] >> Some versions of "ld" support the "-Llibpath" option to specify an >> additional directory to search for libraries. >> >> You can always just name the library in the "ld" or "cc" command: >> cc -o myprog myprog.o mysub.o mylib.a -lm -lplot > > I was under the impression that libraries specified in the way that mylib.a > is have the entire library linked in rather than just those routines which > are needed because of undefined identifiers. Does anyone know if this is > actually the case? File arguments to BSD derived versions of ld are examined for a "magic number"; if the file is an a.out file, it is loaded. If it is a ar archive file things are more complicated. In general, the ar file has been ranlib'ed since it was last ar'ed. In this case, only what is needed gets loaded. Otherwise, ld complains about the library being out of date or not having been ranlib'ed and makes a single pass through the library, which often leaves undefineds. Ld pays no attention to filename suffixes, so for example, -lg (/usr/lib/libg.a) is really a .o file and gets loaded no matter what. Explicitly named libraries are treated the same as -l arguments except in the way they are located (/lib, /usr/lib, /usr/local/lib, -Lpath(?)). If a -l option turns out to be an a.out file, ld uses the argument, not the expanded pathname, as the filename symbol. For example, -lg results in the a local symbol "-lg" appearing in the output symbol table. Ld will also use the size of a common symbol (undefined external with non-zero value) from a library member WITHOUT loading library member if that member resolves no other undefined references. This can cause the resulting a.out file to be unexpectedly big. I'm waiting to see if this is fixed in 4.3. Mike Feldman Gould Computer Systems Urbana, IL {ihnp4|pur-ee}!uiucdcs!ccvaxa!feldman /* End of text from ccvaxa:net.unix */
mike@whuxl.UUCP (BALDWIN) (08/15/85)
> Well, in System V ld(1) has a -L option, followed by the name of a > directory to be searched before /lib and /usr/lib. Usage > cc -c foo.c && ld -o foo -L/usr/jrandom/lib -lglarch -lc > or > cc -o foo foo.c -Wl,-L/usr/jrandom/lib -lglarch > (-Wl can be used to pass arguments to the linker from cc(1); there > were so many options to each, cc could no longer just assume > all linker commands were unrecognized and vice versa, and don't > flame at me for it!) On SVR2 you can use -L on the cc command line without -Wl, e.g.: cc -o foo foo.c -L/usr/jrandom/lib -lglarch -- Michael Baldwin AT&T Bell Labs harpo!whuxl!mike
mouse@mcgill-vision.UUCP (der Mouse) (08/15/85)
>> You can always just name the library in the "ld" or "cc" command: >> cc -o myprog myprog.o mysub.o mylib.a -lm -lplot > >I was under the impression that libraries specified in the way that mylib.a >is have the entire library linked in rather than just those routines which >are needed because of undefined identifiers. Does anyone know if this is >actually the case? I had occasion to play with the loader a while ago. Under 4.2bsd at least, this is not the case. Naming an archive in full is exactly the same as using a -l option which refers to the same archive. -- der Mouse System hacker and general troublemaker CVaRL, McGill University Hacker: One responsible for destroying / Wizard: One responsible for recovering it afterward