Skip to content

enable {llvm,clang}-19 on 10.6+, bump macports-libcxx to llvm-19 for intel macs #28834

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

Open
wants to merge 12 commits into
base: master
Choose a base branch
from

Conversation

i3roly
Copy link

@i3roly i3roly commented Jul 8, 2025

see lawgs here:

https://trac.macports.org/ticket/72660#attachments

the only outstanding issue (which i'm in the process of testing a fix for) is that ld-latest isn't being used on 10.6

for 10.7 it's as simple as using clang-mp-11 and it should build fine (with the patches to sanitizer)

for 10.6 it's a little more involved, unsurprisingly.

as it stands the 10.6 build should almost finish, but fail because /opt/local/bin/ld points to ld127 as opposed to ld-latest.

it's possible that my change in the Portfile (that i'm testing) which sets
CMAKE_{C,CXX}_LINK_EXECUTABLE will fix it

since the "fuse-ld" approach will not work.

where you at jerry holla atcha boi @jeremyhu

cc @ryandesign

who's wheeling in the kegs and shit? rootie coordinating or what? let's take Team Bad Processors to task.

Type(s)
  • bugfix
  • enhancement
  • security fix
Tested on

macOS 10.6.8 10K549 i386
Xcode 4.2 4C199

macOS 10.7.5 11G63 x86_64
Xcode 4.6.2 4H1003

Verification

Have you

  • followed our Commit Message Guidelines?
  • squashed and minimized your commits?
  • checked that there aren't other open pull requests for the same change?
  • referenced existing tickets on Trac with full URL in commit message?
  • checked your Portfile with port lint?
  • tried existing tests with sudo port test?
  • tried a full install with sudo port -vst install?
  • tested basic functionality of all binary files?
  • checked that the Portfile's most important variants haven't been broken?

@aeiouaeiouaeiouaeiouaeiouaeiou
Copy link
Contributor

I have no clue how to test this on my tiny outdated laptop...

CC @barracuda156

where you at rootie @jmroot
who's bringing the hoes @ryandesign @jeremyhu

rootie got the kegs of fosters or what?

lol
@i3roly
Copy link
Author

i3roly commented Jul 9, 2025

it's a one shotter now as of latest commit. uploading lawg

@i3roly
Copy link
Author

i3roly commented Jul 9, 2025

just copy the Portfile to /opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs/ports/lang/llvm-19/Portfile
and copy 0026-changes_for_el_crapitan_and_lower.patch to /opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs/ports/lang/llvm-19/files/

it should work. i mean, my 10.6 vm is pretty barebones.

feels pretty good not going to lie. 10.6 building a full clang-19 hahah

@i3roly
Copy link
Author

i3roly commented Jul 9, 2025

but what i don't understand @ryandesign is why it says

vm106:bin vm$ sudo port select clang mp-clang-11
Selecting 'mp-clang-11' for 'clang' failed: could not create new link "/opt/local/bin/scan-build": target "/opt/local/bin/scan-build-mp-11" doesn't exist

bruh if our party gon' pop, we gotta fix this

@barracuda156
Copy link
Contributor

@i3roly Unless someone fixes clang for powerpc, this is not my party LOL

I do use clangs on Catalina and Sonoma just because switching to gcc is too much of a pain, but my only use for 10.6 Intel is to debug stuff for deploying on 10.6 powerpc. So there clangs are of no use.

Copy link
Contributor

@reneeotten reneeotten left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

a few (cosmetic) suggestions/requests. Also, making this PR draft as it will need proper vetting by people who understand compiler suites and the potential impact of these changes in MacPorts.

