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 <84105208+topolarity@users.noreply.github.com>
(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
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.

9 participants