Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

macOS builds fail with segmentation fault #204

Closed
pavelzw opened this issue Aug 2, 2024 · 28 comments
Closed

macOS builds fail with segmentation fault #204

pavelzw opened this issue Aug 2, 2024 · 28 comments
Labels

Comments

@pavelzw
Copy link
Member

pavelzw commented Aug 2, 2024

  error: linking with `x86_64-apple-darwin13.4.0-clang` failed: exit status: 1
    |
    = note: env -u IPHONEOS_DEPLOYMENT_TARGET -u TVOS_DEPLOYMENT_TARGET -u XROS_DEPLOYMENT_TARGET LC_ALL="C" PATH="/Users/runner/miniforge3/conda-bld/polars-lts-cpu_1722408137853/_build_env/lib/rustlib/x86_64-apple-darwin/bin:/Users/runner/miniforge3/conda-bld/polars-lts-cpu_1722408137853/_build_env/lib/rustlib/x86_64-apple-darwin/bin:/Users/runner/miniforge3/conda-bld/polars-lts-cpu_1722408137853/_build_env/lib/rustlib/x86_64-apple-darwin/bin:/Users/runner/miniforge3/conda-bld/polars-lts-cpu_1722408137853/_build_env/.cargo/bin:/Users/runner/miniforge3/conda-bld/polars-lts-cpu_1722408137853/_build_env/bin:/Users/runner/miniforge3/conda-bld/polars-lts-cpu_1722408137853/_h_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_plac/bin:/Users/runner/miniforge3/condabin:/Users/runner/miniforge3/conda-bld/polars-lts-cpu_1722408137853/_build_env/bin:/Users/runner/miniforge3/conda-bld/polars-lts-cpu_1722408137853/_h_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_plac/bin:/Users/runner/miniforge3/bin:/Users/runner/miniforge3/condabin:/usr/local/lib/ruby/gems/3.0.0/bin:/usr/local/opt/ruby@3.0/bin:.:/usr/local/bin:/usr/local/sbin:/Users/runner/bin:/Library/Frameworks/Python.framework/Versions/Current/bin:/Library/Frameworks/Mono.framework/Versions/Current/Commands:/usr/bin:/bin:/usr/sbin:/sbin:/Users/runner/.ghcup/bin" VSLANG="1033" ZERO_AR_DATE="1" "x86_64-apple-darwin13.4.0-clang" "-Wl,-exported_symbols_list" "-Wl,/tmp/rustc9NlPz9/list" "-arch" "x86_64" "-m64" "/tmp/rustc9NlPz9/symbols.o" "/Users/runner/miniforge3/conda-bld/polars-lts-cpu_1722408137853/work/target/release/deps/futures_macro-a552ce95a8df1c11.futures_macro.3a5e75ff85bfe645-cgu.0.rcgu.o" "/Users/runner/miniforge3/conda-bld/polars-lts-cpu_1722408137853/work/target/release/deps/futures_macro-a552ce95a8df1c11.futures_macro.3a5e75ff85bfe645-cgu.1.rcgu.o" "/Users/runner/miniforge3/conda-bld/polars-lts-cpu_1722408137853/work/target/release/deps/futures_macro-a552ce95a8df1c11.futures_macro.3a5e75ff85bfe645-cgu.2.rcgu.o" "/Users/runner/miniforge3/conda-bld/polars-lts-cpu_1722408137853/work/target/release/deps/futures_macro-a552ce95a8df1c11.futures_macro.3a5e75ff85bfe645-cgu.3.rcgu.o" "/Users/runner/miniforge3/conda-bld/polars-lts-cpu_1722408137853/work/target/release/deps/futures_macro-a552ce95a8df1c11.futures_macro.3a5e75ff85bfe645-cgu.4.rcgu.o" "/Users/runner/miniforge3/conda-bld/polars-lts-cpu_1722408137853/work/target/release/deps/futures_macro-a552ce95a8df1c11.futures_macro.3a5e75ff85bfe645-cgu.5.rcgu.o" "/Users/runner/miniforge3/conda-bld/polars-lts-cpu_1722408137853/work/target/release/deps/futures_macro-a552ce95a8df1c11.4xahsrxaq6eulzlyhye2fskmg.rcgu.rmeta" "/Users/runner/miniforge3/conda-bld/polars-lts-cpu_1722408137853/work/target/release/deps/futures_macro-a552ce95a8df1c11.0nq2p0kze3qhyiuiczx3bg3iu.rcgu.o" "-L" "/Users/runner/miniforge3/conda-bld/polars-lts-cpu_1722408137853/work/target/release/deps" "-L" "/Users/runner/miniforge3/conda-bld/polars-lts-cpu_1722408137853/_build_env/lib/rustlib/x86_64-apple-darwin/lib" "/Users/runner/miniforge3/conda-bld/polars-lts-cpu_1722408137853/work/target/release/deps/libsyn-b5089cdac6dd7ef9.rlib" "/Users/runner/miniforge3/conda-bld/polars-lts-cpu_1722408137853/work/target/release/deps/libquote-1f5d4efab93da96c.rlib" "/Users/runner/miniforge3/conda-bld/polars-lts-cpu_1722408137853/work/target/release/deps/libproc_macro2-68a6686f63f1e88e.rlib" "/Users/runner/miniforge3/conda-bld/polars-lts-cpu_1722408137853/work/target/release/deps/libunicode_ident-58dc0c689a7909ef.rlib" "/Users/runner/miniforge3/conda-bld/polars-lts-cpu_1722408137853/_build_env/lib/rustlib/x86_64-apple-darwin/lib/libproc_macro-ca54877308a7194d.rlib" "/Users/runner/miniforge3/conda-bld/polars-lts-cpu_1722408137853/_build_env/lib/rustlib/x86_64-apple-darwin/lib/libstd-37e0369a2e96ba5c.rlib" "/Users/runner/miniforge3/conda-bld/polars-lts-cpu_1722408137853/_build_env/lib/rustlib/x86_64-apple-darwin/lib/libpanic_unwind-ad975f3dcb44fde5.rlib" "/Users/runner/miniforge3/conda-bld/polars-lts-cpu_1722408137853/_build_env/lib/rustlib/x86_64-apple-darwin/lib/libobject-5583c7401bdfb39a.rlib" "/Users/runner/miniforge3/conda-bld/polars-lts-cpu_1722408137853/_build_env/lib/rustlib/x86_64-apple-darwin/lib/libmemchr-862d8e01ae0e34c4.rlib" "/Users/runner/miniforge3/conda-bld/polars-lts-cpu_1722408137853/_build_env/lib/rustlib/x86_64-apple-darwin/lib/libaddr2line-ec7590c3536cb5fe.rlib" "/Users/runner/miniforge3/conda-bld/polars-lts-cpu_1722408137853/_build_env/lib/rustlib/x86_64-apple-darwin/lib/libgimli-8aa07db820c8a8b0.rlib" "/Users/runner/miniforge3/conda-bld/polars-lts-cpu_1722408137853/_build_env/lib/rustlib/x86_64-apple-darwin/lib/librustc_demangle-14f82d799646defa.rlib" "/Users/runner/miniforge3/conda-bld/polars-lts-cpu_1722408137853/_build_env/lib/rustlib/x86_64-apple-darwin/lib/libstd_detect-1af0fc86d5f75f9c.rlib" "/Users/runner/miniforge3/conda-bld/polars-lts-cpu_1722408137853/_build_env/lib/rustlib/x86_64-apple-darwin/lib/libhashbrown-82188f1e5aa6f33f.rlib" "/Users/runner/miniforge3/conda-bld/polars-lts-cpu_1722408137853/_build_env/lib/rustlib/x86_64-apple-darwin/lib/librustc_std_workspace_alloc-7d7696bfc68c958a.rlib" "/Users/runner/miniforge3/conda-bld/polars-lts-cpu_1722408137853/_build_env/lib/rustlib/x86_64-apple-darwin/lib/libminiz_oxide-c7064bbd5a7a4483.rlib" "/Users/runner/miniforge3/conda-bld/polars-lts-cpu_1722408137853/_build_env/lib/rustlib/x86_64-apple-darwin/lib/libadler-82ef549ebdeddc38.rlib" "/Users/runner/miniforge3/conda-bld/polars-lts-cpu_1722408137853/_build_env/lib/rustlib/x86_64-apple-darwin/lib/libunwind-67c0acc6d6e53ad5.rlib" "/Users/runner/miniforge3/conda-bld/polars-lts-cpu_1722408137853/_build_env/lib/rustlib/x86_64-apple-darwin/lib/libcfg_if-35baf614233bd398.rlib" "/Users/runner/miniforge3/conda-bld/polars-lts-cpu_1722408137853/_build_env/lib/rustlib/x86_64-apple-darwin/lib/liblibc-18c2355194dd9ece.rlib" "/Users/runner/miniforge3/conda-bld/polars-lts-cpu_1722408137853/_build_env/lib/rustlib/x86_64-apple-darwin/lib/liballoc-8fe7af61f49bf77b.rlib" "/Users/runner/miniforge3/conda-bld/polars-lts-cpu_1722408137853/_build_env/lib/rustlib/x86_64-apple-darwin/lib/librustc_std_workspace_core-b573430062f6bfe5.rlib" "/Users/runner/miniforge3/conda-bld/polars-lts-cpu_1722408137853/_build_env/lib/rustlib/x86_64-apple-darwin/lib/libcore-ef02792cbce15279.rlib" "/Users/runner/miniforge3/conda-bld/polars-lts-cpu_1722408137853/_build_env/lib/rustlib/x86_64-apple-darwin/lib/libcompiler_builtins-9bc9296e99b3aad8.rlib" "-lSystem" "-lc" "-lm" "-L" "/Users/runner/miniforge3/conda-bld/polars-lts-cpu_1722408137853/_build_env/lib/rustlib/x86_64-apple-darwin/lib" "-o" "/Users/runner/miniforge3/conda-bld/polars-lts-cpu_1722408137853/work/target/release/deps/libfutures_macro-a552ce95a8df1c11.dylib" "-Wl,-dead_strip" "-dynamiclib" "-Wl,-dylib" "-nodefaultlibs"
    = note: clang-16: error: unable to execute command: Segmentation fault: 11
            clang-16: error: linker command failed due to signal (use -v to see invocation)


  error: could not compile `futures-macro` (lib) due to 1 previous error
  warning: build failed, waiting for other jobs to finish...
  💥 maturin failed
    Caused by: Failed to build a native library through cargo
    Caused by: Cargo build finished with "exit status: 101": `env -u CARGO PYO3_ENVIRONMENT_SIGNATURE="cpython-3.10-64bit" PYO3_PYTHON="/Users/runner/miniforge3/conda-bld/polars-lts-cpu_1722408137853/_h_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_plac/bin/python" PYTHON_SYS_EXECUTABLE="/Users/runner/miniforge3/conda-bld/polars-lts-cpu_1722408137853/_h_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_plac/bin/python" "cargo" "rustc" "--target" "x86_64-apple-darwin" "--message-format" "json-render-diagnostics" "--manifest-path" "/Users/runner/miniforge3/conda-bld/polars-lts-cpu_1722408137853/work/py-polars/Cargo.toml" "--release" "--lib" "--" "-C" "link-arg=-undefined" "-C" "link-arg=dynamic_lookup" "-C" "link-args=-Wl,-install_name,@rpath/polars.abi3.so"`
  Error: command ['maturin', 'pep517', 'build-wheel', '-i', '/Users/runner/miniforge3/conda-bld/polars-lts-cpu_1722408137853/_h_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_plac/bin/python', '--compatibility', 'off'] returned non-zero exit status 1
  error: subprocess-exited-with-error
  
  × Building wheel for polars-lts-cpu (pyproject.toml) did not run successfully.
  │ exit code: 1
  ╰─> See above for output.

