Re: ld-elf.so.1: /usr/local/lib/libglib-2.0.so.0: Undefined symbol "environ" (RPI/arm64)
On 23 Feb 2019, at 16:48, Jan Beich wrote: > > Jakub Lach writes: > >> Hello, >> >> I'm on FreeBSD 12.0-STABLE #0 r344261 amd64. >> >> I've rebuilt all ports after clang 7 import to 12-STABLE. >> >> Now I get with mplayer >> >> ld-elf.so.1: /lib/libc.so.7: Undefined symbol "__progname" > > https://svnweb.freebsd.org/changeset/ports/490727 needs to be adjusted > for -STABLE as well. No, the correct solution is to fix mplayer's linker script, or better, to delete it entirely. :-) Afterwards, r490727 can be reverted. -Dimitry signature.asc Description: Message signed with OpenPGP
Re: ld-elf.so.1: /usr/local/lib/libglib-2.0.so.0: Undefined symbol "environ" (RPI/arm64)
Jakub Lach writes: > Hello, > > I'm on FreeBSD 12.0-STABLE #0 r344261 amd64. > > I've rebuilt all ports after clang 7 import to 12-STABLE. > > Now I get with mplayer > > ld-elf.so.1: /lib/libc.so.7: Undefined symbol "__progname" https://svnweb.freebsd.org/changeset/ports/490727 needs to be adjusted for -STABLE as well. Details are in https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=220103 ___ 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"
Re: ld-elf.so.1: /usr/local/lib/libglib-2.0.so.0: Undefined symbol "environ" (RPI/arm64)
Hello, I'm on FreeBSD 12.0-STABLE #0 r344261 amd64. I've rebuilt all ports after clang 7 import to 12-STABLE. Now I get with mplayer ld-elf.so.1: /lib/libc.so.7: Undefined symbol "__progname" -- Sent from: http://freebsd.1045724.x6.nabble.com/freebsd-current-f3875308.html ___ 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"
Re: ld-elf.so.1: /usr/local/lib/libglib-2.0.so.0: Undefined symbol "environ" (RPI/arm64)
Hi, Reference:
> From: "Julian H. Stacey"
> Date: Sun, 06 Jan 2019 23:31:03 +0100
"Julian H. Stacey" wrote:
> Gary Jennejohn wrote:
> > On Sun, 06 Jan 2019 08:13:52 +0100
> > "Julian H. Stacey" wrote:
> >
> > > > > > $ chrome
> > > > > > ld-elf.so.1: /usr/local/lib/libglib-2.0.so.0: Undefined symbol
> > > > > > "environ"
> > >
> > > [ Delayed report (as it took about 2 days to build chrome from ports/)]
> > > ...
> > >
> > > I too am still seing from chrome:
> > > ld-elf.so.1: /usr/local/lib/libglib-2.0.so.0: Undefined symbol "environ"
> > > which I first saw from chrome after a pkg add, but now too from a ports/
> > > build
> > >
> > > My src/ was maybe a week or so old. To be precise on next failure report,
> > > I've since added WITHOUT_REPRODUCIBLE_BUILD="YES" to /etc/src.conf
> > > & finished a buildworld on .svn_revision 342785, now running buildkernel
> > >
> >
> > IIRC the problem was attributed to some flags being passed to the
> > compiler or linker. Don't know exactly which reply, but it
> > should be findable in the mail-list database. AFAIK it was never
> > verified that it was the cause.
>
> Thanks Gary, my world is now updated to
> uname -a
> FreeBSD lapr.js.berklix.net 13.0-CURRENT FreeBSD 13.0-CURRENT #0: Sun Jan 6
> 08:06:58 CET 2019
> j...@lapr.js.berklix.net:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64
> /usr/src/.svn_revision 342810
>
> chrome still fails
>
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=220103
> has 30 comments inc. 2 patches (That Ive had no time to try yet)
chrome now works after I hand patched my already built /usr/ports/www/chromium
using this patch
--
--- build/linux/chrome.map.orig 2018-08-08 19:10:32 UTC
+++ build/linux/chrome.map
@@ -1,4 +1,7 @@
{
+local:
+ *;
+
global:
__bss_start;
__data_start;
@@ -20,6 +23,10 @@ global:
# Program entry point.
_start;
+ # FreeBSD specific variables.
+ __progname;
+ environ;
+
# Memory allocation symbols. We want chrome and any libraries to
# share the same heap, so it is correct to export these symbols.
calloc;
@@ -81,7 +88,4 @@ global:
localtime64;
localtime64_r;
localtime_r;
-
-local:
- *;
};
--
which looks like
https://bugs.freebsd.org/bugzilla/attachment.cgi?id=200811&action=diff
I extracted mine by hand from
https://bz-attachments.freebsd.org/attachment.cgi?id=200811
Where Max also says it works.
Thanks to Dimitry Andric cc'd for the patch,
I hope it gets commited.
Cheers,
Julian
--
Julian Stacey, Computer Consultant Sys.Eng. BSD Linux Unix, Munich Aachen Kent
First referendum stole 700,000 votes from Brits in EU; 3,700,000 globaly.
Lies criminal funded; jobs pound & markets down. 1.9M new voters 1.3M dead.
Email MP: "A new referendum will buy UK & EU more time (Art 50.3), to avoid
a hard crash, & consider all options." http://berklix.org/brexit/#mp
___
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"
Re: ld-elf.so.1: /usr/local/lib/libglib-2.0.so.0: Undefined symbol "environ" (RPI/arm64)
Gary Jennejohn wrote: > On Sun, 06 Jan 2019 08:13:52 +0100 > "Julian H. Stacey" wrote: > > > > > > $ chrome > > > > > ld-elf.so.1: /usr/local/lib/libglib-2.0.so.0: Undefined symbol > > > > > "environ" > > > > [ Delayed report (as it took about 2 days to build chrome from ports/)] ... > > > > I too am still seing from chrome: > > ld-elf.so.1: /usr/local/lib/libglib-2.0.so.0: Undefined symbol "environ" > > which I first saw from chrome after a pkg add, but now too from a ports/ > > build > > > > My src/ was maybe a week or so old. To be precise on next failure report, > > I've since added WITHOUT_REPRODUCIBLE_BUILD="YES" to /etc/src.conf > > & finished a buildworld on .svn_revision 342785, now running buildkernel > > > > IIRC the problem was attributed to some flags being passed to the > compiler or linker. Don't know exactly which reply, but it > should be findable in the mail-list database. AFAIK it was never > verified that it was the cause. Thanks Gary, my world is now updated to uname -a FreeBSD lapr.js.berklix.net 13.0-CURRENT FreeBSD 13.0-CURRENT #0: Sun Jan 6 08:06:58 CET 2019 j...@lapr.js.berklix.net:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64 /usr/src/.svn_revision 342810 chrome still fails https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=220103 has 30 comments inc. 2 patches (That Ive had no time to try yet) Cheers, Julian -- Julian Stacey, Computer Consultant Sys.Eng. BSD Linux Unix, Munich Aachen Kent First referendum stole 700,000 votes from Brits in EU; 3,700,000 globaly. Lies criminal funded; jobs pound & markets down. 1.9M new voters 1.3M dead. Email MP: "A new referendum will buy UK & EU more time (Art 50.3), to avoid a hard crash, & consider all options." http://berklix.org/brexit/#mp ___ 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"
Re: ld-elf.so.1: /usr/local/lib/libglib-2.0.so.0: Undefined symbol "environ" (RPI/arm64)
On Sun, 06 Jan 2019 08:13:52 +0100 "Julian H. Stacey" wrote: > > > > $ chrome > > > > ld-elf.so.1: /usr/local/lib/libglib-2.0.so.0: Undefined symbol > > > > "environ" > > [ Delayed report (as it took about 2 days to build chrome from ports/)] ... > > I too am still seing from chrome: > ld-elf.so.1: /usr/local/lib/libglib-2.0.so.0: Undefined symbol "environ" > which I first saw from chrome after a pkg add, but now too from a ports/ build > > My src/ was maybe a week or so old. To be precise on next failure report, > I've since added WITHOUT_REPRODUCIBLE_BUILD="YES" to /etc/src.conf > & finished a buildworld on .svn_revision 342785, now running buildkernel > IIRC the problem was attributed to some flags being passed to the compiler or linker. Don't know exactly which reply, but it should be findable in the mail-list database. AFAIK it was never verified that it was the cause. -- Gary Jennejohn ___ 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"
Re: ld-elf.so.1: /usr/local/lib/libglib-2.0.so.0: Undefined symbol "environ" (RPI/arm64)
> > > $ chrome > > > ld-elf.so.1: /usr/local/lib/libglib-2.0.so.0: Undefined symbol "environ" [ Delayed report (as it took about 2 days to build chrome from ports/)] ... I too am still seing from chrome: ld-elf.so.1: /usr/local/lib/libglib-2.0.so.0: Undefined symbol "environ" which I first saw from chrome after a pkg add, but now too from a ports/ build My src/ was maybe a week or so old. To be precise on next failure report, I've since added WITHOUT_REPRODUCIBLE_BUILD="YES" to /etc/src.conf & finished a buildworld on .svn_revision 342785, now running buildkernel Cheers, Julian -- Julian Stacey, Computer Consultant Sys.Eng. BSD Linux Unix, Munich Aachen Kent First referendum stole 700,000 votes from Brits in EU; 3,700,000 globaly. Lies criminal funded; jobs pound & markets down. 1.9M new voters 1.3M dead. Email MP: "A new referendum will buy UK & EU more time (Art 50.3), to avoid a hard crash, & consider all options." http://berklix.org/brexit/#mp ___ 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"
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 wrote:
>
>>> On Dec 27, 2018, at 2:17 AM, Trev 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: 0008 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: 0024 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: 0050 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"
Re: ld-elf.so.1: /usr/local/lib/libglib-2.0.so.0: Undefined symbol "environ" (RPI/arm64)
On Thu, 27 Dec 2018 03:58:51 -0800 Enji Cooper wrote: > > On Dec 27, 2018, at 2:17 AM, Trev 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. -- Gary Jennejohn ___ 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"
Re: ld-elf.so.1: /usr/local/lib/libglib-2.0.so.0: Undefined symbol "environ" (RPI/arm64)
> On Dec 27, 2018, at 2:17 AM, Trev 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. Cheers, -Enji signature.asc Description: Message signed with OpenPGP
