Include SDC GC - #2
Conversation
Co-authored-by: Steven Schveighoffer <sschveighoffer@symmetryinvestments.com>
In order to trivially switch between GCs.
…ntime libs supporting the SDC GC So that env var `DRT_GCOPT=gc:sdc` doesn't break any programs using a druntime library without SDC GC support (incl. LDC itself if linked against static druntime).
…sure all threads are scanned for alternative GC mechanisms.
5e02e4a to
eb9c108
Compare
Conflicts: .github/actions/4d-test-libs/action.yml .github/actions/6-integration-test/action.yml
|
Damn, now we have the problem of GitHub Actions not providing the Ubuntu-20 runners anymore. LDC master is using Ubuntu 22, with higher min glibc version requirement accordingly. For our Symmetry CI runners, a package built on Ubuntu 22 might not work on the Debian-11 The other alternative would be using a Ubuntu-20 container and building in there; that might require a few YAML changes only. I guess I'll try that. |
|
@kinke should we close this PR? I feel like it just adds another identical run of the CI actions (there is one for the branch, and one for the inevitable tag). |
|
Well I guess this branch/PR reaches EOL soon anyway - and the PR is handy for the discussion (although it doesn't need to remain open for that). |
… breakage (ldc-developers#4902) But keep using Xcode v16 (the default version for macos-15), not v15.4.
By running the Linux x86_64 job in a Ubuntu 20 container.
|
Oh, have you force-pushed the tag? - Please wait until the branch workflow is through, there was still a problem caused by running in a container. |
There are actually 2 identical runs for each push here (branch + PR) - identical because the target branch doesn't have anything newer to merge in. The tag workflow is slightly different - it uses an LLVM without assertions, which also disables LDC assertions. So tagged CI builds are significantly faster than all other CI builds. |
|
OK, sorry. I just didn't want to litter the repo with subsequent tags. I will wait to push the tag, and just do lucky 13 I guess lol. |
|
Okay, green now. - No too strong opinion from my side wrt. whether to force-push again or go with 13, but e.g. it's not like my local tag was updated after your force push. Not even after an explicit |
Limit the number of platforms that this is done on. A inspection of some libc implementations of fork has identified the main culprits, don't need to apply this to any others. MacOS testsuite also regressed as a result on calling this code, it's not clear why, but the backtrace is: ``` * thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_INSTRUCTION (code=EXC_I386_INVOP, subcode=0x0) * frame #0: 0x00007ff81abe6ee3 libsystem_platform.dylib`_os_unfair_lock_recursive_abort + 23 frame #1: 0x00007ff81abe12da libsystem_platform.dylib`_os_unfair_lock_lock_slow + 247 frame #2: 0x00007ff81abccd44 libsystem_pthread.dylib`_pthread_atfork_prepare_handlers + 48 frame #3: 0x00007ff825dc2705 libSystem.B.dylib`libSystem_atfork_prepare + 25 frame #4: 0x00007ff81aac17e1 libsystem_c.dylib`fork + 24 frame #5: 0x0000000101f730ee test_runner`core.internal.backtrace.dwarf.resolveAddressesWithAtos(Location[]) + 210 ```
2 participants
No description provided.