Date: Sat, 05 Jan 2019 20:47:48 +0000 From: bugzilla-noreply@freebsd.org To: toolchain@FreeBSD.org Subject: [Bug 220103] devel/glib20: ld-elf.so.1: /usr/local/lib/libglib-2.0.so.0: Undefined symbol "environ" (WITH_LLD_IS_LD) Message-ID: <bug-220103-29464-Wn4Pc7eRsn@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-220103-29464@https.bugs.freebsd.org/bugzilla/> References: <bug-220103-29464@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D220103 --- Comment #28 from Dimitry Andric <dim@FreeBSD.org> --- Created attachment 200811 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D200811&action= =3Dedit Add FreeBSD specific entries to chrome's version map Here is a patch that works for me, at least. It explicitly adds __progname= and environ, which are (as far as I know) the only two symbols that are require= d to be exported from an executable. I'm side stepping the wildcard problem too, but first listing the "local: *" line, then listing the global symbols after that. This works fine for lld,= but I didn't try recent BFD ld yet on it. Chromium is rather expensive in term= s of build time... In any case, this approach can also work for other chromium based ports suc= h as iridium. Mplayer is maybe a simpler case, as its version script can simply= be deleted. --=20 You are receiving this mail because: You are the assignee for the bug. You are on the CC list for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-220103-29464-Wn4Pc7eRsn>