Question about make std_spec

femto · January 10, 2024, 6:01am

tried lastest commit on master

make && make std_spec          
Using /usr/local/opt/llvm/bin/llvm-config [version= 17.0.6]
c++ -c  -o src/llvm/ext/llvm_ext.o src/llvm/ext/llvm_ext.cc -I/usr/local/Cellar/llvm/17.0.6/include -std=c++17 -stdlib=libc++   -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS
CRYSTAL_CONFIG_BUILD_COMMIT="0b57b6cc8" CRYSTAL_CONFIG_PATH='$ORIGIN/../share/crystal/src' SOURCE_DATE_EPOCH="1704818267"  CRYSTAL_CONFIG_LIBRARY_PATH='$ORIGIN/../lib/crystal' ./bin/crystal build -D strict_multi_assign -D preview_overload_order -Dwithout_interpreter  -o .build/crystal src/compiler/crystal.cr -D without_openssl -D without_zlib -D use_pcre2
ld: warning: dylib (/usr/local/Cellar/llvm/17.0.6/lib/libunwind.dylib) was built for newer macOS version (12.6) than being linked (12.0)
ld: warning: dylib (/usr/local/Cellar/llvm/17.0.6/lib/libunwind.dylib) was built for newer macOS version (12.6) than being linked (12.0)
ld: warning: dylib (/usr/local/Cellar/llvm/17.0.6/lib/libunwind.dylib) was built for newer macOS version (12.6) than being linked (12.0)
ld: warning: dylib (/usr/local/Cellar/llvm/17.0.6/lib/libunwind.dylib) was built for newer macOS version (12.6) than being linked (12.0)
Using /usr/local/opt/llvm/bin/llvm-config [version= 17.0.6]
./bin/crystal build -D strict_multi_assign -D preview_overload_order -Dwithout_interpreter  --exclude-warnings spec/std --exclude-warnings spec/compiler --exclude-warnings spec/primitives -o .build/std_spec spec/std_spec.cr
Using compiled compiler at .build/crystal
ld: warning: dylib (/usr/local/Cellar/llvm/17.0.6/lib/libunwind.dylib) was built for newer macOS version (12.6) than being linked (12.0)
ld: warning: dylib (/usr/local/Cellar/llvm/17.0.6/lib/libunwind.dylib) was built for newer macOS version (12.6) than being linked (12.0)
ld: warning: dylib (/usr/local/Cellar/llvm/17.0.6/lib/libunwind.dylib) was built for newer macOS version (12.6) than being linked (12.0)
ld: warning: dylib (/usr/local/Cellar/llvm/17.0.6/lib/libunwind.dylib) was built for newer macOS version (12.6) than being linked (12.0)
.build/std_spec --order=random   
0.2.5
Randomized with seed: 24319

what’s the ld warning and why is that?

michaels · August 6, 2025, 7:34am

I’m a relatively new crystal user and found a similar thing just running a simple test Kemal app. I’m on Mac OS 15.5 and upon compiling (for a run) I get loads of ld: warnings like “was built for newer macOS version (15.0) than being linked (13.3)”, e.g. below.. is there a way to suppress these?

ld: warning: object file (H-T-T-P-5858F-ormD-ata.o0.o) was built for newer macOS version (15.0) than being linked (13.3)
ld: warning: object file (P-ointer40H-ash58-ae15d8163d21c417f1fc491f0bbc15a1.o0.o) was built for newer macOS version (15.0) than being linked (13.3)
ld: warning: object file (H-T-T-P-5858F-ormD-ata5858P-arser.o0.o) was built for newer macOS version (15.0) than being linked (13.3)
ld: warning: ld: warning: object file (M-I-M-E-5858M-ultipart5858P-arser.o0.o) was built for newer macOS version (15.0) than being linked (13.3)
ld: warning: object file (M-I-M-E-5858M-ultipart.o0.o) was built for newer macOS version (15.0) than being linked (13.3)
ld: warning: object file (M-I-M-E-5858M-ultipart5858S-tate.o0.o) was built for newer macOS version (15.0) than being linked (13.3)
ld: warning: object file (H-T-T-P-5858F-ormD-ata5858P-art.o0.o) was built for newer macOS version (15.0) than being linked (13.3)

