Date: Sat, 05 Jan 2019 19:44:42 +0000 From: bugzilla-noreply@freebsd.org To: gnome@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-6497-piLFSknJMl@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-220103-6497@https.bugs.freebsd.org/bugzilla/> References: <bug-220103-6497@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 #26 from Dimitry Andric <dim@FreeBSD.org> --- In any case, I just tried www/chromium, and it does exactly the same dumb t= hing as mplayer: $ cat /wrkdirs/usr/ports/www/chromium/work/chromium-68.0.3440.106/build/linux/chr= ome.map { global: __bss_start; __data_start; data_start; _edata; _end; _IO_stdin_used; [...] local: *; }; I think that the idea is to explicitly "whitelist" any variables that are s= afe to export from the main executable, and hide everything else under local. = What the use of such a scheme is, is not really clear. If we don't want to mess with this system too much, we might want to simply= add "environ" and any other necessary symbols to the global list Alternatively, we could just get rid of the linker script completely, and u= se a similar approach for mplayer. We certainly don't need the glibc specific _IO_stdin_used hack. --=20 You are receiving this mail because: 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-6497-piLFSknJMl>