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.
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)
