Date: Sat, 05 Jan 2019 19:44:42 +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-lwmI6HdV4x@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=220103 --- Comment #26 from Dimitry Andric <dim@FreeBSD.org> --- In any case, I just tried www/chromium, and it does exactly the same dumb thing as mplayer: $ cat /wrkdirs/usr/ports/www/chromium/work/chromium-68.0.3440.106/build/linux/chrome.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 safe 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 use a similar approach for mplayer. We certainly don't need the glibc specific _IO_stdin_used hack. -- You are receiving this mail because: You are on the CC list for the bug. You are the assignee for the bug.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-220103-29464-lwmI6HdV4x>