gforth
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Building Gforth for Apple's new Arm-based Macs


From: Alexander Shpilkin
Subject: Re: Building Gforth for Apple's new Arm-based Macs
Date: Wed, 20 Jan 2021 19:29:00 +0300
User-agent: Evolution 3.38.3

On Wed, 2021-01-20 at 00:08 +0100, Anton Ertl wrote:
> On Tue, Jan 19, 2021 at 02:42:10PM -0500, Craig Treleaven wrote:
> > I contribute a little to the MacPorts project.  MacPorts packages many, 
> > many open source software titles for use on Macintosh.  I noticed that 
> > Gforth failed to build on our new buildbot running on an M1 machine(aka 
> > Apple’s 64 bit ARM SOC).  The configure phase reported the following error:
> > 
> > checking build system type... Invalid configuration 
> > `arm64-apple-darwin20.1.0': machine `arm64-apple' not recognized
> > configure: error: /bin/sh ./config.sub arm64-apple-darwin20.1.0 failed
> 
> config.sub apparently does not know this architecture under the name
> arm64, but instead under the name aarch64.

Incidentally, I looked at the corresponding branch in configure.ac[1]
and it seems to me that the check for arm_cacheflush there is...
technically correct, but extremely misleading: if the variable is
empty, `test -z $arm_cacheflush` is just `test -z`, which POSIX
requires `test` to interpret as being given _no_ operators and a single
string argument, "-z", and to succeed if that string argument is
nonempty (which it is).  While this works for -z, it would do the wrong
thing should a careless edit replace it with -n, for example, so I
think that quoting the variable to get `test -z "$arm_cacheflush"`
would be safer and clearer.

    $ foo=
    $ test -z "$foo"; echo $?
    0
    $ test -n "$foo"; echo $?
    1
    $ test -z $foo; echo $?
    0
    $ test -n $foo; echo $? # sic
    0

More seriously, I see that the OS detection code below[2] uses the
pattern `*win*` to detect Windows;  I don’t know if this is a distro-
specific quirk or not, but my current mingw-w64[3]-based Linux cross
toolchain for Windows calls itself {x86-64,i686}-w64-mingw32, which
would not be detected by this test.  (We appear to have Stallman’s
political insistence on not using the common abbreviation of "Windows"
to "Win" to thank for this technical confusion.)  I am also somewhat
puzzled by this branch setting PATHSEP to colon and not semicolon, but
that at least seems to be a known problem.

[1]: https://git.savannah.gnu.org/cgit/gforth.git/tree/configure.ac#n351
[2]: https://git.savannah.gnu.org/cgit/gforth.git/tree/configure.ac#n932
[3]: http://mingw-w64.org/

-- 
Thanks,
Alex

Attachment: signature.asc
Description: This is a digitally signed message part


reply via email to

[Prev in Thread] Current Thread [Next in Thread]