From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from einhorn-mail-out.in-berlin.de (einhorn.in-berlin.de [192.109.42.8]) by sourceware.org (Postfix) with ESMTPS id 82D4B3857827 for ; Wed, 14 Jul 2021 05:42:18 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 82D4B3857827 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=ubuntu.com Authentication-Results: sourceware.org; spf=none smtp.mailfrom=ubuntu.com X-Envelope-From: doko@ubuntu.com Received: from authenticated.user (localhost [127.0.0.1]) by einhorn.in-berlin.de with ESMTPSA id 16E5gFP2024463 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Wed, 14 Jul 2021 07:42:15 +0200 To: Richard Biener Cc: David Malcolm , GCC Patches , jit@gcc.gnu.org References: <1553292046.18132.49.camel@redhat.com> <96c1d3f3-d8a1-9545-0269-df45e192c98e@ubuntu.com> <5a46c90f-aea4-7dd6-cbc6-db8cf29cba95@ubuntu.com> From: Matthias Klose Subject: Re: [patch] PR jit/87808: Allow libgccjit to work without an external gcc driver Message-ID: <11f26e09-58eb-fd77-2be5-396c771f034b@ubuntu.com> Date: Wed, 14 Jul 2021 07:42:15 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, KAM_LAZY_DOMAIN_SECURITY, NICE_REPLY_A, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=no autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: jit@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Jit mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jul 2021 05:42:20 -0000 On 7/13/21 8:41 AM, Richard Biener wrote: > On Mon, Jul 12, 2021 at 11:00 PM Matthias Klose wrote: >> >> On 3/26/19 12:52 PM, Matthias Klose wrote: >>> On 22.03.19 23:00, David Malcolm wrote: >>>> On Thu, 2019-03-21 at 12:26 +0100, Matthias Klose wrote: >>>>> Fix PR jit/87808, the embedded driver still needing the external gcc >>>>> driver to >>>>> find the gcc_lib_dir. This can happen in a packaging context when >>>>> libgccjit >>>>> doesn't depend on the gcc package, but just on binutils and libgcc- >>>>> dev packages. >>>>> libgccjit probably could use /proc/self/maps to find the gcc_lib_dir, >>>>> but that >>>>> doesn't seem to be very portable. >>>>> >>>>> Ok for the trunk and the branches? >>>>> >>>>> Matthias >>>> >>>> [CCing the jit list] >>>> >>>> I've been trying to reproduce this bug in a working copy, and failing. >>>> >>>> Matthias, do you have a recipe you've been using to reproduce this? >>> >>> the JIT debug log shows the driver names that it wants to call. Are you sure >>> that this driver isn't available anywhere? I configure the gcc build with >>> --program-suffix=-8 --program-prefix=x86_64-linux-gnu-, and that one was only >>> available in one place, /usr/bin. >>> >>> Matthias >> >> David, the bug report now has two more comments from people that the current >> behavior is broken. Please could you review the patch? > > I think libgccjit should use the same strathegy for finding the install location > like the driver does itself. I couldn't readily decipher its magic but at least > there's STANDARD_EXEC_PREFIX which seems to be used as possible > fallback. No, it's crtbeginS.o, and libgcc.* which are are not found in the STANDARD_EXEC_PREFIX. > In particular your patch doesn't seem to work with a DESTDIR= > install? it does. usually you build as configure && make && make install with a DESTDIR set for only the last step, which doesn't rebuild any object file. > Can we instead add a --with-gccjit-install-dir= or sth like that (whatever > path to whatever files the JIT exactly looks for)? that should be possible, moving the definition of FALLBACK_GCC_EXEC_PREFIX from the Makefile to a value specified by a configure value. Or is there already a macro, that doesn't get prefixed by DESTDIR? Matthias