Thanks.

HertzDevil · August 6, 2025, 8:49am

This should have been fixed in the latest version of Crystal

michaels · August 6, 2025, 11:10am

Thanks for the quick reply. I checked the version I used, and it was 1.17.1.

ysbaddaden · August 6, 2025, 1:59pm

Apparently the MACOS_DEPLOYMENT_TARGET environment variable isn’t enough

github.com/crystal-lang/crystal

Respect `$MACOSX_DEPLOYMENT_TARGET` on macOS hosts

master ← HertzDevil:feature/macosx-deployment-target

opened 05:08PM - 25 Mar 25 UTC

HertzDevil

+25 -0

Fixes #15130. On a macOS host, if the `MACOSX_DEPLOYMENT_TARGET` environment …variable is set, that value now overrides the host triple's environment component: ```sh $ bin/crystal eval 'p Crystal::HOST_TRIPLE' "aarch64-apple-darwin24.3.0" $ MACOSX_DEPLOYMENT_TARGET=10.11 bin/crystal eval 'p Crystal::HOST_TRIPLE' "aarch64-apple-macosx10.11" $ MACOSX_DEPLOYMENT_TARGET=13.0 bin/crystal eval 'p Crystal::HOST_TRIPLE' "aarch64-apple-macosx13.0" ``` (`darwin24.3.0` corresponds to `macosx15.0`; [this is how LLVM converts the former into the latter](https://github.com/llvm/llvm-project/blob/6ddc07163d6c781622384eb83c7220d3051243a6/llvm/lib/TargetParser/Triple.cpp#L1427-L1470).)

michaels · August 7, 2025, 8:39am

should I raise a separate github issue about this, or is the above one which has a bot message referring to this message enough?

I also wonder when compiling on the mac, would it be necessary to set an env variable to suppress these (amongst other things)?

ysbaddaden · August 7, 2025, 10:06am

Let’s try to figure out what’s happening here. Is $MACOSX_DEPLOYMENT_TARGET defined on your system? Or maybe they renamed it as $MACOS_DEPLOYMENT_TARGET (no X)?

Or maybe the linker defaults to macOS 13.3 but the environment variable isn’t set, so we build the objects for the current host triple, which then leads to the mismatch warnings?

poke @HertzDevil

michaels · August 7, 2025, 10:27pm

Sorry, I wanted to reply to the other post, but being a new user I was limited to 3 replies on that topic, so I’ve raised a new one to reply.

In that other post I was reporting why when doing ‘crystal run ..’ I would see so many of the following warnings:

ld: warning: object file (…o0.o) was built for newer macOS version (15.0) than being linked (11.0)

it was suggested by @ysbaddaden that I might need to set the env var $MACOSX_DEPLOYMENT_TARGET and I did set it to “15.5”, and reran, and found that the warnings were suppressed, which is great. However as a new crystal user, I think this is not very intuitive and wonder about the need to see those messages. Why would it be necessary to set this var? Is it possible to invert the situation so those are suppressed by default and enable a var or flag to show those? Thanks.

ysbaddaden · August 8, 2025, 8:49am

I wasn’t asking to export the variable. I’m trying to understand why the linker is complaining on your mac, and figure out what we should do to determine the linker’s default deployment target… or maybe we should tell the linker to target the current target, for example by setting $MACOSX_DEPLOYMENT_TARGET or through an argument?

I assume echo $MACOSX_DEPLOYMENT_TARGET doesn’t print anything by default?

michaels · August 9, 2025, 12:02am

Apologies. Yes, echo $MACOSX_DEPLOYMENT_TARGET prints nothing by default. I’ve just tested it again on a brand new MacBook (MacOS 15.3.1) and after installing Crystal 1.17.1 via homebrew, and there is no $MACOSX_DEPLOYMENT_TARGET or $MACOS_DEPLOYMENT_TARGET variables.

