[Bug 220103] devel/glib20: ld-elf.so.1: /usr/local/lib/libglib-2.0.so.0: Undefined symbol "environ" (WITH_LLD_IS_LD)

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=220103

Jan Beich  changed:

   What|Removed |Added

   See Also|https://bugs.freebsd.org/bu |
   |gzilla/show_bug.cgi?id=2555 |
   |90  |

-- 
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)

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=220103

Kubilay Kocak  changed:

   What|Removed |Added

   See Also||https://bugs.freebsd.org/bu
   ||gzilla/show_bug.cgi?id=2555
   ||90

-- 
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)

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=220103

Gleb Popov  changed:

   What|Removed |Added

 CC||arr...@freebsd.org

--- Comment #47 from Gleb Popov  ---
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.

-- 
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)

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=220103

Kubilay Kocak  changed:

   What|Removed |Added

 Resolution|Unable to Reproduce |FIXED

-- 
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)

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=220103

Frédéric Fauberteau  changed:

   What|Removed |Added

 CC||tri...@netbsd.org

--- Comment #46 from Frédéric Fauberteau  ---
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:  0 FILELOCAL  DEFAULT  ABS genviron.c
 7: 000517 OBJECT  LOCAL  DEFAULT4
.L__func__.g_environ_getenv
 8: 002717 OBJECT  LOCAL  DEFAULT4
.L__func__.g_environ_setenv
 9: 006b19 OBJECT  LOCAL  DEFAULT4
.L__func__.g_environ_unsetenv
14:  0 NOTYPE  GLOBAL DEFAULT  UND environ
15:    208 FUNCGLOBAL DEFAULT2 g_environ_getenv
16: 00d0   424 FUNCGLOBAL DEFAULT2 g_environ_setenv
17: 0280   264 FUNCGLOBAL DEFAULT2 g_environ_unsetenv
19: 059020 FUNCGLOBAL DEFAULT2 g_get_environ

-- 
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)

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=220103

Ed Maste  changed:

   What|Removed |Added

 Resolution|--- |Unable to Reproduce
 Status|Open|Closed

--- Comment #45 from Ed Maste  ---
I believe this has been addressed, please reopen if not.

-- 
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)

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=220103

--- Comment #42 from commit-h...@freebsd.org ---
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_l...@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

-- 
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)

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=220103

--- Comment #43 from commit-h...@freebsd.org ---
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_l...@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

-- 
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)

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=220103

Dimitry Andric  changed:

   What|Removed |Added

 CC||jakub_l...@mailplus.pl

--- Comment #41 from Dimitry Andric  ---
*** Bug 235957 has been marked as a duplicate of this bug. ***

-- 
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)

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=220103

--- Comment #39 from Matthias Apitz  ---
(In reply to jhs from comment #35)
WIth the patch chromium builds fine in poudriere and starts fine. Thanks

-- 
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)

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=220103

--- Comment #38 from Ed Maste  ---
(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.

-- 
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)

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=220103

--- Comment #37 from Carlos J. Puga Medina  ---
(In reply to Dimitry Andric from comment #27)

Patch committed in r489612.

Thanks Dimitry!

-- 
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)

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=220103

--- Comment #36 from Ed Maste  ---
The Chromium bug (770264) reports "You do not have permission to view the
requested page."

-- 
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)

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=220103

j...@berklix.com changed:

   What|Removed |Added

 CC||j...@berklix.com

--- Comment #35 from j...@berklix.com ---
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

-- 
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)

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=220103

Kubilay Kocak  changed:

   What|Removed |Added

   See Also||https://bugs.chromium.org/p
   ||/chromium/issues/detail?id=
   ||770264

-- 
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)

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=220103

--- Comment #34 from Max  ---
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

-- 
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)

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=220103

--- Comment #33 from Max  ---
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

-- 
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)

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=220103

--- Comment #32 from Chris Hutchinson  ---
EDIT
that *should* have read

build_linux_chrome.map

not

patch-build_linux_chrome.map

(copy / paste error) Sorry :(

--Chris

-- 
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)

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=220103

