[Bug 220103] devel/glib20: ld-elf.so.1: /usr/local/lib/libglib-2.0.so.0: Undefined symbol "environ" (WITH_LLD_IS_LD)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=220103 --- Comment #29 from Max --- Created attachment 200815 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=200815&action=edit Add FreeBSD specific variables as global to multimedia/mplayer/binary.ver Great! I have just tried to do the similar patch on multimedia/mplayer to test this and the app started successfully. www/chromium and www/iridium are still building on my machine... Thanks, Max -- You are receiving this mail because: You are on the CC list for the bug. You are the assignee for the bug. ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
[Bug 220103] devel/glib20: ld-elf.so.1: /usr/local/lib/libglib-2.0.so.0: Undefined symbol "environ" (WITH_LLD_IS_LD)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=220103 --- Comment #28 from Dimitry Andric --- Created attachment 200811 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=200811&action=edit 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 required 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 terms of build time... In any case, this approach can also work for other chromium based ports such as iridium. Mplayer is maybe a simpler case, as its version script can simply be deleted. -- You are receiving this mail because: You are the assignee for the bug. You are on the CC list for the bug. ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
[Bug 220103] devel/glib20: ld-elf.so.1: /usr/local/lib/libglib-2.0.so.0: Undefined symbol "environ" (WITH_LLD_IS_LD)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=220103 --- Comment #27 from Dimitry Andric --- It looks like the chromium version script was introduced here: https://chromium.googlesource.com/chromium/src.git/+/83365024efd81b5f3439d95c5560465ad2110388%5E%21/ "[Linux build] Add a linker version script to prevent symbol leaks Bug 770264 was caused by accidentally leaking FreeType symbols from Chrome. This CL adds a linker version script to ensure new leaks do not happen. Any newly exported symbols must be explicitly added to the version script." Unfortunately the chromium issue itself, https://bugs.chromium.org/p/chromium/issues/detail?id=770264 apparently, is not viewable by mere mortals. So much for open source. :) In any case, it seems that chromium has assumed the responsibility of keeping up-to-date with all the required exported symbols to make an executable work. So probably an upstream bug report is needed, together with a list of FreeBSD specific symbols that must always be exported. -- You are receiving this mail because: You are on the CC list for the bug. You are the assignee for the bug. ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
[Bug 220103] devel/glib20: ld-elf.so.1: /usr/local/lib/libglib-2.0.so.0: Undefined symbol "environ" (WITH_LLD_IS_LD)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=220103
--- Comment #26 from Dimitry Andric ---
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.
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
