-Bsymbolic for exactly one symbol.

vugluskr@unicorn.math.spbu.ru (Roman Shaposhnick)
8 Aug 2001 01:17:03 -0400

          From comp.compilers

Related articles
-Bsymbolic for exactly one symbol. vugluskr@unicorn.math.spbu.ru (2001-08-08)
Re: -Bsymbolic for exactly one symbol. jfc@mit.edu (2001-08-08)
Re: -Bsymbolic for exactly one symbol. ian@airs.com (Ian Lance Taylor) (2001-08-15)
Re: -Bsymbolic for exactly one symbol. shankarunni@earthlink.net (Shankar Unni) (2001-08-15)
| List of all articles for this month |

From: vugluskr@unicorn.math.spbu.ru (Roman Shaposhnick)
Newsgroups: comp.compilers
Date: 8 Aug 2001 01:17:03 -0400
Organization: St.Petersburg University
Keywords: linker, question, comment
Posted-Date: 08 Aug 2001 01:17:03 EDT

Hi, All!

While building a shared library I've encountered the following problem:

          $cat shared1.cc

          struct A {

          A a;

          $ cat shared2.cc

          #include <stdio.h>

          struct A {

          A::A() {
                printf("Constructor from shared2.cc\n");

          $ cat main.cc

          #include <dlfcn.h>
          #include <stdio.h>

          struct A {

          A::A() {
                printf("Constructor from main.cc\n");

          void main() {
                void* h;
                h = dlopen("./shared.so", RTLD_LAZY);


          $ 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 ).

[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]

Post a followup to this message

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