From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14034 invoked by alias); 12 May 2002 18:30:48 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 14027 invoked from network); 12 May 2002 18:30:47 -0000 Received: from unknown (HELO localhost.localdomain) (66.60.148.227) by sources.redhat.com with SMTP; 12 May 2002 18:30:47 -0000 Received: from warlock.codesourcery.com (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.11.6/8.11.6) with ESMTP id g4CITit09121; Sun, 12 May 2002 11:29:44 -0700 Date: Sun, 12 May 2002 12:17:00 -0000 From: Mark Mitchell To: Jason Merrill , David Abrahams cc: "python-dev@python.org" , "Ralf W. Grosse-Kunstleve" , "gcc@gcc.gnu.org" , "Martin v. Loewis" Subject: Re: Minimal GCC/Linux shared lib + EH bug example Message-ID: <50980000.1021228184@warlock.codesourcery.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SW-Source: 2002-05/txt/msg00901.txt.bz2 > I find this testcase somewhat persuasive, as the offending dlopen call is > not in the C++ code. What do others think? I agree with your other statement: RTLD_LOCAL and C++ don't really make sense. I think we're running down a slippery slope; once EH works, people *will* wonder why things involving inlines and templates don't. If, for example, you have *two* Python modules in C++, each of which uses a nice package for managing global resources, and you can load either module just fine, but loading both causes subtle runtime problems, ... We will have given people a bigger bazooka, but it will be aimed at their own feet. -- Mark Mitchell mark@codesourcery.com CodeSourcery, LLC http://www.codesourcery.com