public inbox for glibc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug nptl/29834] New: libpthread.so lacks GLIBC_PRIVATE version for glibc 2.34 and later
@ 2022-11-29 11:53 misch at google dot com
  2022-11-29 12:11 ` [Bug nptl/29834] " misch at google dot com
                   ` (3 more replies)
  0 siblings, 4 replies; 5+ messages in thread
From: misch at google dot com @ 2022-11-29 11:53 UTC (permalink / raw)
  To: glibc-bugs

https://sourceware.org/bugzilla/show_bug.cgi?id=29834

            Bug ID: 29834
           Summary: libpthread.so lacks GLIBC_PRIVATE version for glibc
                    2.34 and later
           Product: glibc
           Version: 2.34
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: nptl
          Assignee: unassigned at sourceware dot org
          Reporter: misch at google dot com
                CC: drepper.fsp at gmail dot com
  Target Milestone: ---

Created attachment 14474
  --> https://sourceware.org/bugzilla/attachment.cgi?id=14474&action=edit
Patch to restore GLIBC_PRIVATE version for libpthread.so

Since glibc 2.34 libpthread.so no longer provides the GLIBC_PRIVATE version.
This in turn causes problems with closed source software which we can't
recompile ourselves. I've filed this bug to discuss if it would make sense to
restore the GLIBC_PRIVATE version.


Details:
Commit e8d52b64a54ba9ed7778ca9ce1f084eb5808f8d1 [1] removed the GLIBC_PRIVATE
version from libthread.so. This in turn caused closed source software by
Synopsys [2] to fail with this error:

$ /opt/synopsys/vcs/T-2022.06-SP1-1/linux64/bin/vcs1 -h
/opt/synopsys/vcs/T-2022.06-SP1-1/linux64/bin/vcs1:
/lib/x86_64-linux-gnu/libpthread.so.0: version `GLIBC_PRIVATE' not found
(required by /opt/synopsys/vcs/T-2022.06-SP1-1/linux64/bin/vcs1)


It turns out that the Synopsys binaries have a weak symbol for
__pthread_unwind@GLIBC_PRIVATE. Synopsys support is slow and so for the time
being we've helped ourselves by patching glibc to provide the GLIBC_PRIVATE
version again for libpthread.so (see attached patch).


[1]
https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=e8d52b64a54ba9ed7778ca9ce1f084eb5808f8d1
[2] https://www.synopsys.com/

-- 
You are receiving this mail because:
You are on the CC list for the bug.

^ permalink raw reply	[flat|nested] 5+ messages in thread

* [Bug nptl/29834] libpthread.so lacks GLIBC_PRIVATE version for glibc 2.34 and later
  2022-11-29 11:53 [Bug nptl/29834] New: libpthread.so lacks GLIBC_PRIVATE version for glibc 2.34 and later misch at google dot com
@ 2022-11-29 12:11 ` misch at google dot com
  2022-11-29 20:12 ` fweimer at redhat dot com
                   ` (2 subsequent siblings)
  3 siblings, 0 replies; 5+ messages in thread
From: misch at google dot com @ 2022-11-29 12:11 UTC (permalink / raw)
  To: glibc-bugs

https://sourceware.org/bugzilla/show_bug.cgi?id=29834

--- Comment #1 from Michael Schaller <misch at google dot com> ---
I would also appreciate it if we could avoid the discussion about the general
use of closed source software. It appears certain closed source software can't
be avoided in certain fields, like Synopsys VCS [3].

[3] https://www.synopsys.com/verification/simulation/vcs.html

-- 
You are receiving this mail because:
You are on the CC list for the bug.

^ permalink raw reply	[flat|nested] 5+ messages in thread

* [Bug nptl/29834] libpthread.so lacks GLIBC_PRIVATE version for glibc 2.34 and later
  2022-11-29 11:53 [Bug nptl/29834] New: libpthread.so lacks GLIBC_PRIVATE version for glibc 2.34 and later misch at google dot com
  2022-11-29 12:11 ` [Bug nptl/29834] " misch at google dot com
@ 2022-11-29 20:12 ` fweimer at redhat dot com
  2022-11-30 12:13 ` misch at google dot com
  2022-12-23  9:55 ` misch at google dot com
  3 siblings, 0 replies; 5+ messages in thread
