From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28094 invoked by alias); 29 Jan 2010 07:52:47 -0000 Received: (qmail 28055 invoked by uid 48); 29 Jan 2010 07:52:38 -0000 Date: Fri, 29 Jan 2010 07:52:00 -0000 Message-ID: <20100129075238.28054.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug libstdc++/42679] RTLD_DEEPBIND dlopen option for shared library that uses libstdc++ std::ostream crashes In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "jakub at gcc dot gnu dot org" Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2010-01/txt/msg03283.txt.bz2 ------- Comment #14 from jakub at gcc dot gnu dot org 2010-01-29 07:52 ------- Clearly this works with icc, because library.so isn't linked against libstdc++.so. I guess if you link the library with gcc instead of g++, it will work too. Any reason why you need to use RTLD_DEEPBIND? AFAIK it has been mainly to support libraries linked against a different version of libstdc++ from the rest of the app (say the program and all its libraries linked against GCC 3.2/3.3 libstdc++, while some library it dlopens linked against GCC 3.4+ libstdc++. I'd say there is nothing that should be done on the libstdc++ side, this can happen with any kinds of symbols in any library. What can help is compile the program with -fpic/-fPIC, then it won't have copy relocation and thus this problem won't exist. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42679