public inbox for gcc-help@gcc.gnu.org
 help / color / mirror / Atom feed
From: Arindam <arindam.mukerjee@gmail.com>
To: gcc-help@gcc.gnu.org
Subject: Restricting symbol binding within shared object
Date: Tue, 19 Aug 2008 16:12:00 -0000	[thread overview]
Message-ID: <d85a51ff0808190837n3a30ab98ld21257f1471f499d@mail.gmail.com> (raw)

Hi,

I am using a Linux 2.6 (SuSE 9) build machine with gcc 3.3.3 installed.

I have two shared libraries linked to an executable. The executable
calls two functions - say bar1() in one shared lib and bar2() in
another. It so happens that both bar1 and bar2 internally call a
function say foo(). There is a different version of foo defined in
each shared object with same signature but different internal
implementation. It so happens that when both shared libs are linked to
my executable, both bar1 and bar2's calls resolve to the foo defined
in shared object 1. I am trying to figure out a way to resolve each
call "locally" within the shared object. I tried the -Bsymbolic switch
for the linker but it did not work - perhaps because this is C++ code,
although the functions in question are declared with C linkage (extern
"C").

Please help!

- Arindam


PS: I tried a round-about way of restricting which symbols are
exported from each shared object - using a linker version script. I
hid the "foo" symbol from the shared objects and it worked the way I
wanted. However, this is not an acceptable or convenient solution.

-- 
-----------------
A. It messes the natural order in which we read.
Q. What's with it?
A. Top-Posting,
Q. What is the most annoying thing on emails and posts?

             reply	other threads:[~2008-08-19 15:37 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-08-19 16:12 Arindam [this message]
2008-08-19 16:58 ` special comments handling in the C compiler Tim Wang
2008-08-22  1:52   ` extern "C" From command line Seyran Avanesyan
2008-08-22  2:12     ` Brian Dessent
2008-08-23  1:38       ` Seyran Avanesyan
2008-08-23  2:37         ` Brian Dessent
2008-08-23  2:46           ` Seyran Avanesyan
2008-08-22  2:04   ` 64-bit gcc Seyran Avanesyan
2008-08-22 11:01     ` Brian Dessent
2008-08-22 20:09       ` Seyran Avanesyan
2008-08-22 22:32         ` Brian Dessent
2008-08-22 22:45           ` Seyran Avanesyan
2008-08-23  2:31             ` Brian Dessent
2008-08-23  2:45               ` NightStrike
2008-08-23  2:49               ` Seyran Avanesyan
2008-08-23  3:18                 ` Brian Dessent
2008-08-23  2:00         ` NightStrike
2008-08-23  2:13           ` Seyran Avanesyan
2008-08-19 18:49 ` Restricting symbol binding within shared object Ian Lance Taylor
2008-08-20 19:36   ` Arindam
2008-08-21  4:43     ` Ian Lance Taylor

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=d85a51ff0808190837n3a30ab98ld21257f1471f499d@mail.gmail.com \
    --to=arindam.mukerjee@gmail.com \
    --cc=gcc-help@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).