public inbox for gcc-help@gcc.gnu.org
 help / color / mirror / Atom feed
From: jhfrontz <jeff.frontz@gmail.com>
To: gcc-help@gcc.gnu.org
Subject: Re: risk of mixing libstdc++ versions in one executable
Date: Mon, 25 Aug 2008 19:33:00 -0000	[thread overview]
Message-ID: <19149862.post@talk.nabble.com> (raw)
In-Reply-To: <48AF4175.9030801@avtrex.com>



David Daney wrote:
> 
> jhfrontz wrote:
>> In reviewing the archives, I see admonitions to avoid using different
>> versions of libstdc++ in one binary (specifically libstcd++5 and
>> libstdc++6,
>> which results in the confusing-to-the-unsuspecting "/usr/bin/ld: warning:
>> libstdc++.so.5, needed by
>> some-undersupported-IRRATIONAL-INSTRUMENTS-third-party.so, may conflict
>> with
>> libstdc++.so.6" message).
>> 
>> But, really, what is the basis for the warning?
> 
> Well at the highest level, it is almost guaranteed not to work.  This is
> because the ABIs of libraries differs among other problems.
> 
>>  Is it that the binary may
>> in one place use an object created by one library version and then in
>> another place hand the object off to a member function in the other
>> library
>> version?
> 
> That is one problem you might find.
> 
>> 
>> If I have such a firewall, can I safely ignore the ominous warning from
>> ld?
>> 
> 
> If you test it and it works, I would say go ahead and ignore the warning. 
> But if it fails, don't say you were not warned.
> 
> David Daney
> 
> 

OK, thanks, but I'm not sure how to test it.  I mean, I can run the
resulting executable and it seems to behave well, but I'm not sure if that's
an appropriate/sufficient test.  Before I can design an appropriate test, I
need to understand the failure modes that I'm looking for.  What are the
failure modes for mixing the two libraries?  Will these failures only occur
in code that attempts to make use of a library for which it was not
compiled?

To put it another way-- someone had some idea of bad things to come when
they added the warning message; what are these bad things and what would
induce their appearance?

Also, it's not a flat-out error, so there must be conditions where mixing
the libraries is acceptable (or even appropriate)-- what are these
conditions?

Thanks,
Jeff

-- 
View this message in context: http://www.nabble.com/risk-of-mixing-libstdc%2B%2B-versions-in-one-executable-tp19116549p19149862.html
Sent from the gcc - Help mailing list archive at Nabble.com.

      reply	other threads:[~2008-08-25 19:18 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-08-22 22:34 jhfrontz
2008-08-22 23:57 ` David Daney
2008-08-25 19:33   ` jhfrontz [this message]

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=19149862.post@talk.nabble.com \
    --to=jeff.frontz@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).