From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 54659 invoked by alias); 10 Oct 2016 07:58:50 -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 54638 invoked by uid 89); 10 Oct 2016 07:58:49 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=H*r:Mon, capabilities, H*r:0100, arrangement X-Spam-User: qpsmtpd, 2 recipients X-HELO: relay1.mentorg.com Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 10 Oct 2016 07:58:38 +0000 Received: from nat-ies.mentorg.com ([192.94.31.2] helo=SVR-IES-MBX-04.mgc.mentorg.com) by relay1.mentorg.com with esmtp id 1btVTm-0004XG-HT from Iain_Sandoe@mentor.com ; Mon, 10 Oct 2016 00:58:34 -0700 Received: from [127.0.0.1] (137.202.0.87) by SVR-IES-MBX-04.mgc.mentorg.com (139.181.222.4) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 10 Oct 2016 08:58:28 +0100 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Subject: Re: [PATCH] Delete GCJ From: Iain Sandoe In-Reply-To: <31916070-ce2d-423a-e942-33f0b3ebc227@ubuntu.com> Date: Mon, 10 Oct 2016 07:58:00 -0000 CC: Mike Stump , Rainer Orth , Jeff Law , Andrew Haley , GCC Patches , GCJ-patches Content-Transfer-Encoding: quoted-printable Message-ID: <6747724B-4128-4C55-8625-91AA559A0D98@mentor.com> 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> <31916070-ce2d-423a-e942-33f0b3ebc227@ubuntu.com> To: Matthias Klose X-ClientProxiedBy: svr-ies-mbx-01.mgc.mentorg.com (139.181.222.1) To SVR-IES-MBX-04.mgc.mentorg.com (139.181.222.4) X-SW-Source: 2016-q4/txt/msg00017.txt.bz2 > On 10 Oct 2016, at 05:03, Matthias Klose wrote: >=20 > On 07.10.2016 10:30, Iain Sandoe wrote: >>=20 >>> On 7 Oct 2016, at 00:58, Matthias Klose wrote: >>>=20 >>> 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 appropri= ate >>>>> warning. The Objective-C maintainers may have other preferences, tho= ugh. >>>=20 >>> 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 do= esn'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 multili= b aware. >>=20 >> hrm, so perhaps we need a =E2=80=94with-target-boehm-gc=3D type arrangem= ent, and it=E2=80=99s the configurer=E2=80=99s responsibility to provide a = path with appropriate headers/libs for the multi-lib configuration being at= tempted. >=20 > I don't understand what you are proposing here. given that: auto-detection of the capabilities could be quite difficult (or, in the ge= neral case, unachievable) for the reasons you gave. the chosen target libraries might be in a non-standard place. making it an explicit requirement to point to them, and to ensure that the = versions/multi-libs provided are suitable, (by putting =E2=80=94with-target= -boehm-gc=3D/path/to/suitable/) would mean that the dependent configury (fo= r objc-gc) could be just conditional upon the presence of the "with-target= -boehm-gc=E2=80=9D. I suppose that one could make "=E2=80=94with-target-boehm-gc=E2=80=9D (no a= ttached path) declare that the library (and requisite mult-lib versions) wi= ll be found in the sysroot without any additional work. The point here was to simplify the dependent configury so that it only need= s to test something that the configuring user specifies (i.e. if they speci= fy objc-gc, then they need also to specify the place that the gc lib can be= found). >>>> gcc historically is fairly weak at complex configurations. I need the= 32 bit libraries to support -m32, but, those libraries might not be presen= t, 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. D= o I turn off the multilib, or do I not? >>>>=20 >>>> 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 b= ased upon that. Of course, that's all external to gcc proper. Doesn't real= ly make gcc any easier to configure and build or advance gcc. >>>>=20 >>>> We could smell the system at configure time, and turn on and off multi= lib 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 nee= ded 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). >>>>=20 >>>>=20 >>>> So, I think, if I understand what you propose, I'm fine with that. >>>=20 >>> So your proposal is to replace the ": dnl ..." line in libobjc/configur= e.ac with >>> a hard error message and leave it to the user to correctly configure GC= C? That >>> would rely on the compiler to find the library in a system wide multili= b aware >>> directory (e.g. /usr/lib/i386-linux-gnu, or /usr/lib32). Is this the c= ase for >>> Solaris and Darwin? >>=20 >> for Darwin, it=E2=80=99s not a default install (but then neither are the= host deps such as gmp & friends) - so the toolchain builder on Darwin alre= ady needs to make some provisions outside the system. It=E2=80=99s just th= at the only target provisions to date have been the sysroot (we haven=E2=80= =99t yet made use of add-on target libs). >>=20 >>> 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). >>>=20 >>> Looking back at libjava, I think everybody disabled multilibs for libja= va, >>> because nobody had a complete gtk2 stack for multilibs, however that wa= s a >>> complete subdir, not just a certain configuration in that subdir. Looki= ng back >>> at libffi and separate released libffi's I first built multilib'ed libf= fi >>> 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. >>=20 >> Becase Darwin=E2=80=99s libjava does not depend on the gtk2 stack, actua= lly normally libjava (and libffi, gc) were generally built and tested (by t= hose who cared to do it) as multilibs [the default]. >>>=20 >>> In the past I looked at updating boehm-gc to recent sources but never f= inished >>> because libjava relied on internals. Afaics this is not the case for o= bjc-gc, >>> so maybe you could update boehm-gc. But I don't want to go this road my= self =E2=80=A6 >>=20 >> .. and I don=E2=80=99t have cycles to volunteer to try this at present e= ither. >> Iain >>=20 >>=20 >>>=20 >>> Matthias >>=20 >=20