[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

--- Comment #24 from Michal Meloun <mmel at FreeBSD.org> ---
(In reply to Dimitry Andric from comment #23)
I was too brief, sorry. 

'environ' symbol is exported from /lib/crt1.o with *global* binding:
# readelf -s /usr/lib/crt1.o | grep environ
    46: 0000000000000008     8 OBJECT  GLOBAL DEFAULT  COM environ

And it's referenced (not only) from /lib/libc:
# readelf -s /lib/libc.so.7  | grep environ
     3: 0000000000000000     0 NOTYPE  GLOBAL DEFAULT  UND environ

For final mplayer link, following command is issued:
'ld … --version-script binary.ver /usr/lib/crt1.o –lc …'
where linker script binary.ver is:
MPLAYER_1 {
  # to support glibcs abhorrent backwards-compatibility hack
  global: _IO_stdin_used;
  local: *;
};

This script changes binding of all (but  _IO_stdin_used) symbols exported by
mplayer from *global* to *local*, including ‘environ’ symbol from linked in
crt1.o. Due to this, 'environ' becomes invisible to other DSO (libc..). So
resulting binary is invalid, it cannot be run-time loaded and linker should
report this issue.
Everything above is also valid for '__progname' symbol.

Actual ld.bfd (2.30, from binutils) correctly report this problem and reject to
build invalid binary:
/usr/bin/ld: mplayer: local symbol '__progname' in /usr/lib/crt1.o is
referenced by DSO

But ld.lld(7.0.1) doesn't and silently produces invalid binary.

The lack of error report and unloadable binary is, imho, evident ld.lld bug.

I can prepare trivial testcase for this, if you want it.

-- 
You are receiving this mail because:
You are on the CC list for the bug.