From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25757 invoked by alias); 3 Jan 2003 00:46:21 -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 25729 invoked from network); 3 Jan 2003 00:46:18 -0000 Received: from unknown (HELO omnigroup.com) (198.151.161.1) by 209.249.29.67 with SMTP; 3 Jan 2003 00:46:18 -0000 Received: from omnigroup.com (seel.omnigroup.com [198.151.161.19]) by omnigroup.com (8.10.2/8.9.1) with ESMTP id h030jDx03274; Thu, 2 Jan 2003 16:45:13 -0800 (PST) Date: Fri, 03 Jan 2003 00:46:00 -0000 Subject: Re: [3.2/3.3/HEAD] shared libobjc not built Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v548) Cc: "Andrea 'fwyzard' Bocci" , Matthias Klose , gcc@gcc.gnu.org To: Nicola Pero From: "Timothy J. Wood" In-Reply-To: Message-Id: Content-Transfer-Encoding: 7bit X-SW-Source: 2003-01/txt/msg00083.txt.bz2 On Thursday, January 2, 2003, at 04:00 PM, Nicola Pero wrote: > 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 ? My personal experience was that the MinGW distribution just wouldn't build a DLL for ObjC. I don't recall whether it was an error, or whether they inherited the configury from GCC that disabled shared libraries (for some other reason). The responses I got on the MinGW list (around 1/6/2002) indicated that I should just use the GNUstep version. The only indication I see of *why* is that the GNUstep version had different configury bits and a .def file to export the right symbols. I'm assuming there was some real problem, but it's been so long ago that I may be misremembering and it might be that MinGW's problem is an effect of GCC's problem, not the other way around. [...] > 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]. Building libobjc static under MinGW doesn't work well if your other libraries are DLLs _and_ if you want to get good warnings about undefined symbols in your DLLs. You can link the static library into main application and then not link it into your DLLs (linking in both causes madness since you get multiple copies of the ObjC runtime data). I don't recall why didn't go this direction unless it was that I somehow couldn't get DLLs to link with the undefined ObjC symbols... > 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. Yes, I'd definitely like this -- assuming ObjC as a shared library works in GCC now, I can maybe scrounge up some time to get it working on MinGW. I assume all I'd need to do would be to remove 'AC_DISABLE_SHARED' and then reconfigure? -tim