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

Apple builds for MPICH broke in recent toolchain update #7745

Open
eschnett opened this issue Dec 2, 2023 · 5 comments
Open

Apple builds for MPICH broke in recent toolchain update #7745

eschnett opened this issue Dec 2, 2023 · 5 comments

Comments

@eschnett
Copy link
Contributor

eschnett commented Dec 2, 2023

See #7736.

I saw some recent messages about downgrading elfutils in the RootFS. Is this expected to correct this problem?

@gbaraldi

@benlorenz
Copy link
Contributor

benlorenz commented Dec 3, 2023

I recently encountered this as well, one workaround is to set LDFLAGS=-fuse-ld=ld on macos to undo the linker change.

But I did look into this a bit further and this might be caused by a broken linker-flag detection in libtool:
https://savannah.gnu.org/support/?110937

libtool checks whether -single_module is supported, but in the gfortran 4 and 5 builds lld gives a warning that this is the default anyway and deprecated. This confuses libtool and it assumes the flag is unsupported:

[17:49:34] checking for -single_module linker flag... ld64.lld: warning: Option `-single_module' is deprecated in ld64:
[17:49:34] no

The fallback flags -r -keep_private_extern are not supported by lld.

Patching libtool is a bit annoying since we would need to regenerate all the configure scripts.
But we could pass lt_cv_apple_cc_single_mod=yes to configure instead, then the flag will always be assumed to work but that should be fine since it is the default anyway.

In my local experiments this seems to work for the MPICH macos builds and for Singular as well.

@eschnett
Copy link
Contributor Author

I am now seeing a similar (related?) build error on Apple #7762 . This time it's with cmake (not configure) and the option is -commons (possibly Fortran-related):

[23:05:06] ld64.lld: warning: Option `-commons' is not yet implemented. Stay tuned...
[23:05:06] ld64.lld: error: No LC_DYLD_INFO_ONLY or LC_DYLD_EXPORTS_TRIE found in /opt/x86_64-apple-darwin14/x86_64-apple-darwin14/lib/libgcc_s.1.dylib
[23:05:06] ld64.lld: error: No LC_DYLD_INFO_ONLY or LC_DYLD_EXPORTS_TRIE found in /opt/x86_64-apple-darwin14/x86_64-apple-darwin14/lib/libgcc_ext.10.5.dylib

@gbaraldi Do you have some insight here as well?

@eschnett
Copy link
Contributor Author

This approach also seems to work – deleting the new linkers:

if [[ "${target}" == x86_64-apple-darwin* ]]; then
    # See <https://github.com/JuliaPackaging/Yggdrasil/issues/7745>:
    # Remove the new linkers which don't work yet
    rm /opt/bin/${bb_full_target}/ld64.lld
    rm /opt/bin/${bb_full_target}/ld64.${target}
    rm /opt/bin/${bb_full_target}/${target}-ld64.lld
    rm /opt/${MACHTYPE}/bin/ld64.lld
fi

@ViralBShah
Copy link
Contributor

Is this still an issue?

MaximeBouton added a commit to MaximeBouton/Yggdrasil that referenced this issue May 21, 2024
@MaximeBouton
Copy link
Contributor

I encountered the same issue here: #8707 and fixed it using the keyword from #7876

giordano pushed a commit that referenced this issue May 21, 2024
…es (#8707)

* add version in libjulia dependency

* bump preferred gcc to 10

* remove macos specific flags

* do not use lld for macos platforms #7745

* add compat for libcxxwrap_julia_jll

* typo

* compat as string
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants