From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Stuart Summerville (Deimus)" To: Subject: Re: Need help building & integrating library into target Date: Sat, 11 Dec 1999 02:24:00 -0000 Message-id: <003001bf43c1$ec6c68a0$bafc2bcb@deimus.com.au> X-SW-Source: 1999-12/msg00164.html >It would be best to show us how you're trying to link against the >library; knowing your platform would also be helpful. >--ag > Hi Arthur, Given that I have mylib.a in the current directory, I issue the command: gcc -static -g -o rw startup_lib.a to produce the rw executable. Then, issuing the command: ldd rw tells me that this dynamically linked executable is dependent on mylib.o. I presume that as its linked statically, there shouldn't be any lib dependence.... Tools used: Solaris 2.5.1 gcc egcs-2.91.57 19980901 (egcs-1.1 release) ld 2.8.1 (with BFD 2.8.1) Also, mylib.a was created in the following manner: gcc -MD -I../include -g -o init.o -c init.c ar rv ../../../obj/mylib.a *.o I've seen the same behaviour on two Sol251 boxes. To contrast this, if I do the same thing on a Redhat Linux (5.2) box (gcc = 2.7.2.3, ld = 2.9.1 (with BFD 2.9.1.0.15)), it works fine. If statically linked, ldd won't touch it (unlike the Solaris box, which still shows that erroneous dependence) & it runs properly; if dynamically linked, ldd reports that libc and ld-linux are linked but no mylib.a (or even mylib.o). ? Some other questions: 1) does linking of libraries dynamically only affect files specified with the -l switch to ld? Can a file specified as an ordinary object file to ld, be dynamically linked in? eg. if I don't supply ld with the -static switch, will archive files passed in the manner "ld -o myprog mylib.a ..." be statically linked anyway? 2) Is there any use in my creating arcive/object files with the -shared switch to ld? This seems to be a useful thing to do, but the ld manpage suggests its not a common method anymore. Thanks, sTu. ---------------------------------------------- Stuart Summerville Home: stus@deimus.com.au Work: stuart.summerville@icpdd.neca.nec.com.au ---------------------------------------------- From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Stuart Summerville (Deimus)" To: Subject: Re: Need help building & integrating library into target Date: Fri, 31 Dec 1999 22:24:00 -0000 Message-ID: <003001bf43c1$ec6c68a0$bafc2bcb@deimus.com.au> X-SW-Source: 1999-12n/msg00164.html Message-ID: <19991231222400.9LvNGu7AIFlNcuGIuQgYA5SIqDBcy0URs4JwSHrIrss@z> >It would be best to show us how you're trying to link against the >library; knowing your platform would also be helpful. >--ag > Hi Arthur, Given that I have mylib.a in the current directory, I issue the command: gcc -static -g -o rw startup_lib.a to produce the rw executable. Then, issuing the command: ldd rw tells me that this dynamically linked executable is dependent on mylib.o. I presume that as its linked statically, there shouldn't be any lib dependence.... Tools used: Solaris 2.5.1 gcc egcs-2.91.57 19980901 (egcs-1.1 release) ld 2.8.1 (with BFD 2.8.1) Also, mylib.a was created in the following manner: gcc -MD -I../include -g -o init.o -c init.c ar rv ../../../obj/mylib.a *.o I've seen the same behaviour on two Sol251 boxes. To contrast this, if I do the same thing on a Redhat Linux (5.2) box (gcc = 2.7.2.3, ld = 2.9.1 (with BFD 2.9.1.0.15)), it works fine. If statically linked, ldd won't touch it (unlike the Solaris box, which still shows that erroneous dependence) & it runs properly; if dynamically linked, ldd reports that libc and ld-linux are linked but no mylib.a (or even mylib.o). ? Some other questions: 1) does linking of libraries dynamically only affect files specified with the -l switch to ld? Can a file specified as an ordinary object file to ld, be dynamically linked in? eg. if I don't supply ld with the -static switch, will archive files passed in the manner "ld -o myprog mylib.a ..." be statically linked anyway? 2) Is there any use in my creating arcive/object files with the -shared switch to ld? This seems to be a useful thing to do, but the ld manpage suggests its not a common method anymore. Thanks, sTu. ---------------------------------------------- Stuart Summerville Home: stus@deimus.com.au Work: stuart.summerville@icpdd.neca.nec.com.au ----------------------------------------------