Set linkage of __crystal_* funs to internal

[ysbaddaden]

Unlike the usual fun for which we might expect to have external linkage, the __crystal_* funs are an internal implementation detail to abstract calls to stdlib from the codegen pass (e.g. __crystal_once, __crystal_raise, ...).

When compiling to a single module, we can mark them to have internal linkage, so they're only considered inside the object file. We already do that for all globals and def.

Related to #921

[ysbaddaden]

Interesting, darwin fails to link, for aarch64 and x86_64 alike:

         Undefined symbols for architecture arm64:
           "___crystal_personality", referenced from:
               _~proc2Proc(Pointer(Void), Pointer(Void), Nil)@src/gc/boehm.cr:331 in _main.o3.o
               _*IO::FileDescriptor#unbuffered_write<Slice(UInt8)>:Nil in _main.o3.o
               _*Crystal::System::Thread::current_thread:Thread in _main.o3.o
               _*Crystal::EventLoop::Polling::Arena(Crystal::EventLoop::Polling::PollDescriptor, 65536)@Crystal::EventLoop::Polling::Arena(T, BLOCK_BYTESIZE)#at<Int32, Bool>:Pointer(Crystal::EventLoop::Polling::Arena::Entry(Crystal::EventLoop::Polling::PollDescriptor)) in _main.o3.o
               _*Crystal::Scheduler#reschedule:Nil in _main.o3.o
               _*Exception::CallStack#printable_backtrace:Array(String) in _main.o3.o
               _*Exception::CallStack::decode_line_number<UInt64>:Tuple(String, Int32, Int32) in _main.o3.o
               ...
         ld: symbol(s) not found for architecture arm64
         clang-11: error: linker command failed with exit code 1 (use -v to see invocation)

All symbols are declared in the _main.o3.o object file, so it should also declare __crystal_personality and I don't see why it wouldn't be able to find it if it's internal 😕

[ysbaddaden]

$ nm ~/.cache/crystal/Users-runner-work-crystal-crystal-spec-std-data-collect_within_ensure/_main.o3.o | grep __crystal
0000000000000000 t ___crystal_main
0000000000000cb8 t ___crystal_personality
00000000000011dc t ___crystal_raise
0000000000001224 t ___crystal_raise_overflow

The symbol is in the object file, with internal linkage t). I'll try to list all the failing symbols. Maybe there's an external symbol in the list?

[ysbaddaden]

That seems to be a bug in macos ld 🤦

https://stackoverflow.com/questions/72566667/darwin-ld-stubbornly-wont-find-symbol-thats-defined-in-object-file-while-l

Is macos ruining support for #921? Yes.

Apparently it would only work with lld.

[ysbaddaden]

Since we use internal linkage for all defs, it might just be a bug with the personality function? 🤔

Confirmed: not making __crystal_personality internal fixes the ld issue on Darwin. Other funs don't have this issue.

I fail to link using cc -fuse-ld=ldd:

ld64.lld: warning: ignoring unknown argument: -platform_version
ld64.lld: warning: ignoring unknown argument: -no_uuid
ld64.lld: warning: -sdk_version is required when emitting min version load command.  Setting sdk version to match provided min version
Cannot open macos: No such file or directory

I notice that clang-11 injected -platform_version macos 11.0.0 0.0.0 into the ld command. That seems like the problem. Maybe it's working better with a newer llvm release but CI nix environment is still stuck to LLVM 11.

[straight-shoota]

That SO question is also about a personality function. So perhaps it's related to some quirk of exception handling on macos?

[ysbaddaden]

Yeah, it seems that personalities functions are an issue in mach-o in general:
rust-lang/rust#102754

Notably:

• ld64.lld: error: too many personalities (4) for compact unwind to encode rust-lang/rust#102754 (comment)
• ld64.lld: error: too many personalities (4) for compact unwind to encode rust-lang/rust#102754 (comment)