Re: bin/59224: Build failure on Solaris-11.4 for sh/init.c

["Robert Elz via gnats" <gnats-admin%NetBSD.org@localhost>]

The following reply was made to PR bin/59224; it has been noted by GNATS.

From: Robert Elz <kre%munnari.OZ.AU@localhost>
To: gnats-bugs%netbsd.org@localhost
Cc: 
Subject: Re: bin/59224: Build failure on Solaris-11.4 for sh/init.c
Date: Thu, 27 Mar 2025 06:06:15 +0700

     Date:        Wed, 26 Mar 2025 19:15:00 +0000 (UTC)
     From:        cryintothebluesky%gmail.com@localhost
     Message-ID:  <20250326191500.A24E11A923E%mollari.NetBSD.org@localhost>
 
   | The init.c file is auto generated in:
   |
   | /opt/netbsd/obj.sparc64/bin/sh/init.c
   |
   | however for some reason on this platform this results in broken "
   | character on a new line
 
 That's weird, though Solaris has been known to have some broken shells at
 times.
 
 init.c is generated by extracting code from other source files into a func=
 tion
 which is run at shell startup time (allows initialisation code to be near =
 where
 it is being used without adding overheads of lots of extra function calls)=
 .
 
 That extraction is done by a fairly simple shell script - but that script
 needs to be run by the hosts's shell.
 
 Can you tell me which shell is being used  as HOST_SH ?   (mkinit.sh has a=
  #!
 to direct it to use /bin/sh but that's not used by the Makefile which buil=
 ds
 sh, it is just there to simplify testing of mkinit itself).
 
 It looks as if perhaps something is supplying some line wrapping, which it
 shouldn't be (or isn't intended to be doing) - all that should happen to
 the source line concerned is to simply read it line by line, inserting a
 tab at the start of each line read, and append it all to a shell variable,
 and then later, simply "echo $var" at the appropriate place when
 building init.c
 
 You could try running mkinit.sh manually, perhaps using "sh -x" (with what=
 ever
 "sh" would normally be being used) and see if you can see what is happenin=
 g.
 Usage is approximately just "${MYSHELL} [-x] mkinit.sh *.c" (assuming that
 init.c doesn't already exist, delete it first if it does).
 
 Or you could try removing a tab (or two) from the line in question (line 6=
 83
 of trap.c I believe - at least in HEAD, would be close in -10 as well, I d=
 oubt
 much has changed in that file recently) and see if that alters anything (i=
 t
 wouldn't alter the meaning).
 
 kre