From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19229 invoked by alias); 22 Jan 2010 07:10:29 -0000 Received: (qmail 19197 invoked by uid 48); 22 Jan 2010 07:10:16 -0000 Date: Fri, 22 Jan 2010 07:10:00 -0000 Message-ID: <20100122071016.19196.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: "mjtruog at fastmail dot ca" 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/msg02689.txt.bz2 ------- Comment #4 from mjtruog at fastmail dot ca 2010-01-22 07:10 ------- I can help try to determine the problem if you want since it seems everyone is either busy, doesn't necessarily care right now, or both. However, if someone could provide any hints as to what RTLD_DEEPBIND might be doing to libstdc++ internals that is atypical behavior, it would be helpful. I just suggested that it might be a design problem since it seems like the problem might have a broad scope. I don't wish to suggest that libstdc++ is directly responsible for no reason. I was expecting that there was some strange compiler specific linking going on somewhere but have not set out to try to find anything strange like that since I assumed other people would have a better idea of what might be causing the problem. The problem with RTLD_DEEPBIND might be a new one since it appeared in glibc 2.3.4. While the option is not critical, it seems helpful for keeping dynamic libraries in isolation if it is an N-to-1 relationship where many dynamic libraries are used for a single executable, at runtime based on runtime events. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42679