Date: Wed, 02 Jan 2019 16:53:00 +0000 From: bugzilla-noreply@freebsd.org To: toolchain@FreeBSD.org Subject: [Bug 220103] devel/glib20: ld-elf.so.1: /usr/local/lib/libglib-2.0.so.0: Undefined symbol "environ" (WITH_LLD_IS_LD) Message-ID: <bug-220103-29464-GcCjQN3NYm@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-220103-29464@https.bugs.freebsd.org/bugzilla/> References: <bug-220103-29464@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=220103 Michal Meloun <mmel@FreeBSD.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |mmel@FreeBSD.org --- Comment #12 from Michal Meloun <mmel@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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-220103-29464-GcCjQN3NYm>