from conda-forge/polars-feedstock#253 (comment)

@0xbe7a
Copy link
Member

0xbe7a commented Aug 9, 2024

It appears that the same issue is occurring with jnv. See conda-forge/jnv-feedstock#2. Is this an issue with the clang toolchain? @conda-forge/clang-compiler-activation

@h-vetinari
Copy link
Member

This seems to be more likely a question of the rust setup to me, as it's happening during rust compilation.

The log

clang-16: error: unable to execute command: Segmentation fault: 11

doesn't tell me anything what failed.

In the jnv failure there's at least one more tidbit:

  = note: ld: warning: directory not found for option '-L$PREFIX/lib'

which could be explained by the fact that the jnv recipe specifies no host environment

@h-vetinari
Copy link
Member

I reran the CI for conda-forge/jnv-feedstock#2 and it seems to pass now. Not sure if conda-forge/rust-activation-feedstock#60 had something to do with it. The release notes mention a miscompilation when comparing floats; no idea if that's applicable in the cases above.

@setu4993
Copy link
Member

Still running into the same on conda-forge/tokenizers-feedstock#70 for the Python 3.8 MacOS build.

@h-vetinari
Copy link
Member

Still running into the same on conda-forge/tokenizers-feedstock#70 for the Python 3.8 MacOS build.

