Skip to content

Call jl_init_options from jl_autoinit_and_adopt_thread - #62883

Draft
gbaraldi wants to merge 2 commits into
masterfrom
gb/autoinit-options
Draft

Call jl_init_options from jl_autoinit_and_adopt_thread#62883
gbaraldi wants to merge 2 commits into
masterfrom
gb/autoinit-options

Conversation

@gbaraldi

Copy link
Copy Markdown
Member

jl_init_options is normally called by the libjulia loader (cli/loader_lib.c) before any other runtime code. In a static build of libjulia-internal (#62868) there is no loader, and jl_autoinit_and_adopt_thread — the trampoline that images call on first entry — becomes the first runtime entry point, so jl_options would never be initialized. Call jl_init_options there before jl_init_with_image_handle.

jl_init_options guards itself with jl_options_initialized, so this is a no-op for the regular shared build.

Part of the static libjulia-internal work.

🤖 Generated with Claude Code

`jl_init_options` is normally invoked by the libjulia loader
(cli/loader_lib.c) before anything else runs. When the runtime is linked
statically into an image there is no loader, and the auto-initialization
trampoline is the first runtime entry point, so make it initialize
`jl_options` itself. `jl_init_options` is idempotent, so this is a no-op
for the shared build.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
It only initializes the jl_options struct (plus getenv/strtol), and is now
called from the JL_NOTSAFEPOINT path of jl_autoinit_and_adopt_thread, which
the GC analyzer rejects without the annotation.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant