
Building Elixir from source segfaults on macOS on Apple Silicon while compiling - shadykiller
https://groups.google.com/forum/#!msg/elixir-lang-core/9s6-BIxaCz8/i-NmhjabAQAJ
======
oefrha
Related: ongoing compatibility table compiled by the Homebrew team:
[https://github.com/Homebrew/brew/issues/7857](https://github.com/Homebrew/brew/issues/7857).
(Please respect the team and refrain from polluting the thread. If in doubt
check the comments marked off topic.)

~~~
marcinzm
No GCC support if I read that correctly and the effort is expected to take
months of full time work. I wonder what that'd break or is Clang significantly
more common on OSX now?

~~~
KenoFischer
Well, for one, this means that Apple Silicon has no Fortran compiler, which
breaks a decent chunk of the scientific computing ecosystem.

~~~
analognoise
Does anyone in the scientific computing ecosystem use Macs?

I can't think of...any program in that sphere that aren't Windows or Linux?

~~~
FridgeSeal
A huge chunk of scientific and numerical libraries rely on Fortran, for which
64-bit support is seriously lacking on Windows.

Doing this work is significantly easier out-of-the-box on Mac/Linux device.

Data Science is my main job and the first thing I did at my last job was ask
if I could wipe windows and put Linux on the desktop they gave me.

~~~
ryl00
> A huge chunk of scientific and numerical libraries rely on Fortran, for
> which 64-bit support is seriously lacking on Windows.

How so? mingw-64 exists, and so does Intel Fortran (with good integration with
the VS IDE as well).

------
blairanderson
The first comment on that thread is from the creator of Elixir:

> Elixir doesn’t compile any native code. Therefore these errors mean that you
> were able to compile the Erlang VM but either the code or the compiler has
> bugs and the VM is seg faulting.

~~~
drvdevd
I’ve run into errors compiling the Erlang VM before (just doing some Linux
package management). If I casually ran into these types of issues on x86, I’m
skeptical this really has anything to do with Apple Silicon, which is ARM
after all.

~~~
arjan_sch
Erlang compiles and runs fine on ARM architectures in general. It is used
extensively on IoT platforms like [https://www.nerves-
project.org/](https://www.nerves-project.org/)

~~~
KenoFischer
Probably not super well tested with a bleeding edge clang compiler though (and
even for non-bleeding-edge versions, I'd suspect mostly tested with GCC).
Triggering compiler bugs or exposing technically undefined behavior would not
be entirely surprising.

~~~
arjan_sch
True. IIRC Erlang only supports GCC as the build system. I helped fixing a
race in the BEAM a while back that only occurred on the latest GCC.

~~~
KenoFischer
> IIRC Erlang only supports GCC as the build system.

Since gcc doesn't work on Apple Silicon, I assumed the OP must be using clang
:).

~~~
asveikau
gcc certainly compiles for ARM and understands Darwin/mach-o. It can probably
target iOS. What would the major barrier be for gcc to work?

~~~
KenoFischer
See
[https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96168](https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96168).

~~~
asveikau
This is a great thread, thanks! (And I see that your name is in the thread.)

I gather from there that previous efforts to target iOS are outdated, there is
substantial work to handle the Apple ABI, and that it's not been seriously
looked at yet.

------
st3fan
Why is this news? Thousands of projects are in this position where they are
porting to a new platform. This is normal.

~~~
karmakaze
How interesting this might be depends on why it crashed. It's likely the
compiler that compiled the Beam VM not producing the correct code for Apple
silicon. If it turns out to be in the Apple ARM OS or possibly hardware, then
it gets more interesting. Also, many top posts on HN these days I don't find
newsworthy but I wouldn't say so categorically, just to me.

------
js2
I tried to use clang to compile some NDK code on Android and the resulting
binary segfaulted. I tracked it down to what appeared to be a bug with
register spilling. The fix was to use gcc and hope the clang bug was
eventually fixed.

These things happen.

[https://groups.google.com/forum/m/#!topic/google-breakpad-
di...](https://groups.google.com/forum/m/#!topic/google-breakpad-
discuss/uNjAGPCX1Fo)

~~~
pjmlp
I guess this was a while ago, given that GCC support has been dropped since a
couple of releases.

~~~
js2
Yes about two years ago, but the bug wasn’t fixed till April this year and it
looks like the fix was a work-around:

[https://chromium.googlesource.com/linux-syscall-
support/+/be...](https://chromium.googlesource.com/linux-syscall-
support/+/be2d5a80df9a9519cab306508ce902d774da76a9)

------
benmmurphy
The elixir compiler runs jobs in parallel so it could be triggering a
concurrency issue due to differences in the memory model between x86 and ARM.
I’ve peered at the Erlang VM code and it looks like they are using primitives
that are aware of the differences but they might not have covered everything.

Until recently there was a concurrency bug in the VM that would trigger on
elixir compiles that would cause compilation to hang on both x86 and ARM.

------
nazgulsenpai
Honest question, why go through this transition with macOS as a developer
instead of Linux or Windows? Is there something that macOS provides developers
that other operating systems don't?

~~~
Spartan-S63
For me, the fact that it's enterprise Unix, basically. It's polished, smooth,
well-supported, the hardware it runs on is spectacular, and it Just Works™.

I do like Linux for server computing and for command-line/batch computing, but
I don't like the state of the Linux Desktop and thus don't consider it
seriously as a primary machine.

Windows is just a nightmare and even with WSL2, it still feels like it's
bolted on. I only keep a Windows desktop around for gaming. I don't and won't
do any productive work on Windows anymore.

~~~
AsyncAwait
Enterprise indeed, including charging premium for features that should come by
default.

As someone who has to use a Mac at work, it still baffles me how macOS doesn't
even ship with a serious file manager by default in 2020 and every decent
alternative costs decent amount of money.

~~~
gumby
> it still baffles me how macOS doesn't even ship with a serious file manager
> by default in 2020

Serious question: what do you use it for? I rarely use the finder at all; when
I do it’s for pretty trivial things that it handles just fine. Generally ls,
cd, open, tar etc are enough for me.

I understand a lot of people consider the Finder broken so I assume it lacks
“power user” features, at least. But aren’t the power users by definition a
couple of sigma out so are better served by a paid product?

For example I don’t use apple’s calendar app but paid $50 for a different
calendar. I wouldn’t recommend that most people do this: apple calendar is
fine for the bulk of users. I just happened to have some special needs. Could
your case be the same?

~~~
AsyncAwait
> But aren’t the power users by definition a couple of sigma out so are better
> served by a paid product

My point was that on Linux you get the features that on macOS are paid and
considered for power users for free and as standard.

------
Nursie
Stupid question time -

Where are these folks getting Apple silicon? Is there a dev MacOS distribution
for iPad? Or is it likely they have preview hardware?

~~~
xenospn
You can buy it from Apple.

~~~
donarb
Note, that it's more like a rental. You are required to return the equipment
at the end of the beta period.

------
olliej
Are there any 4k page size expectations built into the VM? From wwdc the DTKs
have 16k pages?

------
vmchale
I expect that we'll see a lot of this. At least it's getting caught before it
gets to consumers? But not entirely impressed with the work Apple is making
developers shoulder.

~~~
dilap
Is there any alternative though (other than not switching to ARM?)?

I guess Apple could go out and try to preemptively fix all software, but that
seems excessive to expect. :-)

~~~
crooked-v
They're actually actively contributing to a number of major open-source
projects to fix ARM issues:
[https://twitter.com/wongmjane/status/1275177255681982464](https://twitter.com/wongmjane/status/1275177255681982464)

~~~
chongli
If anyone out there is reading this and wondering whether the switch to ARM is
part of some plan to eventually lock down macOS to the same level as iOS, they
need only click the above link. Why would Apple dedicate engineers to fixing
up all these open source projects if they were planning to lock them out?

I think this very clearly demonstrates Apple’s commitment to supporting open
source, user-installed software on Macs, outside of the Mac App Store.

~~~
orangecat
Yes, developers need to be able to run arbitrary code. But that's not
inconsistent with macOS being locked down by default and requiring a developer
certificate to run unapproved software.

Of course, moving to ARM is orthogonal to that; Apple could just as easily
impose restrictions on x86 Macs. The only immediate downside to ARM is the
loss of the ability to boot other OSes, which has apparently been getting more
difficult anyway due to custom hardware like the T2 chip.

~~~
chongli
Click the link. Not all of those are developer tools. Blender being a
prominent example. Apple's contribution to Blender is inconsistent with a goal
of "requiring a developer certificate to run unapproved software."

No, I think Apple will always keep the Mac as a platform where end users can
run unapproved software with appropriate warnings. The Mac is a serious tool
for many different roles, not just development, and not every tool fits into
Apple's App Store ecosystem. This is Apple's tacit acknowledgement of that
fact.

~~~
orangecat
_Not all of those are developer tools. Blender being a prominent example. "_

Sure, and Blender could be in the app store. (There are possible issues with
the GPL, but Apple could fix that if they cared to).

 _No, I think Apple will always keep the Mac as a platform where end users can
run unapproved software with appropriate warnings._

Well, if you believe Apple's messaging, then using an iPad for real work is
not only possible but often better than a traditional computer, and also it's
too dangerous to allow unapproved software on it even if users had to
explicitly opt in. I think it's entirely possible (although far from certain)
that Apple could decide that the App Store is good enough for 80% of users,
and everyone else can either pay for developer/pro access or go away. I don't
think moving to ARM makes that more likely, but nor do I think contributing
open source fixes makes it less likely.

~~~
xenadu02
The message has been clear for years now. It was re-iterated in WWDC videos
and various interviews.

The Mac is the Mac. It has been and will continue to be the machine where you
can install software not approved by Apple, turn off security, and otherwise
poke at the system. You can still create your own kext caches and mount the
root filesystem as read-write on Apple Silicon. The procedure has changed but
the ability to do it has not.

I really honestly don't know how much clearer it can be.

~~~
api
It wouldn't make sense for them to do otherwise. The Mac has its market and a
large proportion of that market demands those abilities. Why turn the Mac into
iPadOS when they have iPadOS already?

What they are accomplishing by going to their own silicon is eliminating the
need to maintain the Mac as a completely different hardware and driver line.
Now the Mac is just a bigger higher specced clamshell iPad with MacOS, and
MacOS is the same kernel and mostly the same drivers as iPadOS and iOS but
different security policies and a somewhat different user space. It's sort of
like a different Linux distribution with a different window manager and
different defaults.

I think this will make the Mac better because now it can benefit from all the
product dev and R&D being done for iDevices, and vice versa. All those neat
features in the high end iPad can now be considered for the Mac.

It would not shock me if they someday allowed the Mac to run iPadOS either if
the user so chooses, or vice versa, via some reinstall process.

------
Ijumfs
>a new architecture has some bugs OR >turns out the person compiled the thing
with BSD make instead of gmake

------
Vosporos
Always use gmake.

