Thread View: comp.unix.programmer
3 messages
3 total messages
Started by lotx
Tue, 25 May 1999 00:00
linking multiple libraries
Author: lotx
Date: Tue, 25 May 1999 00:00
Date: Tue, 25 May 1999 00:00
27 lines
1828 bytes
1828 bytes
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. 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? Thanks. --== Sent via Deja.com http://www.deja.com/ ==-- ---Share what you know. Learn what you don't.---
Re: linking multiple libraries
Author: Kaz Kylheku
Date: Wed, 26 May 1999 00:00
Date: Wed, 26 May 1999 00:00
15 lines
1555 bytes
1555 bytes
On Tue, 25 May 1999 23:45:47 GMT, lotx@my-dejanews.com <lotx@my-dejanews.com> wrote: > 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? Yes. More precisely, the GNU linker is quite flexible when dealing with symbols. You can give it a list of global symbols to suppress when linking together an object such as a library. For more info, see the documentation or ask in some gnu newsgroup.
Re: linking multiple libraries
Author: David B Anderson
Date: Wed, 26 May 1999 00:00
Date: Wed, 26 May 1999 00:00
46 lines
2678 bytes
2678 bytes
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
Thread Navigation
This is a paginated view of messages in the thread with full content displayed inline.
Messages are displayed in chronological order, with the original post highlighted in green.
Use pagination controls to navigate through all messages in large threads.
Back to All Threads