From: fweimer at redhat dot com @ 2022-11-29 20:12 UTC (permalink / raw)
  To: glibc-bugs

https://sourceware.org/bugzilla/show_bug.cgi?id=29834

Florian Weimer <fweimer at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |fweimer at redhat dot com

--- Comment #2 from Florian Weimer <fweimer at redhat dot com> ---
Thanks for filing this bug publicly.

Do I understand this correctly? The program does not actually need a definition
of the weak symbol? And we just run into a limitation in the GNU symbol
versioning scheme, where we do not have weak symbol versions at all
(VER_FLG_WEAK is generally understood to mean something else)?

Would it be sufficient if we make this work again by setting an environment
variable?

-- 
You are receiving this mail because:
You are on the CC list for the bug.

^ permalink raw reply	[flat|nested] 5+ messages in thread

* [Bug nptl/29834] libpthread.so lacks GLIBC_PRIVATE version for glibc 2.34 and later
  2022-11-29 11:53 [Bug nptl/29834] New: libpthread.so lacks GLIBC_PRIVATE version for glibc 2.34 and later misch at google dot com
  2022-11-29 12:11 ` [Bug nptl/29834] " misch at google dot com
  2022-11-29 20:12 ` fweimer at redhat dot com
@ 2022-11-30 12:13 ` misch at google dot com
  2022-12-23  9:55 ` misch at google dot com
  3 siblings, 0 replies; 5+ messages in thread
From: misch at google dot com @ 2022-11-30 12:13 UTC (permalink / raw)
  To: glibc-bugs

https://sourceware.org/bugzilla/show_bug.cgi?id=29834

--- Comment #3 from Michael Schaller <misch at google dot com> ---
> Do I understand this correctly? The program does not actually need a definition of the weak symbol?

That is indeed the case. The attached patch just restores the GLIBC_PRIVATE
version for libpthread.so and that was sufficient to get the Synopsys binaries
working again.

> And we just run into a limitation in the GNU symbol versioning scheme, where we do not have weak symbol versions at all (VER_FLG_WEAK is generally understood to mean something else)?

I'm not sure I can answer that. My understanding of symbol versioning and weak
symbols is rudimentary and it took me a while to understand that "version
`GLIBC_PRIVATE' not found" literally means that the version was removed.

> Would it be sufficient if we make this work again by setting an environment variable?

I guess yes. Wouldn't it be easier though to just restore the GLIBC_PRIVATE
version as we did with the attached patch? Alternatively maybe the dynamic
loader could be changed to ignore a missing version for a weak symbol.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

^ permalink raw reply	[flat|nested] 5+ messages in thread

* [Bug nptl/29834] libpthread.so lacks GLIBC_PRIVATE version for glibc 2.34 and later
  2022-11-29 11:53 [Bug nptl/29834] New: libpthread.so lacks GLIBC_PRIVATE version for glibc 2.34 and later misch at google dot com
                   ` (2 preceding siblings ...)
  2022-11-30 12:13 ` misch at google dot com
@ 2022-12-23  9:55 ` misch at google dot com
  3 siblings, 0 replies; 5+ messages in thread
From: misch at google dot com @ 2022-12-23  9:55 UTC (permalink / raw)
  To: glibc-bugs

https://sourceware.org/bugzilla/show_bug.cgi?id=29834

--- Comment #4 from Michael Schaller <misch at google dot com> ---
@Florian Weimer
What are your thoughts on my previous reply?

-- 
You are receiving this mail because:
You are on the CC list for the bug.

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2022-12-23  9:55 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-11-29 11:53 [Bug nptl/29834] New: libpthread.so lacks GLIBC_PRIVATE version for glibc 2.34 and later misch at google dot com
2022-11-29 12:11 ` [Bug nptl/29834] " misch at google dot com
2022-11-29 20:12 ` fweimer at redhat dot com
2022-11-30 12:13 ` misch at google dot com
2022-12-23  9:55 ` misch at google dot com

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).