Re: ld-elf.so.1: /usr/local/lib/libglib-2.0.so.0: Undefined symbol "environ" (RPI/arm64)

On 27.12.2018 14:07, Gary Jennejohn wrote:
> On Thu, 27 Dec 2018 03:58:51 -0800
> Enji Cooper <yaneurabeya_at_gmail.com> wrote:
> 
>>> On Dec 27, 2018, at 2:17 AM, Trev <freebsd-current_at_sentry.org> wrote:
>>>
>>> Graham Perrin wrote on 26/12/2018 21:20:  
>>>> grahamperrin_at_momh167-gjp4-8570p:~ % date ; uname -v
>>>> Wed Dec 26 10:18:52 GMT 2018
>>>> FreeBSD 13.0-CURRENT r342466 GENERIC-NODEBUG
>>>> grahamperrin_at_momh167-gjp4-8570p:~ % iridium
>>>> ld-elf.so.1: /usr/local/lib/libglib-2.0.so.0: Undefined symbol "environ"
>>>> grahamperrin_at_momh167-gjp4-8570p:~ % pkg query '%o %v %R' iridium-browser
>>>> www/iridium 2018.5.67_6 FreeBSD
>>>> grahamperrin_at_momh167-gjp4-8570p:~ %
>>>> Any ideas?
>>>> TIA  
>>>
>>> Same problem with a freshly compiled (after 5 days, finished yesterday) www/chromium on RPi3.
>>>
>>> $ chrome
>>> ld-elf.so.1: /usr/local/lib/libglib-2.0.so.0: Undefined symbol "environ"
>>>
>>> $ uname -a
>>> FreeBSD rpi3.sentry.org 13.0-CURRENT FreeBSD 13.0-CURRENT r342189 RPI3 arm64  
>>
>> Hmm___ is something wonky with recent changes to rtld-elf that might be impacting ARM64?
>>
>> CCing mmel_at_, because they might be interested in these bug reports.
>>
> 
> No.  I saw this with mplayer and also iridium when I installed them
> with pkg on AMD64.
> 
> 
> Strangely enough, mpv works, even though it shows a dependency on
> libglib-2.0.so.0 when I run ldd on it.
> 
> glib-2 has "extern char **environ;" in one of its C-files.
> 

I cannot talk about iridium (its i386/amd64 only and I don't want to
infect my headless build box with tons of X11 libraries).
But for multimedia/mplayer, I can say that this problem is caused by
mplayer itself.

The 'environ'  is defined as global symbol in /usr/lib/crt1.o:
>readelf -s /usr/lib/crt1.o | grep environ
    46: 0000000000000008     8 OBJECT  GLOBAL DEFAULT  COM environ

These startup objects (/usr/lib/crt*.o) are linked to each single
executable (but not to shared libraries). That means that any
dynamically linked executable exports 'environ' symbol (and many, many
others) with globally visibility.
>readelf -s /bin/ls | grep environ
    78: 0000000000240000     8 OBJECT  GLOBAL DEFAULT   22 environ

Because these symbols are globally visible, glib20 (and/or other
libraries) can use them.

Unfortunately, when mplayer binary gets linked, makefile uses symbol
version script '-Wl,--version-script,binary.ver' as part of link
command. And this script explicitly lowers visibility of *all* symbols
(but _IO_stdin_used) to local.
>more binary.ver
MPLAYER_1 {
  # to support glibcs abhorrent backwards-compatibility hack
  global: _IO_stdin_used;
  local: *;
};

>readelf -s mplayer | grep environ
    26: 0000000000500000     8 OBJECT  LOCAL  DEFAULT   24 environ

Of course, local symbols are visible only within originating object,
these are invisible for other objects.

I have no idea why mplayer authors uses this script, mainly why version
script is used for *main executable*.
>From my point of view, it's nothing but pure nonsense. This script hides
symbols provided by startup object files so resulting binary is (and
must be) invalid.

I hope that this short description is enough for maintainer to fix these.

Michal