Date: Fri, 28 Dec 2018 13:53:30 +0100 From: Michal Meloun <melounmichal@gmail.com> To: gljennjohn@gmail.com, Enji Cooper <yaneurabeya@gmail.com> Cc: Trev <freebsd-current@sentry.org>, FreeBSD Current <freebsd-current@freebsd.org> Subject: Re: ld-elf.so.1: /usr/local/lib/libglib-2.0.so.0: Undefined symbol "environ" (RPI/arm64) Message-ID: <ac5a6bdd-2888-870c-7757-8a8caed1ca5a@freebsd.org> In-Reply-To: <20181227140706.748bf173@ernst.home> References: <CALvFMRys9oKvCTF7JR=1X81d9G1wFZtCy6Gov2uPuCDGkX=-FA@mail.gmail.com> <d8dfd071-9703-521c-6073-4641c372a926@sentry.org> <3BB1A8CA-272D-4B48-81A2-CBAF7EE23507@gmail.com> <20181227140706.748bf173@ernst.home>
next in thread | previous in thread | raw e-mail | index | archive | help
On 27.12.2018 14:07, Gary Jennejohn wrote: > On Thu, 27 Dec 2018 03:58:51 -0800 > Enji Cooper <yaneurabeya@gmail.com> wrote: > >>> On Dec 27, 2018, at 2:17 AM, Trev <freebsd-current@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?ac5a6bdd-2888-870c-7757-8a8caed1ca5a>