--- Comment #31 from Chris Hutchinson  ---
(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

-- 
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)

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=220103

--- Comment #30 from Michal Meloun  ---
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-131) (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: 0050 8 OBJECT  GLOBAL DEFAULT   24 environ@@MPLAYER_1
(2)
  7023: 0050 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
...

-- 
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)

[bugzilla-noreply]

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=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)

[bugzilla-noreply]

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)

[bugzilla-noreply]

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"

[Bug 220103] devel/glib20: ld-elf.so.1: /usr/local/lib/libglib-2.0.so.0: Undefined symbol "environ" (WITH_LLD_IS_LD)

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=220103

--- Comment #25 from Michal Meloun  ---
(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.

-- 
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)

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=220103

--- Comment #24 from Michal Meloun  ---
(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: 0008 8 OBJECT  GLOBAL DEFAULT  COM environ

And it's referenced (not only) from /lib/libc:
# readelf -s /lib/libc.so.7  | grep environ
 3:  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.

-- 
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)

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=220103

--- Comment #23 from Dimitry Andric  ---
(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?

-- 
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)

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=220103

Konstantin Belousov  changed:

   What|Removed |Added

 CC||k...@freebsd.org

--- Comment #22 from Konstantin Belousov  ---
(In reply to Michal Meloun from comment #21)
>  935: 0056b8e0 8 OBJECT  GLOBAL DEFAULT   27 environ@@MPLAYER_1 (2)
> 5384: 0056b8e0 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.

-- 
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)

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=220103

--- Comment #20 from Dimitry Andric  ---
(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?

-- 
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)

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=220103

--- Comment #19 from Antoine Brodin  ---
(In reply to Dimitry Andric from comment #18)
Should we switch back to MK_LLD_IS_LD=no ?

-- 
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)

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=220103

--- Comment #18 from Dimitry Andric  ---
(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
, 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.

-- 
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)

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=220103

--- Comment #17 from Jan Beich  ---
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.

-- 
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)

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=220103

Michal Meloun  changed:

   What|Removed |Added

 CC||m...@freebsd.org

--- Comment #12 from Michal Meloun  ---
(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)

-- 
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)

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=220103

--- Comment #11 from Cy Schubert  ---
I cannot reproduce this on HEAD at r342641M (and prior) with glib20 2.56.3_2,1
rebuilt Dec 21.

-- 
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)

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=220103

--- Comment #10 from Jan Beich  ---
LLD 4.0 is also which confirms comment 0.

-- 
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)

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=220103

Jan Beich  changed:

   What|Removed |Added

 CC||jbe...@freebsd.org
 Blocks||230355, 214864

--- Comment #9 from Jan Beich  ---
(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


Referenced Bugs:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=214864
[Bug 214864] [exp-run] test build with lld as /usr/bin/ld
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=230355
[Bug 230355] [exp-run] Against projects/clang700-import branch
-- 
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)

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=220103

--- Comment #8 from Antoine Brodin  ---
(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

-- 
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)

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=220103

Kubilay Kocak  changed:

   What|Removed |Added

  Flags|maintainer-feedback?(gnome@ |
   |FreeBSD.org)|
   See Also||https://bugs.freebsd.org/bu
   ||gzilla/show_bug.cgi?id=2340
   ||70,
   ||https://bugs.llvm.org/show_
   ||bug.cgi?id=40176

-- 
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)

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=220103

Dimitry Andric  changed:

   What|Removed |Added

 CC||d...@freebsd.org

--- Comment #7 from Dimitry Andric  ---
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 .

-- 
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)

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=220103

Antoine Brodin  changed:

   What|Removed |Added

  Component|Individual Port(s)  |bin
   Assignee|gn...@freebsd.org   |toolch...@freebsd.org
Product|Ports & Packages|Base System
Version|Latest  |CURRENT

-- 
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)

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=220103

Kubilay Kocak  changed:

   What|Removed |Added

 CC||toolch...@freebsd.org

-- 
You are receiving this mail because:
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"