nieusma@eclipse.colorado.edu (Jeff Nieusma) (11/16/90)
I was under the impression that the .sa file was supposed to hold the global data structures... Since Sun's documentation on shared libraries is minimal at best, can someone tell me where my logic is off? I understand that libc.so has some data segment symbols in it that are primarily read-only, but what about things that aren't read only? I am building a libc.s[oa] with the 4.8.2 resolver and have run into a small problem. The resolver has a shared struct state _res that is declared extern in resolv.h . Since I can write to this structure, (eg. turn on debugging) and I don't want *my* version of this structure shared over the whole system, I assume that this structure should go in the .sa file. ( it is for the "local" globals, isn't it? ) I put the _res stucture in the .sa file by compiling a file with only the declaration in it and then ar r 'ing it and ranlib... And when I compiled my libc.so with no actual definition of the struct anywhere, the library wouldn't work. It kept giving me errors about no _res symbol... So I put the struct definition back into res_init.c and recompiled. This library works fine. Right now I am running with the _res stucture defined in both libc.so and libc.sa. Is this the correct way to do things? Will the .sa version be mapped into my address space if I modify the _res stucture? If I am doing things right, then does that mean the way Sun is advertising to build libc.so with the resolver routines is making libc.so "unshareable"? Since Sun's method doesn't put the _res structure into libc.sa, then when/if I modify the _res structure (like turning on debugging for the resolver) then am I no longer using a shared version of libc.so? I am really confused here. Can someone shed some light on the subject? Jeff Nieusma Logical: nieusma@boulder.colorado.edu