Re: [AOLSERVER] Static vs. shared libraries?
On Thu, Oct 25, 2001 at 06:55:50PM -0500, Rob Mayoff wrote: On Linux, you should be able to extract all the .o files from the .a and combine them into a .so. Rob, how would I do that? Can you point me to any info? -- Andrew Piskorski [EMAIL PROTECTED] http://www.piskorski.com
Re: [AOLSERVER] Static vs. shared libraries?
ar -x blah.a On Thu, Oct 25, 2001 at 06:55:50PM -0500, Rob Mayoff wrote: On Linux, you should be able to extract all the .o files from the .a and combine them into a .so. Rob, how would I do that? Can you point me to any info? -- Andrew Piskorski [EMAIL PROTECTED] http://www.piskorski.com
Re: [AOLSERVER] Static vs. shared libraries?
+-- On Oct 26, Jim Wilcoxson said: ar -x blah.a Followed by ld -shared -nostartfiles -o blah.so *.o (If you're using GNU ld, anyway.)
Re: [AOLSERVER] Static vs. shared libraries?
On Thu, Oct 25, 2001 at 09:46:06PM -0400, Dossy wrote: On 2001.10.25, Andrew Piskorski [EMAIL PROTECTED] wrote: Unfortunately, the vendor of this closed-source API ships only the non-shared libfoo.a version of their library - they don't ship a libfoo.so. So, just make a libfoo.so that only consists of libfoo.a linked in. gcc -shared -o libfoo.so -L/path/to/libfoo.a -lfoo Shouldn't this work? Ah, I didn't know you could do that - thanks! But, when I try it, I'm running into problems I don't understand. I tried it a couple different ways: 1. Putting everything from libfoo.a and myfoo.c into a single myfoo.so library: $ gcc -shared -I../aolserver/include -g -fPIC -o myfoo.so myfoo.c /home/foo/lib/libfoo.a This fails to create myfoo.so, and spits out a single gigantic error messge: Text relocation remains referenced against symbol offset in file unknown 0x33a4 /home/foo/lib/libfoo.a(fooclient.o) malloc 0x30/home/foo/lib/libfoo.a(fooarg.o) malloc 0x2868 /home/foo/lib/libfoo.a(fooarg.o) PQueDumpN 0x830 /home/foo/lib/libfoo.a(foopque.o) [ ... 12000 or so more lines of stuff ] ld: fatal: relocations remain against allocatable but non-writable sections collect2: ld returned 1 exit status Is this the dreaded non-position-independent code problem?? 2. Taking the vendor's libfoo.a, compiling that to libfoo.so, only, and then create my own separate myfoo.so library. $ gcc -shared -fPIC -o libfoo.so /home/foo/lib/libfoo.a I'd SWEAR that this was giving me the same relocations remain against allocatable error as above, but when I do it again now, libfoo.so is successfully created, but there's really nothing in it - the file is only 4 kb long, and strings libfoo.so gives no output. 3. Ok, some searching on the web led me to try the -mimpure-text switch with the put everything into a single myfoo.so library from step 1.: $ gcc -shared -fPIC -mimpure-text -I../aolserver/include -g -o myfoo.so myfoo.c /home/foo/lib/libfoo.a That seems to work, but oddly, compare strings myfoo.so and strings libfoo.a, myfoo.so seems to be missing some stuff - they look like the names of functions - that libfoo.a has. Could be a red herring, I dunno. Then when I try to start up AOLserver, I get: [-main-] Warning: modload: failed to load '/web/aol3/bin/foo.so': 'ld.so.1: /web/aol3-src/aolserver/nsd/nsd8x: fatal: relocation error: file /web/aol3/bin/foo.so: symbol RegSetValueEx: referenced symbol not found' By running strings, I see that that symbol RegSetValueEx is in libfoo.a but NOT in myfoo.so. So I think it isn't linking correctly this way either. I am clueless on what to try next, so any advice would be greatly appreciated... -- Andrew Piskorski [EMAIL PROTECTED] http://www.piskorski.com
Re: [AOLSERVER] Static vs. shared libraries?
Ah, outstanding! By doing: $ ar -x libfoo.a $ ld -d y -G -o libfoo.so *.o -L/home/foo/lib -lblah1 -lblah2 $ gcc -shared -fPIC -I../aolserver/include -g -Wall -o myfoo.so myfoo.c /home/foo/lib/libfoo.so I was able to take apart the vendor's .a file, put it back together as a libfoo.so, and then compile my own loadable module which successfully cales libfoo.so. I don't why this method works when the others did not, but, it works! I didn't have the GNU linker so I used the Solaris one, and I had to give it the -G option (In dynamic mode only, produces a shared object. Undefined symbols are allowed.) or it would die because standard C library symbols like atoi where undefined. Rob, why did you want to use -nostartfiles ? On Fri, Oct 26, 2001 at 10:52:26AM -0500, Rob Mayoff wrote: +-- On Oct 26, Jim Wilcoxson said: ar -x blah.a Followed by ld -shared -nostartfiles -o blah.so *.o (If you're using GNU ld, anyway.) -- Andrew Piskorski [EMAIL PROTECTED] http://www.piskorski.com
Re: [AOLSERVER] Static vs. shared libraries?
+-- On Oct 26, Andrew Piskorski said: Rob, why did you want to use -nostartfiles ? Because AOLserver uses that on Linux. See LDSO in Makefile.global.
[AOLSERVER] Static vs. shared libraries?
I have a newbie's C module development question: I have a closed-source C API that I want to use from AOLserver. Ok, no problem, creating a myfoo.so AOLserver loadable module to do that should be straightforward. Unfortunately, the vendor of this closed-source API ships only the non-shared libfoo.a version of their library - they don't ship a libfoo.so. Now, I should be able to just re-compile all of AOLServer with libfoo.a linked in, right? I think the place to do that is in aolserver/nsd/Makefile, but I'm still a bit vague on basics like that... Are there any particular examples of static linking in the AOLserver code that I should look at? Also, I'm thinking that if I link libfoo.a statically into my nsd8x binary, I can still create myfoo.so as a loadable module - there's no reason I need to also link it statically, right? Finally, it would be nice to avoid having to statically link libfoo.a into nsd8x in the first place. Is it somehow possible to link libfoo.a into my myfoo.so, rather than nsd8x? I don't think so, but I'm not really sure. Thanks for any advice! -- Andrew Piskorski [EMAIL PROTECTED] http://www.piskorski.com
Re: [AOLSERVER] Static vs. shared libraries?
I think you can just say ld -o blah.so -shared blah.a without extracting .o files. The tricky part is going to be ensuring that the files were compiled with the -D_REENTRANT flag on Linux. Otherwise, the code won't work in weird cases (like referencing errno). Jim On Linux, you should be able to extract all the .o files from the .a and combine them into a .so. +-- On Oct 25, Andrew Piskorski said: Also, I'm thinking that if I link libfoo.a statically into my nsd8x binary, I can still create myfoo.so as a loadable module - there's no reason I need to also link it statically, right?
Re: [AOLSERVER] Static vs. shared libraries?
On Thu, Oct 25, 2001 at 05:10:45PM -0700, Jim Wilcoxson wrote: I think you can just say ld -o blah.so -shared blah.a without extracting .o files. The tricky part is going to be ensuring that the files were compiled with the -D_REENTRANT flag on Linux. Otherwise, the code won't work in weird cases (like referencing errno). I'm doing this on Solaris (SunOS 5.8). I have no idea whether the vendor's library was compiled with -D_REENTRANT - is there some way for me to check? -- Andrew Piskorski [EMAIL PROTECTED] http://www.piskorski.com
Re: [AOLSERVER] Static vs. shared libraries?
On 2001.10.25, Andrew Piskorski [EMAIL PROTECTED] wrote: Unfortunately, the vendor of this closed-source API ships only the non-shared libfoo.a version of their library - they don't ship a libfoo.so. So, just make a libfoo.so that only consists of libfoo.a linked in. gcc -shared -o libfoo.so -L/path/to/libfoo.a -lfoo Shouldn't this work? You'll need at least one .c file to implement the necessary functions for Tcl's load proc, I think. Whatever the case, I'd still avoid statically linking in libfoo.a directly to your nsd binary, though. -- Dossy -- Dossy Shiobara mail: [EMAIL PROTECTED] Panoptic Computer Network web: http://www.panoptic.com/ He realized the fastest way to change is to laugh at your own folly -- then you can let go and quickly move on. (p. 70)