On 27.12.2018 14:07, Gary Jennejohn wrote:
> On Thu, 27 Dec 2018 03:58:51 -0800
> Enji Cooper <yaneurab...@gmail.com> wrote:
>
>>> On Dec 27, 2018, at 2:17 AM, Trev <freebsd-curr...@sentry.org> wrote:
>>>
>>> Graham Perrin wrote on 26/12/2018 21:20:
>>>> grahamperrin@momh167-gjp4-8570p:~ % date ; uname -v
>>>> Wed Dec 26 10:18:52 GMT 2018
>>>> FreeBSD 13.0-CURRENT r342466 GENERIC-NODEBUG
>>>> grahamperrin@momh167-gjp4-8570p:~ % iridium
>>>> ld-elf.so.1: /usr/local/lib/libglib-2.0.so.0: Undefined symbol "environ"
>>>> grahamperrin@momh167-gjp4-8570p:~ % pkg query '%o %v %R' iridium-browser
>>>> www/iridium 2018.5.67_6 FreeBSD
>>>> grahamperrin@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@, 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
_______________________________________________
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
