[Bug 220103] devel/glib20: ld-elf.so.1: /usr/local/lib/libglib-2.0.so.0: Undefined symbol "environ" (WITH_LLD_IS_LD)

[bugzilla-noreply at freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=220103

Michal Meloun <mmel at FreeBSD.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mmel at FreeBSD.org

--- Comment #12 from Michal Meloun <mmel at 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.