Sija · August 9, 2025, 1:03am

$MACOSX_DEPLOYMENT_TARGET variable needs to be set manually.

See Always set `MACOSX_DEPLOYMENT_TARGET` in build scripts · Issue #13115 · rust-lang/cargo · GitHub

michaels · August 10, 2025, 1:51am

I realise this is pretty minor, so feel free to ignore - but as someone coming into Crystal from scratch (and coming from Windows also), perhaps this should be documented. There’s no mention of the env variable on the Mac install page, nor this doc page about env vars, though it seems from the above reply having this env var available may be an assumed thing for general development, so apologies if I’m just ignorant to that

ysbaddaden · August 15, 2025, 2:08pm

Do not apologize, we just thought the warnings got finally fixed, but they were not

Maybe we should do the opposite, like define the env variable from the target triplet given by, and maybe have some safe fallback? The Rust cc crate does that for example… and Rust itself does it too; it falls back to these defaults:

github.com/rust-lang/rust

compiler/rustc_target/src/spec/base/apple/mod.rs

ba412a6e7


      
          pub fn os_minimum_deployment_target(os: &str) -> Self {
              // When bumping a version in here, remember to update the platform-support docs too.
              //
              // NOTE: The defaults may change in future `rustc` versions, so if you are looking for the
              // default deployment target, prefer:
              // ```
              // $ rustc --print deployment-target
              // ```
              let (major, minor, patch) = match os {
                  "macos" => (10, 12, 0),
                  "ios" => (10, 0, 0),
                  "tvos" => (10, 0, 0),
                  "watchos" => (5, 0, 0),
                  "visionos" => (1, 0, 0),
                  _ => unreachable!("tried to get deployment target for non-Apple platform"),
              };
              Self { major, minor, patch }
          }

And this is where we should make the change: crystal/src/compiler/crystal/config.cr at aa89b919d7d4310af9e61fb2f44c65a4cb0f9645 · crystal-lang/crystal · GitHub.

ysbaddaden · August 15, 2025, 2:10pm

Do you get issues if you set MACOSX_DEPLOYMENT_TARGET=10.12 for example?

michaels · August 15, 2025, 9:14pm

Thanks. I tried setting to 10.12, and still see warnings, e.g. the following for a simple ‘hello world’ kemal app.

ld: warning: dylib (/opt/homebrew/lib/libgc.dylib) was built for newer macOS version (15.0) than being linked (11.0)
ld: warning: dylib (/opt/homebrew/lib/libpcre2-8.dylib) was built for newer macOS version (13.0) than being linked (11.0)
ld: warning: dylib (/opt/homebrew/lib/libssl.dylib) was built for newer macOS version (15.0) than being linked (11.0)
ld: warning: dylib (/opt/homebrew/lib/libcrypto.dylib) was built for newer macOS version (15.0) than being linked (11.0)

I also tried 11.0 and 13.0 with same result, but setting to 15.0 was good (no warnings). Thanks again.

ysbaddaden · August 16, 2025, 5:31pm

Oh, Homebrew compiled the libraries for 15.0 so Crystal’s objects must also be compiled for 15.0 or later —except for PCRE2 which targets 13.0 but

I was thinking that maybe the crystal formula for Homebrew should set the MACOSX_DEPLOYMENT_TARGET and… that’s exactly what the rust formula does.

I guess we should do both:

fallback to a default version when MACOS_DEPLOYMENT_TARGET is unset (or blank);
fix the homebrew formula to set MACOS_DEPLOYMENT_TARGET to the current macOS version.

Topic		Replies	Views
Install Crystal on Mac M1 Help & Support	28	4452	December 4, 2021
Building compiler on Mac OS Help & Support	1	324	January 7, 2022
Llvm_config on macos (newbie in trouble) Help & Support	8	847	February 13, 2023
Running Crystal on Termux Crystal Contrib	12	3036	July 17, 2022
Specs on Crystal 0.36.0 are taking a LONG time Help & Support	22	961	February 3, 2021

Question about make std_spec

Related topics