From nobody Sat Jun 26 03:52:34 2021 X-Original-To: freebsd-toolchain@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 7EEA611E6031; Sat, 26 Jun 2021 03:52:40 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [50.1.20.27]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "www.zefox.com", Issuer "www.zefox.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4GBg1h1qfhz4mmW; Sat, 26 Jun 2021 03:52:39 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.16.1/8.15.2) with ESMTPS id 15Q3qYvx018950 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Fri, 25 Jun 2021 20:52:35 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.16.1/8.15.2/Submit) id 15Q3qYLV018949; Fri, 25 Jun 2021 20:52:34 -0700 (PDT) (envelope-from fbsd) Date: Fri, 25 Jun 2021 20:52:34 -0700 From: bob prohaska To: Mark Millard Cc: FreeBSD ports , freebsd-arm , FreeBSD Toolchain Subject: Re: llvm10 build failure on Rpi3 Message-ID: <20210626035234.GA18893@www.zefox.net> References: <6F0CF2F3-A298-4CEA-AA07-B79810F3E8CF@yahoo.com> <20210623222838.GA85566@www.zefox.net> <8E78EE69-44A2-429E-AB65-941537DE25A0@yahoo.com> <20210624043000.GA87740@www.zefox.net> <22B941CA-3AFF-42FD-98D1-D40EC2F6EC43@yahoo.com> <20210624160109.GB87740@www.zefox.net> <3B41633E-AAFC-422A-8D73-3B1B001023F0@yahoo.com> <20210625001651.GA98214@www.zefox.net> <5A26965D-2DFD-4A46-A171-A382A61E3CFB@yahoo.com> List-Id: Maintenance List-Archive: https://lists.freebsd.org/archives/freebsd-toolchain List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-toolchain@freebsd.org X-BeenThere: freebsd-toolchain@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5A26965D-2DFD-4A46-A171-A382A61E3CFB@yahoo.com> X-Rspamd-Queue-Id: 4GBg1h1qfhz4mmW X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N On Fri, Jun 25, 2021 at 07:52:32PM -0700, Mark Millard wrote: [huge snip, hope the quotes are still correct] > > So I'm going to suggest using an official kernel build > > as built by the ci.freebsd.org systems, one that is not > > GENERIC-MMCCAM. In: > > World and kernel are updating now to -current as of yesterday. I'll replace GENERIC-MMCCAM with GENERIC for simplicity. > > > > I gather that no RPi4B is available to move the media > > to? (Having more RAM but being able to force much of > > it to be ignored can be handy as a test environment > > for this kind of context.) > > It's still patiently chewing away at www/chromium single-threaded. My mistake, but best to finish what's started.. Now that how to use the packages created is known they can be tested. > > So: no warning about being mis-tuned vs. the 1 GiByte of > used RAM. (I do not know about your context for this.) > My Pi3 does report too much swap. But I remain uncertain about the practical significance of the warning. I gather the issue is that a certain amount memory is set aside to "index", for lack of a better word, the data stored in swap. If there's too much swap relative to index, not all swap can be used. That seems not much different than running out of swap. > All the ports that devel/llvm10 needs are already in place > for poudriere's use for this experiment. > > Another point is: > > # more /usr/local/etc/poudriere.d/options/devel_llvm10/options > # This file is auto-generated by 'make config'. > # Options for llvm10-10.0.1_3 > _OPTIONS_READ=llvm10-10.0.1_3 > _FILE_COMPLETE_OPTIONS_LIST=BE_AMDGPU CLANG DOCS EXTRAS LIT LLD LLDB LLD_LINK OPENMP PYCLANG BE_FREEBSD BE_NATIVE BE_STANDARD > OPTIONS_FILE_SET+=BE_AMDGPU > OPTIONS_FILE_SET+=CLANG > OPTIONS_FILE_SET+=DOCS > OPTIONS_FILE_SET+=EXTRAS > OPTIONS_FILE_SET+=LIT > OPTIONS_FILE_SET+=LLD > OPTIONS_FILE_SET+=LLDB > OPTIONS_FILE_SET+=LLD_LINK > OPTIONS_FILE_SET+=OPENMP > OPTIONS_FILE_UNSET+=PYCLANG > OPTIONS_FILE_UNSET+=BE_FREEBSD > OPTIONS_FILE_SET+=BE_NATIVE > OPTIONS_FILE_UNSET+=BE_STANDARD > > (So I normally build less than BE_STANDARD or > BE_FREEBSD would build.) I'm my own worst enemy when it comes to customization. The less changed the better 8-) > We will see if this is enough common context to > replicate the general type of build problem. > (Your details very from one attempt to the next > so an exact match need not be expected, even if > if this does also fail.) > If you replicate the problem I'll be very pleased. And just slightly relieved. My suspcions still center around things I might have done to corrupt /usr/local/poudriere. That leaves me wondering how to proceed after world, kernel and ports are updated. Delete /usr/local/poudriere (which would toss the packages created so far), delete only the jail (not sure if that'll delete existing packages library) or something more selective that I don't know about? The Pi3B is purely experimental, but I'd rather not throw away usable progress given the extreme slowness of that progress. Thank you! bob prohaska