From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org
X-Spam-Level: 
X-Spam-Status: No, score=0.2 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED,
	NICE_REPLY_A autolearn=no autolearn_force=no version=3.4.4
Received: (qmail 19557 invoked from network); 29 Mar 2023 07:31:18 -0000
Received: from 9front.inri.net (168.235.81.73)
  by inbox.vuxu.org with ESMTPUTF8; 29 Mar 2023 07:31:18 -0000
Received: from mail.posixcafe.org ([45.76.19.58]) by 9front; Wed Mar 29 03:30:04 -0400 2023
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=posixcafe.org;
	s=20200506; t=1680075347;
	h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
	 to:to:cc:mime-version:mime-version:content-type:content-type:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=aQQNDXMAe9WipqMXlE7btKOyyhbuw+k0SdIRvvdRRT0=;
	b=pqId6j120CNjHuN1a5pBuvv0IiX4sK4hlRpEL90ggOfpHYgsZXpHpIYpRS/zmBNZzzotbz
	bncyBYgx9dTG6nsK5W3SlvrMZenHx5oawaxt5W07dCGbR/zlh0ReuUEqSluTADDt6BLd14
	Jrm6MqnUZRzNF9aLs8pry1IHHYfBDW4=
Received: from [192.168.168.200] (161-097-205-025.v4.mynextlight.net [161.97.205.25])
	by mail.posixcafe.org (OpenSMTPD) with ESMTPSA id 0262f90e (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO)
	for <9front@9front.org>;
	Wed, 29 Mar 2023 02:35:47 -0500 (CDT)
Message-ID: <54de21b9-9204-3e6e-e012-7d5615e69d78@posixcafe.org>
Date: Wed, 29 Mar 2023 01:29:20 -0600
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.7.2
Content-Language: en-US
To: 9front@9front.org
References: <6CEA77994DD85DFF25CC9888BE2C71C4@smtp.pobox.com>
From: Jacob Moody <moody@mail.posixcafe.org>
In-Reply-To: <6CEA77994DD85DFF25CC9888BE2C71C4@smtp.pobox.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
List-ID: <9front.9front.org>
List-Help: <http://lists.9front.org>
X-Glyph: ➈
X-Bullshit: stateless asynchronous ORM over ActivityPub GPU service 
Subject: Re: [9front] Beware of 'mk nuke': mkrunetype.c
Reply-To: 9front@9front.org
Precedence: bulk

There was a brief window in which this was the case.

The commit 8b3154fb22991c0e96ca0c4e3658434791fc7e69 should have included the generated
files and remedied this issue.

Did you update past this and still have this issue?

On 3/29/23 01:24, Romano wrote:
> I haven't updated my system in a few months, and noticed the Unicode
> changes so wanted to work with them.  I generally do a 'cd /sys/src &&
> mk nuke && mk all', but that led to many errors.  I tried the
> following:
> * re-compile the compilers first (cc & 6c), which was successful; 6a &
>   6l were not
> * compile and install ape (successful)
> * compile libc first (not successful), which led me to:
> * compile the individual .c files in libc/port, which led me to
>   mkrunetype.c still not compiling.
> 
> Yet I was still getting errors like the following:
> 
> cpu% cd /sys/src/libc/port
> cpu% mk
> @{
> 	eval `{grep '^[A-Z]' /$cputype/mkfile}
> 	6c -FTVw -o mkrunetype.6 mkrunetype.c
> 	6l $LDFLAGS -o 6.mkrunetype mkrunetype.6
> 	6.mkrunetype
> }
> param: undefined: _assert in param
> getunicodeline: undefined: getfields in getunicodeline
> estrtoul: undefined: strtoul in estrtoul
> markbreak: undefined: strstr in markbreak
> main: undefined: strcmp in main
> main: undefined: exits in main
> smprint: undefined: setmalloctag in smprint
> fmtStrFlush: undefined: realloc in fmtStrFlush
> fmtStrFlush: undefined: free in fmtStrFlush
> fmtstrinit: undefined: malloc in fmtstrinit
> dofmt: undefined: chartorune in dofmt
> _fmtcpy: undefined: fullrune in _fmtcpy
> _fmtcpy: undefined: runelen in _fmtcpy
> _fmtcpy: undefined: runetochar in _fmtcpy
> fmtstrcpy: undefined: utflen in fmtstrcpy
> xdtoa: undefined: isNaN in xdtoa
> xdtoa: undefined: isInf in xdtoa
> xdtoa: undefined: tolower in xdtoa
> xdtoa: undefined: frexp in xdtoa
> xdtoa: undefined: pow10 in xdtoa
> xdtoa: undefined: strtod in xdtoa
> too many errors
> mk: @{  eval ...  : exit status=rc 2050: rc 2052: 6l 2056: error
> 
> So I just kept updating the linking with the appropriate objects until it compiled. This is what I ended up with:
> @{
> 	eval `{grep '^[A-Z]' /$cputype/mkfile}
> 	6c -FTVw -o mkrunetype.6 mkrunetype.c
> 	6l $LDFLAGS -o 6.mkrunetype mkrunetype.6 getfields.6 strtoul.6 strstr.6 strcmp.6 exits.6 _assert.6 rune.6 utfrune.6 malloc.6 lock.6 atol.6 pool.6 strtol.6 nan.6 strtod.6 toupper.6 frexp.6 pow10.6 utfecpy.6 atexit.6 fabs.6 utflen.6 ctype.6
> 	6.mkrunetype
> }
> 
> I think it might be useful to have a proper patch for the mkfile under
> libc/port.  Thoughts?
>