Switch FreeBSD CI to LLVM 19 #4901

arrowd · 2025-04-07T06:56:00Z

The default LLVM version on FreeBSD Ports was switched to 19 a while ago. Current LDC bootstraps gets build against 15, which forces the port to pull in two LLVM versions, 15 and 19, at the same time.

Fixes build on FreeBSD

kinke · 2025-04-07T13:50:54Z

In #4865, I've tried LLVM 19: b884ed4

Then LLVM 18: 184d7e0

I finally gave up because of the lit-test failures (still available in the CI logs) and reverted to 15.

arrowd · 2025-04-07T14:34:06Z

Yes, I now bumped into the same test failures. I'll look into them more.

arrowd · 2025-04-07T18:09:16Z

Ok, this is really a mess, unfortunately. There is so much logic trying to guess proper filepaths and names on different OSes. It is fragile and FreeBSD is just an example of this.

I'm not experienced enough to quickly devise a different approach, so I'm just leaving this PR as it is hoping someone will pick it up.

arrowd · 2025-04-09T15:57:40Z

All right, now that I made the CI green I noticed that I partly redid what #4665 does.

I think we should first land this PR, as it isn't as invasive as the first one and then try to overhaul the logic for searching the runtime libraries.

kinke · 2025-04-09T16:17:27Z

.circleci/config.yml

      - LLVM_MAJOR: 18
      - HOST_LDC_VERSION: 1.39.0
-      - EXTRA_CMAKE_FLAGS: "-DMULTILIB=ON -DRT_SUPPORT_SANITIZERS=ON -DBUILD_LTO_LIBS=ON"
+      - EXTRA_CMAKE_FLAGS: "-DMULTILIB=ON -DRT_SUPPORT_SANITIZERS=ON -DBUILD_LTO_LIBS=ON -DCOMPILER_RT_LIBDIR_OS=linux"


Why is this DCOMPILER_RT_LIBDIR_OS now needed everywhere? I'm afraid that's unacceptable.

I guess we could change it to linux here if it's the more common value

ldc/CMakeLists.txt

Lines 826 to 827 in 06b2e42

set(COMPILER_RT_LIBDIR_OS_DEFAULT "x86_64-unknown-linux-gnu")

set(COMPILER_RT_LIBDIR_OS "${COMPILER_RT_LIBDIR_OS_DEFAULT}" CACHE STRING "Non-Mac Posix: OS used as directory name for the compiler-rt source libraries, e.g., 'freebsd'.")

Why is this DCOMPILER_RT_LIBDIR_OS now needed everywhere?

I made it a hard error if the directory does not exist

I'm afraid that's unacceptable.

Why? It serves as a safebelt for a user. Without this it took me a while to figure out why profiling tests are failing on FreeBSD - turns out that profiling functionality is silently disabled if the compiler can't locate the runtime dir properly.

I guess we could change it to linux here if it's the more common value

Sure, but AFAICT, it has been working fine already - but maybe only accidentally? E.g., looking at the unsupported lit-tests for Cirrus CI job Ubuntu-24.04-multilib-rtSanitizers (edit: which is using the shared distro LLVM 18, so defaulting to LDC_INSTALL_LLVM_RUNTIME_LIBS=OFF), their number is still 32.

Alternatively (not sure what the current 'normal' convention is), we could also default to the default LLVM target triple (derivable from llvm-config --host-target).

Why is this DCOMPILER_RT_LIBDIR_OS now needed everywhere?

I made it a hard error if the directory does not exist

Ah alright, so it really just worked accidentally, and the default value should be linux then.

I'm afraid that's unacceptable.

Why?

Because I thought then every user/maintainer needs to follow suit and set it now.

Without this it took me a while to figure out why profiling tests are failing on FreeBSD - turns out that profiling functionality is silently disabled if the compiler can't locate the runtime dir properly.

Understood. Ideally, the according lit-tests would actually be disabled ('unsupported') if the compiler-rt libs aren't available, e.g.:

ldc/tests/PGO/lit.local.cfg

Lines 2 to 3 in 06b2e42

if 'profile' in config.enabled_rt_libs:

config.available_features.add('PGO_RT')

Ah alright, so it really just worked accidentally, and the default value should be linux then.

Oh well, what's required for our LLVM builds is apparently a full triple on Linux, for both x86_64 and aarch64. And that's a pretty standard build, not customizing any compiler-rt paths or the like.

kinke · 2025-04-09T16:19:17Z

