[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 234480] devel/llvm70: Crashes with multimedia/aom >= 1.0.0.1109

[bugzilla-noreply]

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

Brooks Davis  changed:

   What|Removed |Added

  Flags|merge-quarterly?|merge-quarterly+
 Resolution|--- |FIXED
 Status|In Progress |Closed

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

[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"