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'.
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.
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
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!
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
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
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
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>.
(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
(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
LLD 4.0 is also which confirms comment 0.
I cannot reproduce this on HEAD at r342641M (and prior) with glib20 2.56.3_2,1 rebuilt Dec 21.
(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)
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
(In reply to Chris Hutchinson from comment #13) Can you post "pkg info glib" output, please.
(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
(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
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.
(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.
(In reply to Dimitry Andric from comment #18) Should we switch back to MK_LLD_IS_LD=no ?
(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?
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
(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.
(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?
(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.
(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.
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.
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.
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.
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
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 ...
(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
EDIT that *should* have read build_linux_chrome.map not patch-build_linux_chrome.map (copy / paste error) Sorry :( --Chris
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
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
The Chromium bug (770264) reports "You do not have permission to view the requested page."
(In reply to Dimitry Andric from comment #27) Patch committed in r489612. Thanks Dimitry!
(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.
(In reply to jhs from comment #35) WIth the patch chromium builds fine in poudriere and starts fine. Thanks
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:~ %
*** Bug 235957 has been marked as a duplicate of this bug. ***
A commit references this bug: Author: riggs Date: Sun Feb 24 17:57:38 UTC 2019 New revision: 493791 URL: https://svnweb.freebsd.org/changeset/ports/493791 Log: Fix linking error with lld 7 Details: - The linker script in mplayer's WRKSRC causes linking problems when used with lld 7. Remove it during post-patch PR: 235957, 220103 Reported by: jakub_lach@mailplus.pl, dim Reviewed by: dim MFH: 2019Q1 Changes: head/multimedia/mencoder/Makefile head/multimedia/mplayer/Makefile head/multimedia/mplayer/Makefile.common head/multimedia/mplayer/Makefile.options
A commit references this bug: Author: riggs Date: Sun Feb 24 18:02:17 UTC 2019 New revision: 493792 URL: https://svnweb.freebsd.org/changeset/ports/493792 Log: MFH: r493791 Fix linking error with lld 7 Details: - The linker script in mplayer's WRKSRC causes linking problems when used with lld 7. Remove it during post-patch PR: 235957, 220103 Reported by: jakub_lach@mailplus.pl, dim Reviewed by: dim Approved by: ports-secteam (riggs) Changes: _U branches/2019Q1/ branches/2019Q1/multimedia/mencoder/Makefile branches/2019Q1/multimedia/mplayer/Makefile branches/2019Q1/multimedia/mplayer/Makefile.common branches/2019Q1/multimedia/mplayer/Makefile.options
This issue is now understood and a few instances have been fixed. O. Hartmann - what is the status of your original issue (in devel/glib20)?
I believe this has been addressed, please reopen if not.
Hi, I am not sure if the bug is really related but I think I have the same symptoms. I am using the pkgsrc framework (from NetBSD) to build glib-2.62.3 on FreeBSD 12.0-RELEASE-p12. I configured pkgsrc to use the basesystem Clang compiler: $ /usr/bin/clang --version FreeBSD clang version 6.0.1 (tags/RELEASE_601/final 335540) (based on LLVM 6.0.1) Target: x86_64-unknown-freebsd12.0 Thread model: posix InstalledDir: /usr/bin The meson configuration process completes without error. But the build process produces the followings: [93/1124] Linking target glib/libglib-2.0.so.0.6200.3. FAILED: glib/libglib-2.0.so.0.6200.3 clang -o glib/libglib-2.0.so.0.6200.3 'glib/4430778@@glib-2.0@sha/deprecated_gallocator.c.o' [...] 'glib/libcharset/6e4c96c@@charset@sta/localcharset.c.o' -I/usr/pkg/include -I/usr/include -I/usr/pkg/include/python3.8 -L/usr/pkg/lib -L/usr/lib -Wl,--as-needed -Wl,--no-undefined -shared -fPIC -Wl,--start-group -Wl,-soname,libglib-2.0.so.0 -O2 -liconv -Wl,-R/usr/pkg/lib -Wl,-R/usr/lib -Wl,-z,nodelete -Wl,-Bsymbolic-functions -Wl,-R/usr/pkg/lib /usr/pkg/lib/libpcre.so -pthread -lintl -Wl,--end-group /usr/bin/ld: error: undefined symbol: environ >>> referenced by genviron.c >>> glib/4430778@@glib-2.0@sha/genviron.c.o:(g_listenv) /usr/bin/ld: error: undefined symbol: environ >>> referenced by genviron.c >>> glib/4430778@@glib-2.0@sha/genviron.c.o:(g_listenv) /usr/bin/ld: error: undefined symbol: environ >>> referenced by genviron.c >>> glib/4430778@@glib-2.0@sha/genviron.c.o:(g_get_environ) /usr/bin/ld: error: undefined symbol: environ >>> referenced by gspawn.c >>> glib/4430778@@glib-2.0@sha/gspawn.c.o:(fork_exec_with_fds) clang: error: linker command failed with exit code 1 (use -v to see invocation) ninja: build stopped: subcommand failed. *** Error code 1 Stop. bmake[1]: stopped in /usr/pkgsrc/devel/glib2 *** Error code 1 Stop. bmake: stopped in /usr/pkgsrc/devel/glib2 I tried to build it using the Clang version provided by pkgsrc: $ /usr/pkg/bin/clang --version clang version 9.0.0 (tags/RELEASE_900/final) Target: x86_64-unknown-freebsd12.0 Thread model: posix InstalledDir: /usr/pkg/bin Since the problem is a linking error, I added LDFLAGS.FreeBSD+= -fuse-ld=/usr/pkg/bin/ld.lld to use the LLD version provided by pkgsrc: $ /usr/pkg/bin/ld.lld --version LLD 9.0.0 (compatible with GNU linkers) But I get similar errors: ld.lld: error: undefined symbol: environ >>> referenced by genviron.c >>> glib/4430778@@glib-2.0@sha/genviron.c.o:(g_listenv) >>> referenced by genviron.c >>> glib/4430778@@glib-2.0@sha/genviron.c.o:(g_listenv) >>> referenced by genviron.c >>> glib/4430778@@glib-2.0@sha/genviron.c.o:(g_get_environ) >>> referenced by gspawn.c >>> glib/4430778@@glib-2.0@sha/gspawn.c.o:(fork_exec_with_fds) clang-9: error: linker command failed with exit code 1 (use -v to see invocation) ninja: build stopped: subcommand failed. *** Error code 1 Stop. bmake[1]: stopped in /usr/pkgsrc/devel/glib2 *** Error code 1 Stop. bmake: stopped in /usr/pkgsrc/devel/glib2 By inspecting the object file, I got the following output: $ readelf -s work/glib-2.62.3/output/glib/4430778\@\@glib-2.0\@sha/genviron.c.o | grep environ 1: 0000000000000000 0 FILE LOCAL DEFAULT ABS genviron.c 7: 0000000000000005 17 OBJECT LOCAL DEFAULT 4 .L__func__.g_environ_getenv 8: 0000000000000027 17 OBJECT LOCAL DEFAULT 4 .L__func__.g_environ_setenv 9: 000000000000006b 19 OBJECT LOCAL DEFAULT 4 .L__func__.g_environ_unsetenv 14: 0000000000000000 0 NOTYPE GLOBAL DEFAULT UND environ 15: 0000000000000000 208 FUNC GLOBAL DEFAULT 2 g_environ_getenv 16: 00000000000000d0 424 FUNC GLOBAL DEFAULT 2 g_environ_setenv 17: 0000000000000280 264 FUNC GLOBAL DEFAULT 2 g_environ_unsetenv 19: 0000000000000590 20 FUNC GLOBAL DEFAULT 2 g_get_environ
I also stumbled upon this problem when building glib manually (not from ports). After peeking at the port's Makefile, I added "-Db_lundef=false" argument to the meson invocation and the problem disappeared.