CMakeLists.txt

    set(COMPILER_RT_LIBDIR_OS "${COMPILER_RT_LIBDIR_OS_DEFAULT}"   CACHE STRING "Non-Mac Posix: OS used as directory name for the compiler-rt source libraries, e.g., 'freebsd'.")
    set(COMPILER_RT_LIBDIR "${COMPILER_RT_LIBDIR}/${COMPILER_RT_LIBDIR_OS}")
+    if(NOT COMPILER_RT_LIBDIR_OS STREQUAL COMPILER_RT_LIBDIR_OS_DEFAULT)
+        set(WANT_COMPILER_RT_LIBDIR_CONFIG TRUE)


Is this used anywhere?

Oh I see now, this controls whether the dir makes it to the config file. I guess it doesn't hurt to always add it here in this branch - if the dir exists. When using LDC_INSTALL_LLVM_RUNTIME_LIBS, it's disabled later anyway.

I added this mainly for linux distros to:

encourage adding support for compiler-rt rather then hard-disabling the option to prevent the copies which are undersirable

avoid having to sed the cpp source files to allow ldc to find them.

[Yeah I very much like that in principle, forwarding CMake options to the compiler, to put less burden on the hardcoded compiler magic.]

CMakeLists.txt

arrowd · 2025-04-10T09:26:06Z

Made linux the default.
Made the hard error a warning.

It feels like macOS failure isn't my fault?

CMakeLists.txt

kinke · 2025-04-10T09:52:47Z

It feels like macOS failure isn't my fault?

That's almost certainly #4899, now that GHA bumped their macos-15 image to v15.4. Thx Apple, greatly appreciated!

kinke · 2025-04-10T09:56:17Z

Made linux the default.

I guess that still needs investigating - a 'normal' LLVM build (with in-tree compiler-rt sources) seems to default to the full triple. As said above, that's what our LLVM builds require, and the FreeBSD port too. So it looks like the majority (?) of Linux distros went with linux, but that diverges from the LLVM default.

Edit: I guess we could also support both, preferring the full triple and checking if the dir exists; if it doesn't, trying to fall back to linux if that dir exists.

the-horo · 2025-04-10T12:32:31Z

I guess that still needs investigating - a 'normal' LLVM build (with in-tree compiler-rt sources) seems to default to the full triple. As said above, that's what our LLVM builds require, and the FreeBSD port too. So it looks like the majority (?) of Linux distros went with linux, but that diverges from the LLVM default.

The jist is that when building compiler-rt separately you end up, by default, with /linux and when building it alongside llvm you end up with /<triple>. Relevant llvm cmake code for this is:

https://github.com/llvm/llvm-project/blob/5c8ba28c751bf0e7cb5c3ac9d223acba4cefc739/compiler-rt/cmake/base-config-ix.cmake#L106-L118

https://github.com/llvm/llvm-project/blob/5c8ba28c751bf0e7cb5c3ac9d223acba4cefc739/compiler-rt/cmake/Modules/CompilerRTUtils.cmake#L512-L519

With LLVM_ENABLE_PER_TARGET_RUNTIME_DIR being set at https://github.com/llvm/llvm-project/blob/5c8ba28c751bf0e7cb5c3ac9d223acba4cefc739/llvm/CMakeLists.txt#L959-L965

I guess I should have wrote these in #4665. It would have saved me for re-checking the llvm logic.

kinke · 2025-04-10T15:17:22Z

Thx a lot Andrei. - So to me this is clearly the way to go then:

we could also support both, preferring the full triple and checking if the dir exists; if it doesn't, trying to fall back to linux if that dir exists