Interesting that this only happens with py38, that looks like it involves at least one other problem. Since py38 is about to be dropped in 2 month, I'd be fairly liberal in dropping those builds though. 🤷

@setu4993
Copy link
Member

With @h-vetinari's help, we got conda-forge/tokenizers-feedstock#70 atleast resolved and merged, but I did see CI fail for MacOS on Python 3.12 atleast once, so I suspect this is likely flaky and maybe broader than just Python 3.8. It could also be caching at some layer for an older image causing it, but I'm not confident.

@0xbe7a
Copy link
Member

0xbe7a commented Aug 15, 2024

@xhochy
Copy link
Member

xhochy commented Aug 20, 2024

Should we move this to the rust(-activation) feedstock?

@bollwyvl
Copy link

Has anyone tried using conda-forge/label/rust_dev to see if it's just a bad version on conda-forge?

@0xbe7a
Copy link
Member

0xbe7a commented Aug 26, 2024

Has anyone tried using conda-forge/label/rust_dev to see if it's just a bad version on conda-forge?

Yes, Polars is using rust_dev and still experienced this issue when not patching the syn version.

@baszalmstra
Copy link
Member

Is there any update with regard to this issue? Any workarounds?

@bollwyvl
Copy link

bollwyvl commented Sep 4, 2024

Thus far have had success downgrading to the MSRV of the upstream, if available/documented/can be inferred from their CI, e.g.:

# conda_build_config.yaml
rust_compiler_version:  # [osx]
  - "1.74"              # [osx]

Some feedstocks (like uv) haven't had any issues with the latest version on main. Without an fruitbox, or a particularly deep knowledge of rust, this is the best I've been able to do.

@xhochy
Copy link
Member

xhochy commented Sep 4, 2024

This only happens with osx-64, not if the build is run using osx-arm64.

Sadly lldb is quite silent:

% lldb /Users/uwe/Development/conda-forge/ruff-feedstock/miniforge3/conda-bld/ruff_1725476454375/_build_env/bin/x86_64-apple-darwin13.4.0-clang -c /cores/core.64352
(lldb) target create "/Users/uwe/Development/conda-forge/ruff-feedstock/miniforge3/conda-bld/ruff_1725476454375/_build_env/bin/x86_64-apple-darwin13.4.0-clang" --core "/cores/core.64352"
Core file '/cores/core.64352' (arm64) was loaded.
(lldb) bt
* thread #1, stop reason = ESR_EC_DABORT_EL0 (fault address: 0x726f63344e5a5fbf)
  * frame #0: 0x0000000102984c94
(lldb) bt all
* thread #1, stop reason = ESR_EC_DABORT_EL0 (fault address: 0x726f63344e5a5fbf)
  * frame #0: 0x0000000102984c94
  thread #2
    frame #0: 0x00007ff7ffdd3414
    frame #1: 0x00007ff7ffddf164
    frame #2: 0x00007ff7ffde0a80
(lldb)

@pkgw
Copy link
Contributor

pkgw commented Sep 4, 2024

I was able to poke around a bit. The culprit seems to be the -Wl,-exported_symbols_list,... argument: if I rerun the link step without that argument, no crash.

In my particular sample build of pixi, the contents of that list file are trivial:

___rustc_proc_macro_decls_9059548e8b173a1d__
_rust_metadata_darling_macro_9059548e8b173a1d

(I was able to debug this by manually activating the build environment using build_env_setup.sh, emulating the setup of the recipe build.sh, and then setting $CARGO_TARGET_X86_64_APPLE_DARWIN_LINKER to a one-off wrapper shell script.)

I'll fool around a bit more but it doesn't look like Rust is doing anything incredibly unreasonable here — I think we are uncovering a weird Clang ld crash.

update: Even if the list file is completely empty, I get the segfault. So it looks like the problem is with the fundamental handling of that argument.

Also, if I pass the argument directly without the -Wl, it still crashes.

@pkgw
Copy link
Contributor

pkgw commented Sep 4, 2024

I was able to attach an lldb to the underlying ld process and identify that the crash is happening in a function ld::passes::order::Layout::Comparer::operator(). I don't know how to use lldb though so that's as far as I'm able to take it (for now).

