Re: C Linker/Compiler question

>> Is there a way to generate a library (with gcc, kcc or anything) that
>> includes another library AND DOES some linking tasks by filling the
>> wholes in the intermediate files (.o) we're including in the library
>> we're trying to build with the code found in the library we're also
>> including in that library we're trying to build.
>>
>> The goal is to not use another version of the same symbols when
>> linking to an executable.


> Unfortunately, I'm not sure I completely understand your question.
> If, however, the situation is as follows:
> ------- --------
> | app |-------------->| lib1 |
> ------- --------
> | |
> |--> symbol "a" |---> a different symbol "a" (from lib2)
> =


> Where lib1 is a shared object, you can do it by:
> 1) linking lib2 into lib1 statically _and_ symbolically
> 2) using a version script to decide what gets exported from lib1


> I suggest you look at the info pages for ld for further information.
> A different approach would be to develop wrapper code around the
> functions you're interested in and use partial linking to create a
> "library-like" .o file.


> If you restate your problem a little more clearly, I (or someone else)
> might be able to give you further help.


> BTW -- I have needed to use a slew of similar mechanisms for a project
> I've been working on (for far too long)...


Hi ! Thank you for your answer. The real goal is to put myself between
an application and a library. One solution I thought of, as a first
approch, is :




                                                    -----------
                                --------->| my_lib1 |
                                | -----------
------- | |
| app |---------- |--> defines symbol a() that calls my_a()
------- | =


    | | -----------
    | --------->| my_lib2 |
    | | -----------
    | | |
    | | |--> defines symbol my_a() that calls a()
    | | ** would like to call the one in real_lib !! **
    | |
    | | ------------
    | --------->| real_lib |
    | ------------
    | |
    | |--> real definition of a()
    |
    |--> symbol a() from my_lib1


The problem is that NO link related job is done when the libraries are
constructed. Therefore when all this code is really linked in app,
only the first definition of a() is used. What I would like to do is
to construct my_lib2 so that the call to a() is resolved right away to
the address in real_lib. Is it reasonable ? Is "partial linking" the
solution ? Is it safe to use ld when the objects files had been
constructed with another tool, say KCC or anything other ?


Notice that there might be one superfluous library in this scheme.
my_lib2 could probably be replaced by a "special" object file where
the symbol "a()" had been resolved once and for all to the one in
real_lib. But the problem is the same.


One solution would be to use dynamic linking. my_a() would explicitly
ask the runtime dynamic linker the address of a() in real_lib and call
it. This will probably work. But what if I real_lib only comes as a
static library ?


Thank you


Francis Girard
frgirard@globetrotter.net
Rimouski, Qu=E9bec, Canada
[This is a problem that few linkers solve well. The most common workaround
is to give library routines long ugly names that are unlikely to collide
with names in user applications. -John]

Return to the comp.compilers page.
Search the comp.compilers archives again.