Re: -Bsymbolic for exactly one symbol.

Basically, you want to have classes in a shared library and in a
program that are really different, but just share a name.


It's extremely difficult to do this in a portable way in the way that
you are attempting to do it, but there's a simple answer, of course,
for C++: *use namespaces*.


Even if you don't have control over one of them (say, the shared
library, or the program), you can certainly put the other one inside a
unique namespace.


It's especially vital to do this for shared libraries, which can be used
in a variety of applications, where you can't depend on someone not
whomping over your naming convention and accidentally reusing one of
"your" names.


Roman Shaposhnick wrote:


> Hi, All!
>
> While building a shared library I've encountered the following problem:
>
> $cat shared1.cc
>
> struct A {
> A();
> };
>
> A a;
>
> $ cat shared2.cc
>
>
> #include <stdio.h>
>
> struct A {
> A();
> };
>
> A::A() {
> printf("Constructor from shared2.cc\n");
> }
>
> $ cat main.cc
>
> #include <dlfcn.h>
> #include <stdio.h>
>
> struct A {
> A();
> };
>
> A::A() {
> printf("Constructor from main.cc\n");
> }
>
> void main() {
> void* h;
> h = dlopen("./shared.so", RTLD_LAZY);
>
> dlclose(h);
> }
>
>
> $ CC -c shared1.cc shared2.cc
> $ CC -G -o shared.so shared1.o shared2.o
> $ CC main.cc -ldl
> $ ./a.out
> Constructor from main.cc
>
> Of course the problem is related to the fact, that references to UNDEF symbols
> in shared objects are not bound at a link phase, but instead they are being
> resolved by a dynamic linker. One option is to use -Bsymbolic when linking
> shared.so, but it will *resolve* all references to a local symbols from
> that shared.so, which is not desirable, since it won't let me override them
> later on.
>
> So my question is: how can I force linker to resolve just one reference
> to the particular symbol ( A::A() from the shared2.cc in my example ).
>
> Thanks,
> Roman.
> [I think my advice would be "don't do that". If you really, really, need
> to, you could use dlsym() to find the address in the loaded module and
> then patch it into A's vtbl. -John]

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