[cfarm-users] [cfarm-announces] New Apple M1 machine running macOS (gcc104)

[Christian Jullien]

Currently, TinyCC, the super fast C compiler I modestly contribute on, works with limitations on M1 but only with x86_64 emulation.
We hope to have a native M1 port as TinyCC has already an aarch64 backend.

Until then, works remains to better support TinyCC on M1 with Rosetta emulation so it's a nice to have on this machine.

C.

-----Original Message-----
From: Zach van Rijn [mailto:me at zv.io] 
Sent: Tuesday, October 18, 2022 06:56
To: jullien at eligis.com; GCC Compile Farm Users
Cc: Christian Jullien
Subject: Re: [cfarm-users] [cfarm-announces] New Apple M1 machine running macOS (gcc104)

On Tue, 2022-10-18 at 05:40 +0200, Christian Jullien via cfarm-
users wrote:
> Many thanks team!!
> 
> I noticed an issue with x86_64 support
> 
> gcc104 (homebrew):~ jullien$ cat foo.c
> #include <stdio.h>
> int
> main() {
>   printf("Hello World\n");
> }
> gcc104 (homebrew):~ jullien$ gcc -arch x86_64 foo.c -o foo &&
> ./foo
> bash: ./foo: Bad CPU type in executable

on x86_64 executables
---------------------

I think this requires Rosetta, something like:

  # softwareupdate --agree-to-license --install-rosetta

However I'm wondering if this should be enabled or left as-is?
Would it be confusing for x86_64 binaries to run out of the box?


on system stability
-------------------

The system appears to have low resource limits, and is currently
not available by SSH. Existing connections say something like:

    -sh: fork: Resource temporarily unavailable

A quick search reveals that this may be a solution? Anyone have
experience with this? https://support.apple.com/en-us/HT202528

This may require a physical poweroff/poweron cycle. If the system
does not become available again soon, this may take a few days...


on external storage
-------------------

Since the internal disk is rather small:

  * A 2TB NVMe disk has been attached at /Volumes/STORAGE/ and it
    gets nearly 8gbps (1GB/s) in write performance.

  * Each user has their own directory at /Volumes/STORAGE/$USER

  * A symbolic link at $HOME/STORAGE points to that directory,
    and it cannot be deleted.

  * You should use this external storage for large files, or to
    archive projects that you're not actively working on.

  * Internal storage is limited, but it's a resource you should
    use since it exists. Use it for compiles instead of NVMe.


Thanks for your patience as we tune this machine. I wonder if the
same thing happened to gcc304. Hopefully that comes back, too.


ZV