https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=220103
Michal Meloun <m...@freebsd.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |m...@freebsd.org
--- Comment #12 from Michal Meloun <m...@freebsd.org> ---
(In reply to Dimitry Andric from comment #7)
Yes, linker scripts are culprits (at least for mplayer and chromium). And I
think that this issue is related to glib-20 at all, it is only first visible
victim.
'environ' (and several other symbols) is exported from crt1.o as global symbol.
crt1.o (and other startup object files) should be linked to every single
dynamically linked program (but not to shared libraries). So, every program
should export 'environ' as global symbol. But linker scrips used for
linking mplayer or chromium lowers visibility of all not enumerated symbols to
local, including 'environ' symbol. Thus because 'environ' is referenced at
least from libc (or glib-20), runtime linker complains about undefined symbol.
Simply, linker version scrips used for linking target binary are not compatible
with FreeBSD (just because startup objects linked with target binary emits
global symbols).
Linker scrips like this
foo {
...
local: *;
};
cannot be applied to symbols originated from startup object (ctr*.o)
--
You are receiving this mail because:
You are the assignee for the bug.
You are on the CC list for the bug.
_______________________________________________
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