configure.cppflags-append -DON_LION_OR_LATER
}
if {${os.platform} eq "darwin" && ${os.major} < 15} {
configure.cppflags-append -DON_BROSEMITE_OR_LOWER
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

change to correctly identify OS --> Yosemite

@reneeotten reneeotten marked this pull request as draft July 9, 2025 13:32
turns out i had the ld-latest symlinked to /opt/local/bin/ld still :P

realised that the CMAKE_LINKER variable was being set, and it needs to
be set (again) to override the previous setting (latest flag always
takes precedent)
@i3roly
Copy link
Author

i3roly commented Jul 9, 2025

i think i got most of the suggestions wrt spacing.

the brosemite thing i think is fair game. there were no issues with it in nodejs.

plus diffing tghe relevant files is kind of annoying because i would have to do it after macports applies all patches (save the new one) and then reinsert/test it :/

@reneeotten
Copy link
Contributor

the brosemite thing i think is fair game. there were no issues with it in nodejs.

no, it's rather ridiculous and shouldn't have merged in the nodejs ports either - probably nobody noticed... It should be changed there as well.

@i3roly
Copy link
Author

i3roly commented Jul 9, 2025

well i believe there's room for self-expression and one's contribution to override another's sanctimony, but that's neither here nor there. i'll handle this in private. thanks

i3roly added 2 commits July 9, 2025 21:25
this time /opt/local/bin/ld did point to ld-127 and it works!

finally. test your hearts out @jmroot @ryandesign
thanks to the string replacement, we can do what cmake refuses to do
consistently
# 2. snow leopard uses ld-127, which is not good enough for libunwind.
# so we use -fuse-ld=/opt/local/bin/ld-latest to shoehorn in the right linker.
# together, these two substitutions lead to a "one shot" compilation.
reinplace "s|work/build/runtimes/runtimes-stamps/runtimes-configure|work/build/runtimes/runtimes-stamps/runtimes-configure \\&\\& sed -i '' 's:\-current_version /usr/lib/libSystem.B.dylib:\-current_version 1.0.0 /usr/lib/libSystem.B.dylib:g' ${portpath}/work/build/runtimes/runtimes-bins/build.ninja \\&\\& sed -i '' 's:\-compatibility_version 1.0.0 \-current_version 1.0.0:\-compatibility_version 1.0.0 \-current_version 1.0.0 \-fuse\-ld=\/opt\/local\/bin\/ld\-latest:g' \`find ${portpath}/work/build/runtimes -name build.ninja\`|g" ${portpath}/work/build/build.ninja
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hardcoding /opt/local here is probably not correct; you probably want to use ${prefix} instead.

Instead of ${portpath}/work/build you probably want to use ${build.dir}. That might also apply to the two occurrences of work/build that aren't prefixed by ${portpath}/, assuming they are prefixed with that value in the contents of build.ninja.

Some things are escaped here by manually adding backslashes and other things (like the first argument to find) are not properly escaped. You can use [shellescape ...] to escape arguments that will be sent to the shell. However, to actually support any unlikely special characters that might occur within ${build.dir}, you would have to use find's -print0 option and pipe to xargs, rather than just interpolating the output of find.

Literal periods in regular expressions need to be escaped with a backslash (and a second backslash when using "-delimited strings as you are here), e.g. 1.0.0 in the search part should be replaced with 1\\.0\\.0. For a long string like this one, instead of manually escaping every period and other special character, you might rather use [quotemeta ...] to add the necessary escaping.

@i3roly
Copy link
Author

i3roly commented Jul 10, 2025 via email

@i3roly i3roly force-pushed the LLVM_TheRemix branch 2 times, most recently from c0e71a7 to 53596ba Compare July 10, 2025 15:32
looks much better now.

running the compile again, ugh. but it should be fine. the substituted
stringsd on't look any different
@i3roly
Copy link
Author

i3roly commented Jul 10, 2025

works great. thanks @ryandesign

partyprep

@jmroot rootie you got that fosters comin' in freight or what?

should be a little better. maybe makes no difference at all. but this
makes sure the older patches in llvm-17 are consistent with the ones i
had made independently
@i3roly
Copy link
Author

i3roly commented Jul 13, 2025

extremely pleased to announce all nodejses build great on 10.7 with the uplifted macports-libcxx

i haven't tried nodejs on 10.6 quite yet as this stupid linker issue is bugging me, but that linker issue does not interfere with having a working macports-libcxx. i just haven't taken a breath in between my sudo port -v build clang-19s (on 10.6) to do a sudo port -v build nodejs24 configure.compiler=macports-clang-17 (or whatever).

i want to thank the team and guys like @fhgwright who don't talk much, but do a lot.

here's to you freddy baby

- intel macs on 10.6 and later can use clang-19 and llvm-19, so we
  update the macports-libcxx accordingly. it seems one of the
  install_tool commands isn't necessary now?

  could @jeremyhu or @ryandesign comment here?
@i3roly i3roly changed the title changes so that clang-19 compiles on 10.6 and 10.7 enable {llvm,clang}-19 on 10.6+, bump macports-libcxx to llvm-19 for intel macs Jul 13, 2025
@i3roly i3roly marked this pull request as ready for review July 13, 2025 19:13
i3roly added 2 commits July 14, 2025 09:12
it is now clean and no more string replacements for the linker
@ryandesign @jeremyhu. i had to bump the default ld to 274 but i don't
think this any huge problem. with this new default everything builds
great and i've gotten node to start, but node will need some patches for
10.6 since it calls getsectiondata
because of @jeremyhu's magic, or i think it's his magic, and a libc++
appearing in /usr/lib, the build process for clang-19 erroneously thinks
it can use it for cxa_thread_atexit, which it cannot. so i had to make
sure that we build clang to include it, as non-APPUL/CYGWIN platforms
use it, and snow leopard has no thread_local handling (that's on 10.7
and up).

so now we have a proper compiler that handles thread_local, and i'm
focussing on why environment.c in nodejs22 is not linking up to
libc++abi properly, which has the symbols.

all in all this is great news and it seems to me, at least, the compielr
is ready to go live. i just have to figure out how to make sure the
c++abi gets linked into environment.o before it gets into the static
library, which is then used at final linktime.

maybe jeremy has some ideas?

cc: rydye (@ryandesign)
@i3roly
Copy link
Author

i3roly commented Jul 18, 2025

this is ready to go. and it should be pushed before nodejs.

i'll let you coordinate this @ryandesign

but from my POV it looks good

Copy link
Contributor

@ryandesign ryandesign left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Some suggestions

Comment on lines +112 to +113
system -W ${destroot}${prefix}/lib/libcxx/ "ln -s libunwind.1.0.dylib libunwind.1.dylib"
system -W ${destroot}${prefix}/lib/libcxx/ "ln -s libunwind.1.dylib libunwind.dylib"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see you're just copying what existing lines in the portfile do, but we don't want to use system to do things that can be done in native Tcl; it's an unnecessary overhead. ln is a built-in MacPorts Tcl command.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i'm not sure if i can use the macports tcl command here? i need to cd into a directory first to link them without having any path in the source? any additional input?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

Successfully merging this pull request may close these issues.

6 participants