From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27218 invoked by alias); 9 Sep 2005 09:19:56 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Received: (qmail 26963 invoked by uid 48); 9 Sep 2005 09:19:47 -0000 Date: Fri, 09 Sep 2005 09:19:00 -0000 Message-ID: <20050909091947.26962.qmail@sourceware.org> From: "bkoz at gcc dot gnu dot org" To: gcc-bugs@gcc.gnu.org In-Reply-To: <20050705135434.22309.jakub@redhat.com> References: <20050705135434.22309.jakub@redhat.com> Reply-To: gcc-bugzilla@gcc.gnu.org Subject: [Bug libstdc++/22309] mt allocator doesn't pthread_key_delete it's keys X-Bugzilla-Reason: CC X-SW-Source: 2005-09/txt/msg01092.txt.bz2 List-Id: ------- Additional Comments From bkoz at gcc dot gnu dot org 2005-09-09 09:19 ------- Hey Jakub. Yeah, I think this can be back-ported. I put in my patch, which looks pretty good on x86/linux. We could proably do something more elaborate to not duplicate some of the symbols but I'm feeling lazy... this is good enough. Sorry about the confusion about the static freelist_mutex. Yes, this was what I was getting at by "linkage clarity" ... I think we are on the same page. Yes, this is a good idea, and I'll clean this up too as a follow-on patch. Umm... so, no, I don't get what you are getting at WRT destructors in libstdc++.so. I think you mean functions in testsuite_shared.so that are asm destrutors but that use __mt_alloc to do allocations or something. You mean, what then? Maybe we'd both be better off if you came up with an example... I think just static ordering in this file will work. Won't that just work? Man, I want that to work. If not, then the init priorty stuff can be re-added. The thing is, there are no config tests for init priority... ..... I thought support of that was kind of dodgy, non-ELF... if this feature is going to be used, there are other things with __ioinit that can also be done. Anyway. Of more immediate concern is that the testsuite dejagnu hacking is quite weak. For instance, The testsuite file should just be run on linux, so I think that is ok. But the shared object is unconditionally compiled, even for --disable-shared builds.... also, compiled with a complete hack for flags, likely to only work on linux... It is kind of funny, just to be re-creating an autoconf way of doing this, but doing it in dejagnu. Ugh. Some of this stuff would be easier if we could use Make to build instead of dejagnu.... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22309