-
-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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
base: master
Are you sure you want to change the base?
Conversation
I have no clue how to test this on my tiny outdated laptop... |
where you at rootie @jmroot who's bringing the hoes @ryandesign @jeremyhu rootie got the kegs of fosters or what? lol
it's a one shotter now as of latest commit. uploading lawg |
just copy the Portfile to /opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs/ports/lang/llvm-19/Portfile 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 |
but what i don't understand @ryandesign is why it says
bruh if our party gon' pop, we gotta fix this |
@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. |
There was a problem hiding this 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.
lang/llvm-19/Portfile
Outdated
configure.cppflags-append -DON_LION_OR_LATER | ||
} | ||
if {${os.platform} eq "darwin" && ${os.major} < 15} { | ||
configure.cppflags-append -DON_BROSEMITE_OR_LOWER |
There was a problem hiding this comment.
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
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)
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 :/ |
no, it's rather ridiculous and shouldn't have merged in the |
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 |
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
lang/llvm-19/Portfile
Outdated
# 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 |
There was a problem hiding this comment.
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.
i don't think i can shellescape a reinplace command?
i can implement the other changes wrt prefix and build dir, and hope it doesn't break things (it shouldn't)
but the xargs print-0 way may break things or make it ugly as hell.
Thanks,
Gagan
… On Jul 10, 2025, at 8:42 AM, Ryan Carsten Schmidt ***@***.***> wrote:
@ryandesign commented on this pull request.
In lang/llvm-19/Portfile:
> + }
+ if {${os.platform} eq "darwin" && ${os.major} < 15} {
+ configure.cppflags-append -DON_BROSEMITE_OR_LOWER
+ }
+ if {${os.platform} eq "darwin" && ${os.major} < 16} {
+ configure.cppflags-append -DON_EL_CAPITAN_OR_LOWER
+ }
+ if {${os.platform} eq "darwin" && ${os.major} < 11} {
+ pre-build {
+ #we need a way to shoehorn in this string replacement for two reasons:
+ # 1. because the build system inserts no version number for libSystem.B.dylib
+ # when linking libunwind.1.0.dylib
+ # 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
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.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you were mentioned.
|
c0e71a7
to
53596ba
Compare
looks much better now. running the compile again, ugh. but it should be fine. the substituted stringsd on't look any different
works great. thanks @ryandesign @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
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?
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)
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 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Some suggestions
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" |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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?
i think this covers all of it?
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)
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
port lint
?sudo port test
?sudo port -vst install
?