(Doesn't have to be in this PR, can create one myself.)

arrowd · 2025-04-14T09:35:19Z

Anything required from me to move this forward?

kinke · 2025-04-14T11:45:31Z

At most a rebase after #4665 has landed, then you shouldn't have to deal with compiler-rt here anymore.

As according to earlier tests, it's only LLD that needs libzstd.

kinke

Thanks!

arrowd · 2025-04-16T14:42:28Z

Am I understand it right that the FreeBSD binaries of the next LDC release will be linked to LLVM 19?

kinke · 2025-04-16T15:01:33Z

Yeah, beta1 coming up this week. - If you wanna make the bootstrapping of the LDC FreeBSD port more independent, I suggest using GDC via its gdmd wrapper as host compiler.

arrowd · 2025-04-16T15:08:31Z

It was the other way around - we switched from gdmd to binary LDC bootstraps because GDC 12+ also needs a bootstrap compiler. So using LDC bootstraps is lesser of two evils and we're actually depending on you guys.

kinke · 2025-04-16T15:42:58Z

Mhm. The official FreeBSD package from GitHub is the only prebuilt package which doesn't link LLVM statically. I assumed the majority of those users are fine with a slim package, having the LLVM port installed already or quickly installing it if needed.

If static linking is feasible with the LLVM port, and it would make things easier for you guys, we could IMO switch.

arrowd · 2025-04-16T15:50:23Z

As long as bootstrap is linked to the same LLVM version that we're building against, the static linking wouldn't change anything for us. So I don't think you should bother with static linking unless it is actually easier for you.

kinke · 2025-04-16T15:54:49Z

For us it wouldn't be any easier/harder. As long as you won't be needing bleeding-edge LLVM version support, you should be good then - as you probably know, it can take a bit of time until a new LLVM version is supported here in master, and some more time until a release with prebuilt packages is available.

arrowd added 2 commits April 7, 2025 09:54

Switch FreeBSD CI to LLVM 19

213ad49

ldc-profdata uses threads, so link it to a threading library

e14cd63

Fixes build on FreeBSD

arrowd force-pushed the freebsd branch 6 times, most recently from 38ca68d to ea61174 Compare April 7, 2025 13:50

arrowd force-pushed the freebsd branch from ea61174 to f5d30d6 Compare April 7, 2025 14:13

arrowd force-pushed the freebsd branch 5 times, most recently from a89857b to fb7aa12 Compare April 7, 2025 18:09

arrowd force-pushed the freebsd branch 4 times, most recently from 90b014e to ba48c64 Compare April 9, 2025 14:38

kinke reviewed Apr 9, 2025

View reviewed changes

CMakeLists.txt Outdated Show resolved Hide resolved

arrowd force-pushed the freebsd branch 2 times, most recently from d1cb4a9 to 16e4e19 Compare April 10, 2025 08:24

kinke reviewed Apr 10, 2025

View reviewed changes

CMakeLists.txt Outdated Show resolved Hide resolved

Link to zstd on FreeBSD as it gets pulled in by LLVM

3d24a7a

arrowd force-pushed the freebsd branch from 16e4e19 to dbd56fd Compare April 10, 2025 11:34

kinke force-pushed the freebsd branch from dbd56fd to 3d24a7a Compare April 15, 2025 18:52

Cirrus & Circle CI: Merge PR with target branch first

361f3dc

kinke force-pushed the freebsd branch from b0c0a98 to 361f3dc Compare April 15, 2025 19:49

[move FreeBSD libzstd special case to LDC_WITH_LLD linker flags block]

7d341e6

As according to earlier tests, it's only LLD that needs libzstd.

kinke force-pushed the freebsd branch from 2b36d4f to 7d341e6 Compare April 16, 2025 13:04

kinke approved these changes Apr 16, 2025

View reviewed changes

kinke merged commit 87ae838 into ldc-developers:master Apr 16, 2025
20 checks passed

arrowd deleted the freebsd branch April 16, 2025 15:50

	set(COMPILER_RT_LIBDIR_OS_DEFAULT "x86_64-unknown-linux-gnu")
	set(COMPILER_RT_LIBDIR_OS "${COMPILER_RT_LIBDIR_OS_DEFAULT}" CACHE STRING "Non-Mac Posix: OS used as directory name for the compiler-rt source libraries, e.g., 'freebsd'.")

	if 'profile' in config.enabled_rt_libs:
	config.available_features.add('PGO_RT')

Uh oh!

Switch FreeBSD CI to LLVM 19 #4901

Switch FreeBSD CI to LLVM 19 #4901

Uh oh!

Conversation

arrowd commented Apr 7, 2025

Uh oh!

kinke commented Apr 7, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

arrowd commented Apr 7, 2025

Uh oh!

arrowd commented Apr 7, 2025

Uh oh!

arrowd commented Apr 9, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

kinke Apr 9, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

arrowd commented Apr 10, 2025

Uh oh!

Uh oh!

kinke commented Apr 10, 2025

Uh oh!

kinke commented Apr 10, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

the-horo commented Apr 10, 2025

Uh oh!

kinke commented Apr 10, 2025

Uh oh!

arrowd commented Apr 14, 2025

Uh oh!

kinke commented Apr 14, 2025

Uh oh!

kinke left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

arrowd commented Apr 16, 2025

Uh oh!

kinke commented Apr 16, 2025

Uh oh!

arrowd commented Apr 16, 2025

Uh oh!

kinke commented Apr 16, 2025

Uh oh!

arrowd commented Apr 16, 2025

Uh oh!

kinke commented Apr 16, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

kinke commented Apr 7, 2025 •

edited

Loading

kinke Apr 9, 2025 •

edited

Loading

kinke commented Apr 10, 2025 •

edited

Loading