From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5073 invoked by alias); 3 Jan 2003 00:01:46 -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 5066 invoked from network); 3 Jan 2003 00:01:44 -0000 Received: from unknown (HELO mail.brainstorm.co.uk) (217.169.5.196) by 209.249.29.67 with SMTP; 3 Jan 2003 00:01:44 -0000 Received: from nicola.brainstorm.co.uk (nicola.brainstorm.co.uk [192.168.4.138]) by mail.brainstorm.co.uk (8.11.4/8.11.4) with ESMTP id h0300wG12352; Fri, 3 Jan 2003 00:00:58 GMT Date: Fri, 03 Jan 2003 00:01:00 -0000 From: Nicola Pero To: "Timothy J. Wood" cc: "Andrea 'fwyzard' Bocci" , Matthias Klose , gcc@gcc.gnu.org Subject: Re: [3.2/3.3/HEAD] shared libobjc not built In-Reply-To: <4D9D51ED-1E94-11D7-B25D-0003938E4E3C@omnigroup.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SW-Source: 2003-01/txt/msg00077.txt.bz2 > > Hmmm ... I suspected to have originally wrote/submitted the lines > > > > # Disable shared libs by default > > AC_DISABLE_SHARED > > > For what it's worth, I know that there were problems building shared > objc in MinGW. Maybe this came from there? > > (I'd sure love it if libobjc worked as a shlib on MinGW, though :) Thanks - 'problems building shared objc in MinGW' - do you mean it doesn't compile, or just that once you've compiled it, it's quite useless ? Because I don't use windows, but on GNUstep's instructions for MinGW I find - "It's a good idea to remove the libobjc.a and include/objc header that come with gcc (gcc -v for location) so that they are not accidentally found instead of the libobjc DLL that you will compile below." and I've heard this repeated on mailing lists quite often, so I suspect building libobjc as static on MinGW is not really a solution either, as it seems a libobjc.a on MinGW is not really a usable thing :-) [I think the problem starts when people build all other libraries as DLLs, and mixing DLLs and static libs doesn't seem a good thing ... well I don't really know, but that's what I heard]. The 'libobjc DLL that you will compile below.' is of course built from GNUstep's separate maintained version of libobjc, which can be built and used out-of-the-box as a DLL on MinGW. I suppose what we'd really want then is to fix building the libobjc shipped with GCC as a DLL on MinGW. :-) I don't have the time to work on this.