Because we currently just use the clang from the user's path linking
suddenly breaks when the user updates their system clang to 18 with an
error about an unknown option -arch.
I had already fixed it for my LLVM 18 PR but it seems like a good idea
to get this in already to avoid that breakage (had a few people come to
the Discord with it and an issue).
This fixes#3461
We did some profiling for #3343 and this seems to be the biggest
problem. `realpath` is expensive, and we are locking here for no reason
that I can think of.
This improves the "check procedure bodies" timing (of the linked issue)
from 2.4s to .4s on my machine.
After #3316 we set a default minimum version, now this will warn if you
link with a library that is targeting later versions.
This might be a bit annoying, especially when the user hasn't actually
given Odin a minimum target.
So this PR makes these warnings only show when you explicitly give a
target version (afaik that is the only thing that -mmacosx-min-version
actually does for us because we don't use it to compile anything, just
to link).
`path_to_fullpath` did different things on Windows&Unix, an attempt to
bring them closer together was made here.
This was prompted by the compiler completely ignoring
`foreign import "foo.dylib"` when `foo.dylib` does not exist (because
`path_to_fullpath` returns an empty string).
Causing just unresolved symbol errors, when on Windows it would pass
along the path to the linker and actually say it doesn't exist, which
is now also the case for Unix.
This also fixes some checker errors that relied on the Windows
behaviour, for example: `Error: File name, , cannot be as a library name
as it is not a valid identifier`.
Made `-no-crt` require either `-default-to-nil-allocator` or
`-default-to-panic-allocator` on Unix, the current default allocators
rely on libc and this was not obvious and would immediately bring up
unresolved symbol errors for the linked memory management functions, or
just link with libc anyways because it was foreign imported.
Added a suggestion to install `nasm` with the user's package manager
when assembling using `nasm` fails on Unix, I saw some confusion about
it in the Discord.
Ignore explicit foreign imports of libc. It is already linked in later
on in the linking process and would otherwise (at least on macOS) cause
linker warnings for duplicate libraries. This also makes it so when
using `-no-crt` and importing something that requires libc, linker
errors are given (like I would expect), instead of silently still
linking with libc because it was foreign imported.
W:\Odin>odin run sketch.odin -file -subsystem:foo
Invalid -subsystem string, got oo. Expected one of:
BOOT_APPLICATION, CONSOLE (default), EFI_APPLICATION, EFI_BOOT_SERVICE_DRIVER, EFI_ROM, EFI_RUNTIME_DRIVER, NATIVE, POSIX, WINDOWS (or WINDOW), WINDOWSCE
We now also set the constant ODIN_WINDOWS_SUBSYSTEM, which is "" for non-Windows targets.
`llvm_features` being empty is the default state, and implies the
presence of certain features.
Previously if any target features were explicitly enabled by the
`enable_target_feature` attribute, they were added comma separated
to `llvm_features`.
For example: `lzcnt,popcnt,...,sse4.2,sse`
This was causing LLVM to try to target a CPU that *ONLY* has the
explicitly enabled features. This now will prefix explicitly enabled
features with a `+`, and preserve the existing `llvm_features` string
by appending to it if it is set.
gingerBill
Feoramund
Laytan Laats
Thomas la Cour
gingerBill
avanspector
Jeroen van Rijn
codename-irvin
Yawning Angel