Skip to content

gcc: defer L4Re loader symbols to runtime in LINK_SPEC#318

Open
sixtyfourktec wants to merge 1 commit into
BobBuildTool:masterfrom
sixtyfourktec:l4re
Open

gcc: defer L4Re loader symbols to runtime in LINK_SPEC#318
sixtyfourktec wants to merge 1 commit into
BobBuildTool:masterfrom
sixtyfourktec:l4re

Conversation

@sixtyfourktec

Copy link
Copy Markdown
Contributor

The dynamic-executable LINK_SPEC sets /rom/libld-l4.so.1 as the interpreter but does not allow undefined symbols in shared libraries. L4Re's libc.so carries no DT_NEEDED on the loader, so ld cannot resolve the loader-provided symbols (dl*, l4re_global_env, l4_global_kip, l4re_env_posix_vfs_ops) at link time and a plain link fails.

Add --allow-shlib-undefined to the dynamic-exe branch so these symbols are bound at load time by the interpreter, matching what the libc -> ld-linux DT_NEEDED chain achieves implicitly on GNU/Linux.

The dynamic-executable LINK_SPEC sets /rom/libld-l4.so.1 as the
interpreter but does not allow undefined symbols in shared libraries.
L4Re's libc.so carries no DT_NEEDED on the loader, so ld cannot resolve
the loader-provided symbols (_dl_*, l4re_global_env, l4_global_kip,
l4re_env_posix_vfs_ops) at link time and a plain link fails.

Add --allow-shlib-undefined to the dynamic-exe branch so these symbols
are bound at load time by the interpreter, matching what the libc ->
ld-linux DT_NEEDED chain achieves implicitly on GNU/Linux.

Signed-off-by: Christian Pötzsch <christian.poetzsch@kernkonzept.com>
@jkloetzke

Copy link
Copy Markdown
Member

I guess it makes more sense to fix L4Re's uclibc build? This workaround doesn't feel right. Especially since other systems don't need them...

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.

2 participants