Web searching doesn't pull up any obvious reports of crashes associated with -exported_symbols_list or this function. So my best guess now is that somewhere in the link line, one of the input files contains some kind of cursed symbol, and that the -exported_symbols_list argument causes ld to scan over all of the input symbols in a way that it wouldn't normally do, causing it to crash.

update: If I use /usr/bin/ld instead of $BUILD/bin/x86_64_apple-darwin13.4.0-ld, there's no crash. I don't understand the toolchain situation well enough to know if that's interesting or not.

update 2: OK, if I reorder the project .rlib dependencies in various ways, the crash goes away?? E.g., if I move the libstrsim-(yadda).rlib dependency just a few slots later in the link list, the manual ld invocation works. Not at all clear to me what's changing.

@h-vetinari
Copy link
Member

If I use /usr/bin/ld instead of $BUILD/bin/x86_64_apple-darwin13.4.0-ld, there's no crash. I don't understand the toolchain situation well enough to know if that's interesting or not.

That $BUILD/bin/x86_64_apple-darwin13.4.0-ld is packaged here, and it's not impossible that there's a bug in this implementation. I say this because when we briefly enabled "hardened" libcxx builds that trap on certain classes of undefined behaviour (c.f. here), ld ended up failing on osx in some cases. But even if that's the case, it's not clear to me where the error is coming from, and also the most recent version update for that feedstock is stuck.

@pkgw
Copy link
Contributor

pkgw commented Sep 4, 2024

@h-vetinari I am leaning towards agreeing that it's a bug in this build of ld. I don't see how reordering the input files can cause things to go from "crash" to "no crash" in any non-pathological scenario.

FWIW, the ld that crashes is indeed version ld64-711 from July 2024, according to its -v output. My system version — which doesn't crash — is ld64-609.8 from December 2020. But I note that the newer tool reports using "Apple TAPI version 11.0.0 (tapi-1100.0.11)", while the older system tool reports "Apple TAPI version 12.0.0 (tapi-1200.0.23.5)". I have no idea what TAPI is (and Google reveals absolutely nothing) but I am quite surprised to see the linked version go backwards.

I'm about to wander over to the NumFOCUS project summit so that will be the end of my flailing around today.

@h-vetinari
Copy link
Member

But I note that the newer tool reports using "Apple TAPI version 11.0.0 (tapi-1100.0.11)", while the older system tool reports "Apple TAPI version 12.0.0 (tapi-1200.0.23.5)".

Indeed, neither do I know what TAPI does (though ld64 is the only package depending on it). I had proposed an update in conda-forge/tapi-feedstock#10 a while ago, which seems to have come to life just now.

@isuruf
Copy link
Member

isuruf commented Sep 4, 2024

TAPI is a library to read .tbd and creating .tbd files from .dylib files.

@xhochy
Copy link
Member

xhochy commented Sep 5, 2024

Full backtrace:

(lldb) target create "/Users/uwe/conda-bld/ruff_1725524133335/_build_env/bin/x86_64-apple-darwin13.4.0-clang" --core "/cores/core.28365"
Core file '/cores/core.28365' (x86_64) was loaded.
(lldb) bt all
* thread #1
  * frame #0: 0x0000000100ae7fed x86_64-apple-darwin13.4.0-ld`void std::__1::__introsort<std::__1::_ClassicAlgPolicy, ld::passes::order::Layout::Comparer&, ld::Atom const**, false>(ld::Atom const**, ld::Atom const**, ld::passes::order::Layout::Comparer&, std::__1::iterator_traits<ld::Atom const**>::difference_type, bool) + 973
    frame #1: 0x0000000100ae7de6 x86_64-apple-darwin13.4.0-ld`void std::__1::__introsort<std::__1::_ClassicAlgPolicy, ld::passes::order::Layout::Comparer&, ld::Atom const**, false>(ld::Atom const**, ld::Atom const**, ld::passes::order::Layout::Comparer&, std::__1::iterator_traits<ld::Atom const**>::difference_type, bool) + 454
    frame #2: 0x0000000100ae7de6 x86_64-apple-darwin13.4.0-ld`void std::__1::__introsort<std::__1::_ClassicAlgPolicy, ld::passes::order::Layout::Comparer&, ld::Atom const**, false>(ld::Atom const**, ld::Atom const**, ld::passes::order::Layout::Comparer&, std::__1::iterator_traits<ld::Atom const**>::difference_type, bool) + 454
    frame #3: 0x0000000100ae6cc5 x86_64-apple-darwin13.4.0-ld`ld::passes::order::Layout::doPass() + 149
    frame #4: 0x0000000100ae6dca x86_64-apple-darwin13.4.0-ld`ld::passes::order::doPass(Options const&, ld::Internal&) + 170
    frame #5: 0x0000000100886542 x86_64-apple-darwin13.4.0-ld`main + 1026
    frame #6: 0x00007ff800a3f345 dyld`start + 1909

