From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2946 invoked by alias); 10 Oct 2016 04:03:33 -0000 Mailing-List: contact java-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: java-patches-owner@gcc.gnu.org Received: (qmail 2924 invoked by uid 89); 10 Oct 2016 04:03:32 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.2 spammy=Hx-languages-length:4168, arrangement, road X-Spam-User: qpsmtpd, 2 recipients X-HELO: einhorn.in-berlin.de Received: from einhorn.in-berlin.de (HELO einhorn.in-berlin.de) (192.109.42.8) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 10 Oct 2016 04:03:21 +0000 X-Envelope-From: doko@ubuntu.com Received: from [192.168.178.26] (ip5f5af460.dynamic.kabel-deutschland.de [95.90.244.96]) (authenticated bits=0) by einhorn.in-berlin.de (8.14.4/8.14.4/Debian-8+deb8u1) with ESMTP id u9A43DtV026216 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 10 Oct 2016 06:03:13 +0200 Subject: Re: [PATCH] Delete GCJ To: Iain Sandoe References: <78f841e7-808b-58d0-7913-3ec0d19630a0@redhat.com> <4deb7e45-e428-d819-aabc-748abe8f7686@redhat.com> <0E421C5A-7EF5-4182-A13B-BF9AEAF90215@comcast.net> <6DA7C7D0-314E-4A5E-8B35-5A8EA2F74CD8@mentor.com> <2b5de569-1efd-f407-49c2-c9fa84cc5315@ubuntu.com> <4964955d-4de1-618c-de41-835ca19f9932@ubuntu.com> <4FBA6B16-460A-4EBB-8809-0883A84ABEB7@mentor.com> <0bf14402-d4e6-5fb0-8a63-479903ed2141@ubuntu.com> <01B885DF-4340-43C6-A784-21326A9CA8CF@comcast.net> <10704c8f-fd72-8d13-17a1-f522e88345b2@ubuntu.com> Cc: Mike Stump , Rainer Orth , Jeff Law , Andrew Haley , GCC Patches , GCJ-patches From: Matthias Klose Message-ID: <31916070-ce2d-423a-e942-33f0b3ebc227@ubuntu.com> Date: Mon, 10 Oct 2016 04:03:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-IsSubscribed: yes X-SW-Source: 2016-q4/txt/msg00016.txt.bz2 On 07.10.2016 10:30, Iain Sandoe wrote: > >> On 7 Oct 2016, at 00:58, Matthias Klose wrote: >> >> On 06.10.2016 20:00, Mike Stump wrote: >>> On Oct 6, 2016, at 9:56 AM, Rainer Orth wrote: >>>> I wouldn't hard-fail, but completely disable objc-gc with an appropriate >>>> warning. The Objective-C maintainers may have other preferences, though. >> >> I think I can't do that in the top level make file very well (currently I only >> have the pkg-config check there for an early failure, but that check doesn't >> tell me if the library is present for all multilib variants). And I can't check >> for multilibs because I don't know if the bootstrap compiler is multilib aware. > > hrm, so perhaps we need a —with-target-boehm-gc= type arrangement, and it’s the configurer’s responsibility to provide a path with appropriate headers/libs for the multi-lib configuration being attempted. I don't understand what you are proposing here. >>> gcc historically is fairly weak at complex configurations. I need the 32 bit libraries to support -m32, but, those libraries might not be present, but do I build all the rest of my libraries, and if i do, do I test them once build, but what is other dependent external libraries are missing. Do I turn off the multilib, or do I not? >>> >>> I used to manage some of this by passing in configure flags to control multilibbing based upon what libraries were install and then run testing based upon that. Of course, that's all external to gcc proper. Doesn't really make gcc any easier to configure and build or advance gcc. >>> >>> We could smell the system at configure time, and turn on and off multilib variants and things like objc gc. Target specific, but I think it helps to ponder this in a target independent way. This can then turn on and off objc gc support directly. To get it on, one would need to install the needed libraries, and reconfigure and rebuild gcc. I think I might like that the best. Has a nice easy of use about it, and then everything gcc does is rather sane (no funny build errors when a needed library isn't present). >>> >>> >>> So, I think, if I understand what you propose, I'm fine with that. >> >> So your proposal is to replace the ": dnl ..." line in libobjc/configure.ac with >> a hard error message and leave it to the user to correctly configure GCC? That >> would rely on the compiler to find the library in a system wide multilib aware >> directory (e.g. /usr/lib/i386-linux-gnu, or /usr/lib32). Is this the case for >> Solaris and Darwin? > > for Darwin, it’s not a default install (but then neither are the host deps such as gmp & friends) - so the toolchain builder on Darwin already needs to make some provisions outside the system. It’s just that the only target provisions to date have been the sysroot (we haven’t yet made use of add-on target libs). > >> I'm fine with that, it wouldn't affect configurations like x86_64-linux-gnu >> where multilib is the default (but objc-gc is not). >> >> Looking back at libjava, I think everybody disabled multilibs for libjava, >> because nobody had a complete gtk2 stack for multilibs, however that was a >> complete subdir, not just a certain configuration in that subdir. Looking back >> at libffi and separate released libffi's I first built multilib'ed libffi >> libraries from the libffi source for Debian/Ubuntu, then dropped these because >> they were not used, and until today GCC internal and external libffi are >> hopelessly out of sync, so you couldn't use an external libffi to build libjava. > > Becase Darwin’s libjava does not depend on the gtk2 stack, actually normally libjava (and libffi, gc) were generally built and tested (by those who cared to do it) as multilibs [the default]. >> >> In the past I looked at updating boehm-gc to recent sources but never finished >> because libjava relied on internals. Afaics this is not the case for objc-gc, >> so maybe you could update boehm-gc. But I don't want to go this road myself … > > .. and I don’t have cycles to volunteer to try this at present either. > Iain > > >> >> Matthias >