Bug 220103 - devel/glib20: ld-elf.so.1: /usr/local/lib/libglib-2.0.so.0: Undefined symbol "environ" (WITH_LLD_IS_LD)
Summary: devel/glib20: ld-elf.so.1: /usr/local/lib/libglib-2.0.so.0: Undefined symbol ...
Status: Open
Alias: None
Product: Base System
Classification: Unclassified
Component: bin (show other bugs)
Version: CURRENT
Hardware: Any Any
: Normal Affects Many People
Assignee: freebsd-toolchain mailing list
URL:
Keywords: needs-qa
Depends on:
Blocks: 214864 230355
  Show dependency treegraph
 
Reported: 2017-06-18 09:22 UTC by O. Hartmann
Modified: 2019-01-15 02:45 UTC (History)
19 users (show)

See Also:


Attachments
Add FreeBSD specific entries to chrome's version map (1.17 KB, patch)
2019-01-05 20:47 UTC, Dimitry Andric
no flags Details | Diff
Add FreeBSD specific variables as global to multimedia/mplayer/binary.ver (415 bytes, patch)
2019-01-05 22:36 UTC, Max
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description O. Hartmann 2017-06-18 09:22:52 UTC
Running 12-CURRENT (FreeBSD 12.0-CURRENT #55 r320061: Sat Jun 17 23:06:47 CEST 2017 amd64, WITH_LLD_IS_LD=yes), some clients, i.e. multimedia/mplayer, quit service immediately after starting with:

/usr/local/lib/libglib-2.0.so.0: Undefined symbol "environ"

Even after recompiling every(!) port of the system after INO64 update remains the client mplayer unusable and it seems to be an issue with LLVM 4.0 linker 'lld'.
Comment 1 Ed Maste freebsd_committer 2017-08-22 19:56:04 UTC
Thank you for the report.

I cannot reproduce this on FreeBSD-head with Clang+LLD 5.0.0 so I presume this is fixed. Closing as the original submitter is unable to retest at present.
Comment 2 Max 2019-01-01 17:50:44 UTC
Hi

The issue  has become reproducible lately again when attempting to start up www/chromium. This has happened on latest TrueOS/Trident build which is based on FreeBSD-13.0-CURRENT as per below


Can the bug please be re-opened so that it does not look abandoned?


{code}
[~]$ chrome
ld-elf.so.1: /usr/local/lib/libglib-2.0.so.0: Undefined symbol "environ"
[~]$ uname -a
FreeBSD trident-den 13.0-CURRENT FreeBSD 13.0-CURRENT GENERIC-NODEBUG  amd64
{code}


Thanks,
Max
Comment 3 O. Hartmann 2019-01-01 21:14:48 UTC
I see a problem again with multimedia/mplayer on recent 13-CURRENT (FreeBSD 13.0-CURRENT #43 r342666: Tue Jan  1 09:25:45 CET 2019 amd64). The problem seems to have resurfaced around 15th December 2018 (a guess).

Port multimedia/mplayer has been recompiled with "portmaster -f" as well as devel/glib20. No effect!
Comment 4 Max 2019-01-01 21:31:14 UTC
Here is some additional information.



This is quick simple test to verify that clib with environ symbol is present on the system
> #include <stdio.h>
> #include <stddef.h>
> 
> extern char** environ;
> 
> int main(int argc, char *argv[])
> {
>     int count = 0;
> 
>     printf("\n");
>     while(environ[count] != NULL)
>    {
>          printf("[%s] :: ", environ[count]);
>          count++;
>    }
> 
>    return 0;
> }


> [ ~]$ cc test_env.c 
> [~]$ ./a.out 
> 
> [LC_ALL=en_US.UTF-8] ...



Here is ldconfig output
> [~]$ sudo ldconfig -r|grep glib
>         164:-lpyglib-2.0-python2.7.0 => /usr/local/lib/libpyglib-2.0-python2.7.so.0
>         186:-ljson-glib-1.0.0 => /usr/local/lib/libjson-glib-1.0.so.0
>         395:-lglib-2.0.0 => /usr/local/lib/libglib-2.0.so.0
>         439:-ldbus-glib-1.2 => /usr/local/lib/libdbus-glib-1.so.2
>         554:-lavahi-glib.1 => /usr/local/lib/libavahi-glib.so.1
>         726:-lpulse-mainloop-glib.0 => /usr/local/lib/libpulse-mainloop-glib.so.0
>         765:-lpoppler-glib.8 => /usr/local/lib/libpoppler-glib.so.8


> [ ~]$ sudo ldconfig -r|grep "libc.so"
>         33:-lc.7 => /lib/libc.so.7
Comment 5 Max 2019-01-02 02:59:05 UTC
Somehow 'environ' definition is not in the glib-2.0.so binary in contrast to a simple printenv test binary, even after full clean  rebuild of devel/glib20

>[~]$ objdump -T /usr/local/lib/libglib-2.0.so |grep env
>0000000000000000      DF *UND*  0000000000000000  FBSD_1.0    getenv
>0000000000000000      D  *UND*  0000000000000000  Base        environ
>0000000000000000      DF *UND*  0000000000000000  FBSD_1.0    setenv
>>0000000000000000      DF *UND*  0000000000000000  FBSD_1.0    unsetenv
>00000000000b9640 g    DF .text  00000000000000d0  Base        g_environ_getenv
>00000000000b9a00 g    DF .text  000000000000009a  Base        g_setenv
>00000000000b9b10 g    DF .text  00000000000000b4  Base        g_listenv
>00000000000b99d0 g    DF .text  000000000000002c  Base        g_getenv
>00000000000b98c0 g    DF .text  0000000000000108  Base        g_environ_unsetenv
>00000000000b9bd0 g    DF .text  0000000000000014  Base        g_get_environ
>00000000000b9aa0 g    DF .text  0000000000000062  Base        g_unsetenv
>00000000000b9710 g    DF .text  00000000000001af  Base        g_environ_setenv
>[~]$ objdump -T ~/a.out |grep env
>0000000000204000 g    DO .bss   0000000000000008  Base        environ
Comment 6 Kubilay Kocak freebsd_committer freebsd_triage 2019-01-02 11:25:03 UTC
If/when a base change is identified as requirement to resolution, please create a separate issue blocking this one to track its progress/resolution, as ports issues do not contain flags to track MFC's
Comment 7 Dimitry Andric freebsd_committer 2019-01-02 13:00:38 UTC
This seems to be related to bug 234070, in the sense that mplayer (the only concrete example of this problem that I have been able to reproduce) also uses linker symbol versioning script which includes wildcards:

$ cat /wrkdirs/usr/ports/multimedia/mplayer/work/mplayer-export-2018-12-24/binary.ver
MPLAYER_1 {
  # to support glibcs abhorrent backwards-compatibility hack                                                                                                                                                           global: _IO_stdin_used;                                                                                                                                                                                              local: *;                                                                                                                                                                                                          };

Simply eliminating the versioning script should fix the problem for mplayer, at least.

My guess is that the other ports exhibiting this issue are also doing similar tricks with their versioning scripts.

As to the linker behavior with these wildcards, this is still being debated upstream, see the discussion in <https://bugs.llvm.org/show_bug.cgi?id=40176>.
Comment 8 Antoine Brodin freebsd_committer 2019-01-02 13:51:37 UTC
(In reply to Dimitry Andric from comment #7)
Is this something new in LLD 7.0?  I can't reproduce the issue on FreeBSD 12.0
Comment 9 Jan Beich freebsd_committer 2019-01-02 15:41:20 UTC
(In reply to Antoine Brodin from comment #8)
Probably. I can reproduce mplayer issue with LLD 7.0 but not 6.0[1] nor 5.0[2]. Being runtime issue it's not clear how many ports are affected.

[1] LDFLAGS+=-fuse-ld=lld60 + BUILD_DEPENDS+=ld.lld60:devel/llvm60
[2] LDFLAGS+=-fuse-ld=/usr/local/llvm50/bin/ld.lld + BUILD_DEPENDS+=lld50:devel/llvm50
Comment 10 Jan Beich freebsd_committer 2019-01-02 15:52:40 UTC
LLD 4.0 is also which confirms comment 0.
Comment 11 Cy Schubert freebsd_committer 2019-01-02 16:44:18 UTC
I cannot reproduce this on HEAD at r342641M (and prior) with glib20 2.56.3_2,1 rebuilt Dec 21.
Comment 12 Michal Meloun freebsd_committer 2019-01-02 16:53:00 UTC
(In reply to Dimitry Andric from comment #7)
Yes, linker scripts are culprits (at least for mplayer and chromium). And I think that this issue is related to glib-20 at all, it is only first visible victim.

'environ' (and several other symbols) is exported from crt1.o as global symbol. crt1.o (and other startup object files) should be linked to every single dynamically linked program (but not to shared libraries). So, every program should export 'environ' as global symbol. But linker scrips used for 
linking mplayer or chromium lowers visibility of all not enumerated symbols to local, including 'environ' symbol. Thus because 'environ' is referenced at least from libc (or glib-20), runtime linker complains about undefined symbol.

Simply, linker version scrips used for linking target binary are not compatible with FreeBSD (just because startup objects linked with target binary emits global symbols). 

Linker scrips like this

foo {
...
local: *;                                                                                                                                                                                                          };

cannot be applied to symbols originated from startup object (ctr*.o)
Comment 13 Chris Hutchinson 2019-01-04 06:52:57 UTC
Huston. We have a problem...

I can confirm this is a repeatable problem.
www/iridium was built this morning. Firing it off returns:

ld-elf.so.1: /usr/local/lib/libglib-2.0.so.0: Undefined symbol "environ"

This is on 13 with the following versions:

FreeBSD d510 13.0-CURRENT FreeBSD 13.0-CURRENT r342002 OWIRES  amd64

FreeBSD clang version 7.0.1 (branches/release_70 348686) (based on LLVM 7.0.1)
Target: x86_64-unknown-freebsd13.0
Thread model: posix
InstalledDir: /usr/bin

as well as

clang version 6.0.1 (tags/RELEASE_601/final)
Target: x86_64-portbld-freebsd13.0
Thread model: posix
InstalledDir: /usr/local/llvm60/bin

Relative URL: ^/head
Repository Root: svn://svn.freebsd.org/ports
Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5
Revision: 487324
Node Kind: directory
Schedule: normal
Last Changed Author: madpilot
Last Changed Rev: 487324
Last Changed Date: 2018-12-12 12:48:30 -0800 (Wed, 12 Dec 2018)

PORTNAME=	iridium
PORTVERSION=	2018.5.67
PORTREVISION=	6

Is this a new "feature" in 13, or poor assumption(s) by application
programers?

Thank you for all your time, and attention.

--Chris
Comment 14 Cy Schubert freebsd_committer 2019-01-04 07:04:11 UTC
(In reply to Chris Hutchinson from comment #13)

Can you post "pkg info glib" output, please.
Comment 15 Chris Hutchinson 2019-01-04 07:14:53 UTC
(In reply to Chris Hutchinson from comment #13)
> Huston. We have a problem...
> 
> I can confirm this is a repeatable problem.
> www/iridium was built this morning. Firing it off returns:
> 
...
> 
> clang version 6.0.1 (tags/RELEASE_601/final)
> Target: x86_64-portbld-freebsd13.0
> Thread model: posix
> InstalledDir: /usr/local/llvm60/bin
> 
> Relative URL: ^/head
> Repository Root: svn://svn.freebsd.org/ports
> Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5
> Revision: 487324
> Node Kind: directory
> Schedule: normal
> Last Changed Author: madpilot
> Last Changed Rev: 487324
> Last Changed Date: 2018-12-12 12:48:30 -0800 (Wed, 12 Dec 2018)
> 
> PORTNAME=	iridium
> PORTVERSION=	2018.5.67
> PORTREVISION=	6
> 
...
P.S. I *can* reproduce this with clang6.[0.1]
using the following in make.conf(5)

CC=clang60
CXX=clang++60
CPP=clang-cpp60

Just thought it worth mentioning...

--Chris
Comment 16 Chris Hutchinson 2019-01-04 07:17:35 UTC
(In reply to Cy Schubert from comment #14)
> (In reply to Chris Hutchinson from comment #13)
> 
> Can you post "pkg info glib" output, please.

Can do!

glib-2.56.3_2,1
Name           : glib
Version        : 2.56.3_2,1
Installed on   : Thu Dec 13 11:54:18 2018 PST
Origin         : devel/glib20
Architecture   : FreeBSD:13:amd64
Prefix         : /usr/local
Categories     : devel
Licenses       : LGPL20
Maintainer     : gnome@FreeBSD.org
WWW            : https://www.gtk.org/
Comment        : Some useful routines of C programming (current stable version)
Options        :
	DEBUG          : off
	MANPAGES       : on
	NLS            : on
Shared Libs required:
	libpcre.so.1
	libintl.so.8
	libiconv.so.2
	libffi.so.6
Shared Libs provided:
	libgthread-2.0.so.0
	libglib-2.0.so.0
	libgobject-2.0.so.0
	libgio-2.0.so.0
	libgmodule-2.0.so.0
Annotations    :
	FreeBSD_version: 1300005
Flat size      : 20.3MiB
Description    :
GLib provides a simple, abstract, and highly portable set of C support
routines such as lists, trees, hashes, memory allocation, and much, much
more.  It is a foundation for writing portable applications.

WWW: https://www.gtk.org/

HTH

--Chris
Comment 17 Jan Beich freebsd_committer 2019-01-04 08:34:59 UTC
Can someone bisect LLD commits to figure out the cause? Maybe current LLD behavior is unintentional. Also, I wonder if bug 230602 and https://github.com/swaywm/wlroots/issues/1450 are related.
Comment 18 Dimitry Andric freebsd_committer 2019-01-04 13:20:44 UTC
(In reply to Jan Beich from comment #17)
> Can someone bisect LLD commits to figure out the cause? Maybe current LLD
> behavior is unintentional.

I think lld has always behaved this way, e.g. as was reported in <https://bugs.llvm.org/show_bug.cgi?id=40176>, by having later "*" wildcards override earlier ones.

In any case, I tried pretty old lld versions, and they all behave the same way.


> Also, I wonder if bug 230602 and
> https://github.com/swaywm/wlroots/issues/1450 are related.

Bug 230602 was an error in samba's linker scripts, and that wlroot thing looks to be the same sort of error, at first sight.
Comment 19 Antoine Brodin freebsd_committer 2019-01-04 13:50:26 UTC
(In reply to Dimitry Andric from comment #18)
Should we switch back to MK_LLD_IS_LD=no ?
Comment 20 Dimitry Andric freebsd_committer 2019-01-04 14:01:33 UTC
(In reply to Jan Beich from comment #9)
> (In reply to Antoine Brodin from comment #8)
> Probably. I can reproduce mplayer issue with LLD 7.0 but not 6.0[1] nor
> 5.0[2]. Being runtime issue it's not clear how many ports are affected.
> 
> [1] LDFLAGS+=-fuse-ld=lld60 + BUILD_DEPENDS+=ld.lld60:devel/llvm60
> [2] LDFLAGS+=-fuse-ld=/usr/local/llvm50/bin/ld.lld +
> BUILD_DEPENDS+=lld50:devel/llvm50

Hm, this is still strange to me.  I think we need to investigate some more if this is really not something that has changed due to another revision in lld.

E.g. https://bugs.llvm.org/show_bug.cgi?id=40176 is talking about this specific use case:

FOO {
	foo*;
};

BAR {
	*;
};

causing symbols starting with "foo" to end up in the BAR namespace with lld.  As far as I know, this has always been the case.

But with all the chromium based ports, I am not so sure.  Does anybody know what kind of linker script(s) are used in those?
Comment 21 Michal Meloun freebsd_committer 2019-01-04 15:19:14 UTC
Finally, I think I know what's going on. But I warn, it's a really crazy story. And not, this problen is not related to https://bugs.llvm.org/show_bug.cgi?id=40176.

FACT:
Linker version script of all affected ports is and has always been invalid (or, at least, incompatible with FreeBSD).  On FreeBSD, symbols originated from /lib/crt*.o must stay global. Nothing else.

FIX:
At least 'environ' and '__progname' should be put into the global section of the linker script. We do it right for other ports (multimedia/mpv, net/asterisk16), there is no reason not to do it for others.
Why nobody noticed this until now? 
The old in base ld.bfd is very buggy in this area. It doesn't reflect local binding requested by linker script and, moreover, it emits given symbols duplicated. Once without version, second time with requested version.
FreeBSD 11, in base ld.bfd is used for linking:
# readelf -s mplayer | grep environ
 935: 000000000056b8e0 8 OBJECT  GLOBAL DEFAULT   27 environ@@MPLAYER_1 (2)
5384: 000000000056b8e0 8 OBJECT  GLOBAL DEFAULT   27 environ

It's very clear that this is invalid result, but it's also clear that this also negates requested effect of given linker script, so resulting binary is workable.

Should be this problem detected on link time?  Yes, it should.
This is a real (and, in this case, only one) bug in ld.ldd.  It should quit with error message instead of producing not load time linkable binary. 

As quick verification, you can replace default system linker by ld.bfd from binutils. 
In this case, final linking always fails (on FBSD11, 12, current) with: 
/usr/bin/ld: mplayer: local symbol '__progname' in /usr/lib/crt1.o is referenced by DSO

Dim, please, can you submit this but to llvm bugzila?
Michal
Comment 22 Konstantin Belousov freebsd_committer 2019-01-04 16:17:50 UTC
(In reply to Michal Meloun from comment #21)
>  935: 000000000056b8e0 8 OBJECT  GLOBAL DEFAULT   27 environ@@MPLAYER_1 (2)
> 5384: 000000000056b8e0 8 OBJECT  GLOBAL DEFAULT   27 environ

To be fair, typical cause of occurrence of the second unversioned symbol in the
readelf -a output is due to the presence of the static (debugging) symbol table.
It is not used for dynamic symbol resolution, so really only one environ is
exported.  That said, it is wrong for environ to be exported with any
version, as well, it must be unversioned in the dynamic symbol table.  Our
rtld is forgiving but in principle we could check.
Comment 23 Dimitry Andric freebsd_committer 2019-01-04 17:38:59 UTC
(In reply to Michal Meloun from comment #21)
...
> As quick verification, you can replace default system linker by ld.bfd from
> binutils. 
> In this case, final linking always fails (on FBSD11, 12, current) with: 
> /usr/bin/ld: mplayer: local symbol '__progname' in /usr/lib/crt1.o is
> referenced by DSO
> 
> Dim, please, can you submit this but to llvm bugzila?

I'm not sure what bug on the LLD side you are talking about; you are describing a problem with BFD ld above?  As far as the linker is concerned, "environ" is not in any way more special than any other symbol.  If somebody wants to provide versioned and unversioned variants, I don't see any reason why this would be forbidden?
Comment 24 Michal Meloun freebsd_committer 2019-01-05 05:12:11 UTC
(In reply to Dimitry Andric from comment #23)
I was too brief, sorry. 

'environ' symbol is exported from /lib/crt1.o with *global* binding:
# readelf -s /usr/lib/crt1.o | grep environ
    46: 0000000000000008     8 OBJECT  GLOBAL DEFAULT  COM environ

And it's referenced (not only) from /lib/libc:
# readelf -s /lib/libc.so.7  | grep environ
     3: 0000000000000000     0 NOTYPE  GLOBAL DEFAULT  UND environ

For final mplayer link, following command is issued:
'ld … --version-script binary.ver /usr/lib/crt1.o –lc …'
where linker script binary.ver is:
MPLAYER_1 {
  # to support glibcs abhorrent backwards-compatibility hack
  global: _IO_stdin_used;
  local: *;
};

This script changes binding of all (but  _IO_stdin_used) symbols exported by mplayer from *global* to *local*, including ‘environ’ symbol from linked in crt1.o. Due to this, 'environ' becomes invisible to other DSO (libc..). So resulting binary is invalid, it cannot be run-time loaded and linker should report this issue.
Everything above is also valid for '__progname' symbol.

Actual ld.bfd (2.30, from binutils) correctly report this problem and reject to build invalid binary:
/usr/bin/ld: mplayer: local symbol '__progname' in /usr/lib/crt1.o is referenced by DSO

But ld.lld(7.0.1) doesn't and silently produces invalid binary.

The lack of error report and unloadable binary is, imho, evident ld.lld bug.

I can prepare trivial testcase for this, if you want it.
Comment 25 Michal Meloun freebsd_committer 2019-01-05 05:52:02 UTC
(In reply to Konstantin Belousov from comment #22)
> To be fair, typical cause of occurrence of the second unversioned symbol in
> the readelf -a output is due to the presence of the static (debugging)
> symbol table.
Aha, I did not know this. Thanks for info.

> That said, it is wrong for environ to be exported with any
> version, as well, it must be unversioned in the dynamic symbol table. Our
> rtld is forgiving but in principle we could check.
True. Using version script for final binary (not DSO) looks like stupid idea,
mainly if it contains 'local: *' clause. Moreover, there are more (other then  '__progname' and 'environ') global symbols exported by /lib/crt*.o stuff.
All above is only quick fix for actual damage.

At this point, and if these programs are really needs version scripts, I know about only one real solution. Final link should be splitted to two phases. First phase should link all local objects to one big while applying version script. Second phase should do final link by using resulting object from first step without issuing version script.

But that's a big change, it's hard to tell if it's right and if is acceptable by upstream.
Comment 26 Dimitry Andric freebsd_committer 2019-01-05 19:44:42 UTC
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.
Comment 27 Dimitry Andric freebsd_committer 2019-01-05 19:59:08 UTC
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.
Comment 28 Dimitry Andric freebsd_committer 2019-01-05 20:47:48 UTC
Created attachment 200811 [details]
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.
Comment 29 Max 2019-01-05 22:36:30 UTC
Created attachment 200815 [details]
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
Comment 30 Michal Meloun freebsd_committer 2019-01-06 08:02:08 UTC
Only FYI. Reordering of local and global sections isn't necessary in this case. Seems that global section have priority before local section.


root@tegra210:/usr/ports/multimedia/mplayer/work/mplayer-export-2018-12-24 # ld -v
LLD 7.0.1 (FreeBSD 349250-1300001) (compatible with GNU linkers)

root@tegra210:/usr/ports/multimedia/mplayer/work/mplayer-export-2018-12-24 # more binary.ver
MPLAYER_1 {
  # to support glibcs abhorrent backwards-compatibility hack
  global: _IO_stdin_used;
          __progname;
          environ;

  local: *;
};

root@tegra210:/usr/ports/multimedia/mplayer/work/mplayer-export-2018-12-24 # readelf -s ./mplayer | grep environ
   818: 0000000000500000     8 OBJECT  GLOBAL DEFAULT   24 environ@@MPLAYER_1 (2)
  7023: 0000000000500000     8 OBJECT  GLOBAL DEFAULT   24 environ

root@tegra210:/usr/ports/multimedia/mplayer/work/mplayer-export-2018-12-24 # ./mplayer
MPlayer SVN-r38119-snapshot-7.0.1 (C) 2000-2018 MPlayer Team
Usage:   mplayer [options] [url|path/]filename
...
Comment 31 Chris Hutchinson 2019-01-06 23:37:31 UTC
(In reply to Dimitry Andric from comment #28)
> Created attachment 200811 [details]
> 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.

Thank you for all the time you've spent on this! I was also going to
give that a try. But hadn't found enough time to test it.. till now.
My results were negative. :(
As I had already built, and installed it. I performed the following:
# cd /usr/ports/iridium
# make deinstall
# make patch
edited the patch-build_linux_chrome.map file. moving the local clause,
and asterisk above the global stanzas. then performing
# make
... looonnnggg time later ...
# make install
But no joy. Same result(s) as before. Do I perhaps need to clean out
ld(1)'s cache? Dunno. I didn't build a package prior to this. So I
can count on pkg(8) not having used a prior built package.

Thanks again!

--Chris
Comment 32 Chris Hutchinson 2019-01-06 23:43:57 UTC
EDIT
that *should* have read

build_linux_chrome.map

not

patch-build_linux_chrome.map

(copy / paste error) Sorry :(

--Chris
Comment 33 Max 2019-01-07 00:32:23 UTC
I was able to successfully build and start up www/chromium after applying the attached patch  chrome.map

www/iridium build is in progress but I expect it to be successful as well since it seems to be the same linker script.

Thanks,
Max
Comment 34 Max 2019-01-07 00:32:51 UTC
I was able to successfully build and start up www/chromium after applying the attached patch  chrome.map

www/iridium build is in progress but I expect it to be successful as well since it seems to be the same linker script.

Thanks,
Max
Comment 35 jhs 2019-01-07 16:31:13 UTC
Me too: I was able to successfully build and start up www/chromium after applying the attached patch  chrome.map
Thanks Dimitry Andric

I also confirmed this patch work to
https://lists.freebsd.org/pipermail/freebsd-current/2019-January/072629.html
Comment 36 Ed Maste freebsd_committer 2019-01-07 17:01:49 UTC
The Chromium bug (770264) reports "You do not have permission to view the requested page."
Comment 37 Carlos J. Puga Medina freebsd_committer 2019-01-07 20:05:04 UTC
(In reply to Dimitry Andric from comment #27)

Patch committed in r489612.

Thanks Dimitry!
Comment 38 Ed Maste freebsd_committer 2019-01-07 20:16:52 UTC
(In reply to Kubilay Kocak from comment #6)
> If/when a base change is identified as requirement to resolution, please create
> a separate issue blocking this one to track its progress/resolution, as ports
> issues do not contain flags to track MFC's

It looks like there should be an lld change to make these build time errors instead of run time, but the real fixes need to be made to the individual ports that have incorrect (for FreeBSD) symbol version maps.
Comment 39 Matthias Apitz 2019-01-08 05:40:57 UTC
(In reply to jhs from comment #35)
WIth the patch chromium builds fine in poudriere and starts fine. Thanks
Comment 40 Graham Perrin 2019-01-15 02:45:30 UTC
Follow-up to <https://lists.freebsd.org/pipermail/freebsd-current/2018-December/072516.html>

Now I can run both www/chromium and www/iridium – thanks, folks. 

grahamperrin@momh167-gjp4-8570p:~ % date ; uname -v
Tue 15 Jan 2019 02:42:00 GMT
FreeBSD 13.0-CURRENT r343023 GENERIC-NODEBUG 
grahamperrin@momh167-gjp4-8570p:~ % pkg query '%o %v %R' chromium iridium-browser
www/chromium 71.0.3578.98_2 FreeBSD
www/iridium 2018.5.67_7 FreeBSD
grahamperrin@momh167-gjp4-8570p:~ %