@h-vetinari
Copy link
Member

Hopefully conda-forge/cctools-and-ld64-feedstock#74 changes something 🤞

@xhochy
Copy link
Member

xhochy commented Sep 5, 2024

I have built the linked PR locally and rerun the ruff build, but I still get the same stacktrace:

% lldb $(which x86_64-apple-darwin13.4.0-clang) -c /cores/core.53820
(lldb) target create "/Users/uwe/conda-bld/ruff_1725535464874/_build_env/bin/x86_64-apple-darwin13.4.0-clang" --core "/cores/core.53820"
Core file '/cores/core.53820' (x86_64) was loaded.
(lldb) bt all
* thread #1
  * frame #0: 0x000000010d0dde1d x86_64-apple-darwin13.4.0-ld`void std::__1::__introsort<std::__1::_ClassicAlgPolicy, ld::passes::order::Layout::Comparer&, ld::Atom const**, false>(ld::Atom const**, ld::Atom const**, ld::passes::order::Layout::Comparer&, std::__1::iterator_traits<ld::Atom const**>::difference_type, bool) + 973
    frame #1: 0x000000010d0ddc16 x86_64-apple-darwin13.4.0-ld`void std::__1::__introsort<std::__1::_ClassicAlgPolicy, ld::passes::order::Layout::Comparer&, ld::Atom const**, false>(ld::Atom const**, ld::Atom const**, ld::passes::order::Layout::Comparer&, std::__1::iterator_traits<ld::Atom const**>::difference_type, bool) + 454
    frame #2: 0x000000010d0ddc16 x86_64-apple-darwin13.4.0-ld`void std::__1::__introsort<std::__1::_ClassicAlgPolicy, ld::passes::order::Layout::Comparer&, ld::Atom const**, false>(ld::Atom const**, ld::Atom const**, ld::passes::order::Layout::Comparer&, std::__1::iterator_traits<ld::Atom const**>::difference_type, bool) + 454
    frame #3: 0x000000010d0dcaf5 x86_64-apple-darwin13.4.0-ld`ld::passes::order::Layout::doPass() + 149
    frame #4: 0x000000010d0dcbfa x86_64-apple-darwin13.4.0-ld`ld::passes::order::doPass(Options const&, ld::Internal&) + 170
    frame #5: 0x000000010ce7c952 x86_64-apple-darwin13.4.0-ld`main + 1026
    frame #6: 0x00007ff800a3f345 dyld`start + 1909

@h-vetinari
Copy link
Member

Has anyone tried if an older ld64 version still works?! It's conceivable that this is a bug in v907 specifically.

@mdekstrand
Copy link

@h-vetinari FYI this bug is still hitting conda-forge/deno-feedstock#132, even with the new cctools_osx-64 from the PR you linked (I have checked in the build logs to confirm the most recent cctools w/ build number 4 is being used). I also tried bumping the syn version, and that did not fix the segfault either.

@pkgw
Copy link
Contributor

pkgw commented Sep 6, 2024

In a local test build of pixi, conda-forge/cctools-and-ld64-feedstock#70 fixes the failure for me.

update: in a local test of conda-forge/deno-feedstock#132, the macOS build doesn't succeed, but it gets past the segfault issue in the current version of the PR.

@pkgw
Copy link
Contributor

pkgw commented Sep 6, 2024

conda-forge/cctools-and-ld64-feedstock#70 has been merged and has propagated. I've retriggered a few sample builds of the Rust projects that were failing and I think they're working now, so hopefully this issue is fixed.

@xhochy
Copy link
Member

xhochy commented Oct 13, 2024

Closing as I haven't seen this in a while. Seems like the fix was sufficient.

@xhochy xhochy closed this as completed Oct 13, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

10 participants