🚀 go-pugleaf

In article <7ifcnb$mna$1@nnrp1.deja.com>,  <lotx@my-dejanews.com> wrote:
>Hi,
>
>   I am writing an application for which I want to link two very
>similar libraries.  By similar, I mean that both libraries have a lot
>of global variables and functions that have the same name. In fact, the
>only difference between both libraries would be the access functions to
>be called outside the library.  My problem is that the gcc linker will
>not allow multiple instances of function names and global variables
>even if these functions and variables are local to the library.

You may think the names are local, but that is a misunderstanding
on your part. Hard to know for sure since you don't
supply a small complete example.

>   BTW, in M$-Window$, it is possible to solve my dilemma by using
>dynamically linking instead of static linking of libraries.  The WIN32
>API provides functions such as LoadLibrary() and GetProcAddress() to
>call explicit functions at run time.  This would allow me to use
>distinct DLLs that have the same name for a global variable.
>
>   Is there a switch or an option in gcc that gives me this capability?

dlopen() and dlsym() do in Linux (and many other UN*X systems)
what I would guess LoadLibrary() and GetProcAddress() do in
WIN32 (I know nothing about WIN32...)

In Linux, dynamic linking of libraries is the norm
and is  different thing from using dlopen() and dlsym().


a) dynamic executable: linked against shared libraries
   Normal to use dlopen(), though most such executables don't. 
   Not necessary to use dlopen. Functions are found by name
   (well, not C 'static' functions, but external functions are).

b) static executable: linked against archives, not shared libraries

   static executable using dlopen(), dlsym().
   Even a static executable
   is supposed to be able to do dlsym() in linux.
   (having a static executable do dlopen() is not
    very portable, some UNIX systems don't support that).

Hope this makes sense.
davea@sgi.com