How I can 'hide' a global variable in a shared library? Say, my library
contain a variable "char buf[256]" but also my application contain a global
variable with the same name "char buf[64]". When the program runs, I see
that buf in the shared library is replaced by buf in the application.

- Wong

Terminology gets awkward...hope this helps,
Chris

Very often, you will build libraries like this:

static sometype somevar = SOMEINITVALUE;

somelib_open()
{
        somevar = SOMEREASONABLEVALUE;
        /* open files, comms and stuff */

somelib_foo()
{
#ifdef DEBUG
        if (somevar == SOMEINITVALE)
                somelib_print("Must call somelib_init() first");
#endif
        /* foo away */

somelib_close()
{
        /* close files, comms and stuff */

  But it doesn't work if the shared library composed of mulitple C files.
One file declare buf as static can't be seen by the others..

- Wong

news:3B171A56.F046A512@acm.org...
: Perhaps what you want to do is make the variable a 'static' in your
: library.
:
: Terminology gets awkward...hope this helps,
: Chris
:
: Wong Ka Chun wrote:
: >
: > Hi,
: >
: >   How I can 'hide' a global variable in a shared library? Say, my
library
: > contain a variable "char buf[256]" but also my application contain a
global
: > variable with the same name "char buf[64]". When the program runs, I see
: > that buf in the shared library is replaced by buf in the application.
: >
: > - Wong

The only way to do this is to pick a name that is not likely to be
repeated. There's nothing else that can possibly work - if it's true that
you want to have two global variables (one in the library and one in the
program).

Look at it this way... 'static' isn't going to help because the user of
the library may wish to have a static variable of the same name. BINGO!
problem.

You might want to try *not* to have global variables - but if you've gone
down that path and are convinced that you must have them, then you need
to work very hard at naming the variable something that is not very
likely to get repeated.

For example, what I often use is simple namespace prefixing... If I have
a library I usually name it because it stands alone as a project. Say my
library was GTK or GLib or PointLib or whatever... then simply make sure
that you document that your library uses 'gtk' or 'glib' or 'plib' as the
prefix to all functions, classes, variables, etc. Then you've told the
user of your library that he mustn't use any names starting like that and
you're safe.

So, the only way to *ensure* that you have no problems is to use a
careful naming scheme.

                        Thanks,
                          Bob   (bobbe...@mediaone.net)
                        The Man from S.P.U.D.
                        We will write no code before it's designed.  

Actually, this isn't a problem.  However the comments about a static
symbol being utilize by other modules can be a problem.  As mentioned
below, namespaces are good ideas, but of course, we're really implying
a variable of a different name when that is done (at the symbol
table level anyway).  As this message says... careful naming is
the best thing to do in a design to avoid collision.

So, accessing the library will have the effect of increasing the size of
char buf[].

The only way to find out is to try it, and if it works, tell the whole
world not to do it :-)

Atle

  So, it means that global variables in shared library are indeed visible
to application. But it is not possible for one to assign a name which may
not clash with someone else application. In Win32, global variable in DLL
is not visible to application unless you explicity put it to a shared
memory region. Why this is not done similar under Linux?

- Wong

(Actually, visibility to the application has nothing to do with shared
memory; this is just a matter of whether the symbol is exported using
a .DEF file or a declspec(dllexport) statement ...)

The whole concept of shared libraries on Linux (and other Unixes) is that
a shared library behaves exactly the same as a statically linked library,
only with different performance characteristics (i.e. it's somewhat slower
when used only once, but saves a lot of memory when lots of applications
use the library at the same time).

The toolchain actually goes through a number of contortions to implement
this behaviour; it's really not trivial (e.g. the initial values of
variables defined in the library but used in the application are copied
to the .dynbss slots; for function pointer comparisons everybody uses
the address of the PLT slot for the function in the main application,
not the address of the function itself; etc.).  But while the internals
are complex, the user-visible behaviour is easy to describe: just the
same as statically linking.

In Windows, on the other hand, DLLs have a quite different user-visible
behaviour that statically linked libraries.  This makes them easier to
implement, however the user has to be aware of the fact that it's not
a static library (i.e. writing .DEF files and/or using dllexport/
dllimport, possibly fiddling around with ordinals, etc.).

On the one hand, this behaviour has disadvantages compared to the Unix
model: you have two quite different user-visible models of linking to
consider.  On the other hand, this makes it possible to use DLLs for a
second purpose at the same time: not just to solve performance problems
by avoiding multiple copies of the same library loaded into memory, but
also to provide for name space encapsulation.

If you want to do this sort of name space encapsulation on Unix, you have
to use some other mechanism -- shared libraries won't do it for you.
However, if you use something else, that will work also when when you
are statically linking ...   As the C language doesn't provide for name
spaces, the traditional method has always been to just use a common name
prefix for every module:  if you are implementing the 'foo' module,
every global variable or function should have a name that starts with
foo_.  If you choose 'foo' distinctive enough, that will work for all
practical purposes ...

B.t.w. nowadays Unix toolchains (including the GNU toolchain used on Linux)
have introduced various additions to the simple model described above.
With the GNU linker, it is in fact now possible to decide on a symbol-
by-symbol basis which global symbols should be visible outside a shared
library and which ones not.

To do so, you'll need to create a 'version script' which looks like:

VERSION_TAG {
  global:
     foo;
  local:
     bar;

where you list under 'global' those names that should be visible outside
and under 'local' those that shouldn't; you can use wildcards.  You then
specify the version script as argument to the link process. Check out the
ld info pages ('VERSION command') for more details.

Note that this is not portable; other linkers on other Unix platforms
may offer similar features, but the syntax will be completely different ...

--
  Dr. Ulrich Weigand
  weig...@informatik.uni-erlangen.de

Dude, you have no clue. Shared libraries have capabilities that can run circles
around DLL's.

Sure they will. Create a symbolic shared library with -Bsymbolic.
This causes the linker to resolve the library's references to its own
internal symbols, so that its own references won't be overriden at dynamic
link time. So suppose you have an executable with the external
function foo(), and two symbolic libraries each with their own foo().
The three foo's will not interfere with each other in any way;
every object will call its foo().

As a nice side effect, when you link a symbolic library, unresolved references
are errors, just like when you build a Windows DLL.

To restrict the visibility of the identifiers within your library,
use a version script, exactly as you mention later in your article.

I ported a COM object to Linux this way. The symbolic library exported only
DllMain, DllCanUnloadNow, and DllGetClassObject.  I wrote a COM loader which
supports the functions CoGetClassObject, CoInitializeEx and CoUninitialize.
Also a registry layer based over text files, so that the location of the COM
``DLL'' could be fetched by class ID and all that crap.

This COM object used a lot of the same C++ libraries as the executable
loading it, without interference.

It just seems worth pointing out that while this is not portable, neither are
the M$ language extensions used when dealing with their shared libraries.

-- Jim

James Cownie    <jcow...@etnus.com>
Etnus, LLC.     +44 117 9071438
http://www.etnus.com

This may be easier if you state excactly what it is you want to achieve.
If you want to exploit side-effects from the dynamic loading of
functions from a DLL, there may be a better way to obtain the same
result.
Please give a small example of the Win32 code with a short description
of what part is relevant.

This will make it easier to understand what you try to do, and probably
'filter' away the kind of responses you are not interested in.

Atle