Skip to content

Conversation

@KristofferC
Copy link
Member

No description provided.

xal-0 and others added 7 commits December 4, 2025 14:34
Some testing by @BenChung has revealed how hard it is to load a
JuliaC-built library into a program that has already loaded a very old
version of libstdc++. Even with probing disabled, `libjulia-internal.so`
fails because of missing GLIBCXX symbols.

We use so little of the C++ standard library in `libjulia-internal.so`
that it's worth the tradeoff to link it statically: it barely changes
the size of the resulting library, removes a medium-size library we have
to ship in trimmed bundles, and solves some of our hermeticity issues
when being loaded by other software. `libjulia-codegen.so` uses it more
extensively, and we expect to be able to load it as a plugin for `opt`,
meaning it may have to remain dynamically linked.

This PR contains a series of changes to enable statically linked
libstdc++ by default and mitigate the size impact:
- We enable `--gc-sections` when building with gcc/ld.bfd. This saves us
some code already, since we can trim out a lot of
libLLVMSupport/libLLVMTargetParser. On macOS, we can use `-dead_strip`
to save some space even though the rest of these changes are not
applicable.
- Two flags for `-static-libstdc++` and `-static-libgcc`, called
`USE_RT_STATIC_LIBSTDCXX` and `USE_RT_STATIC_LIBGCC`, are added and
enabled by default.
- Most of the additional code that gets linked into
`libjulia-internal.so` is related to locales for iostreams. Replace
these with standard C IO and LLVM helpers that don't have weird
locale-related behaviour.
- (NOT IMPLEMENTED) `--gc-sections` removes unused executable code, but
leaves us with a lot of irrelevant debug info. I tested the effect of
`llvm-dwarfutil --garbage-collection` and saw pretty good savings, but
that is not included in this PR because BinaryBuilder doesn't have a new
enough version of the LLVM tools.

| Change | Size of `libjulia-internal.so` (KiB) |

|--------------------------------------|--------------------------------------|
| No change | 14524 |
| Linker GC enabled | 13220 |
| -static-libstdc++ and -static-libgcc | 22136 |
| Excise iostreams | 15036 |
| DWARF GC (not in this PR) | 11488 |

This is a comparison of symbols that were added and removed. Even though
15 times more code is removed than added, the resulting
`libjulia-internal.so` has a similar size to the original because of the
additional debug info.

(cherry picked from commit f36882f)
It was exported in v1.7, not v1.10: #39588

(cherry picked from commit 1067db8)
Co-authored-by: Cody Tapscott <[email protected]>
(cherry picked from commit 841148d)
(cherry picked from commit cb2ceb9)
Somewhat of a companion to
#60248.

For a small application that has just started up `fork()` is not a huge
concern, but it's quite heavy-handed for Julia- as-a-library scenarios
where resident memory may already be large. Many soft-embedded targets
also do not support fork() well, so it is good for our compatibility to
adjust this.

Rather than relying on the linker to do all of the heavy lifting, this
changes our `libstdcxx` probe sequence to directly parse the
`ld.so.cache` and `libstdc++.so.6` files. As long as we can expect
`/etc/ld.so.cache` to be the same path on all Linux systems, this seems
to be a reliable way to locate system libraries.

(cherry picked from commit ac4ee59)
@KristofferC KristofferC added the release Release management and versioning. label Dec 4, 2025
@KristofferC KristofferC requested a review from giordano as a code owner December 4, 2025 13:34
vtjnash and others added 2 commits December 9, 2025 17:57
Add fake_stack_pop implementation for Linux platforms to improve stack
unwinding in debuggers when analyzing core dumps from signals like
SIGQUIT. This provides proper DWARF Call Frame Information (CFI)
directives that help unwinders locate saved register values on the
manipulated stack.

The implementation follows the same pattern as the existing macOS
version, with fake_stack_pop now unified in signals-unix.c to support
both platforms:
- x86_64: Uses .cfi_def_cfa %rsp with offsets for %rip and %rsp
- i686: Uses .cfi_def_cfa %esp with offsets for %eip and %esp
- aarch64: Uses .cfi_def_cfa sp with offsets for lr and sp

The jl_call_in_ctx function on Linux now sets up the stack similarly to
jl_call_in_state on macOS, pushing saved register state and a return
address pointing to fake_stack_pop to enable proper unwinding.

🤖 Generated with Claude Code

(cherry picked from commit 8fd607a)
…0259)

If a method we precompile instantiates a closure struct, and there is a
single compileable signature for the closure method, we can compile the
closure method with few downsides.

For example:
```julia
f(x::T) where {T <: Number} = y::T -> x+y
precompile(f, (Int,))

f(1)(2)
```

Before, the closure method would not get precompiled, resulting in
`--trace-compile` output:
`precompile(Tuple{Foo.var"#f##0#f##1"{Int64, Int64}, Int64})`

This idea was motivated by trying to make the REPL precompile script
more "static". Creating a task with `@task` or `@async` expands into a
no-argument lambda, which won't get precompiled with the containing
method.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

release Release management and versioning.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

10 participants