Bug 102098
| Summary: | libc.so contains pthread_* symbols, libc.a does not | ||
|---|---|---|---|
| Product: | [Retired] Red Hat Linux | Reporter: | Jan "Yenya" Kasprzak <kas> |
| Component: | XFree86 | Assignee: | Mike A. Harris <mharris> |
| Status: | CLOSED WONTFIX | QA Contact: | David Lawrence <dkl> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 9 | CC: | drepper, mharris, mitr, roland |
| Target Milestone: | --- | Keywords: | MoveUpstream |
| Target Release: | --- | ||
| Hardware: | i386 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2003-08-24 08:49:25 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
IMHO this is a bug in XFree86.
If not linking against -lpthread, it cannot assume those functions exist.
Instead, it should use
#pragma weak pthread_equal
if (pthread_equal == NULL || pthread_equal (thr1, thr2))
{
do_something_if_thr1_and_thr2_are_the_same_thread
}
I still don't think it's (only) a XFree86 (libX11) bug. I think libc.so providing different set of symbols than libc.a is plain wrong. I would understand libc.a exporting _bigger_ set of symbols (not all objects of the ar archive must be linked in, while the .so file is mapped as a whole). Please report in upstream XFree86 bugzilla located at http://bugs.xfree86.org and include the upstream bug URL here for tracking purposes once filed. I will monitor the upstream report, and possibly backport any safe fixes that are checked into CVS as long as there is no risk of regression. This bug will have to be reported in upstream XFree86 bugzilla, and have XFree86.org developers comment on the issue and resolve it in XFree86 CVS before Red Hat will make any changes to XFree86 for this issue. The risks of making local modifications are too high, and the problem has been reported only by a single person in all the years we've shipped XFree86, so I can't consider it of mission critical importance. I'm closing this as "WONTFIX" in Red Hat bugzilla for the time being, as I require upstream acceptance that the problem is real, and approval of any changes that are needed to fix it. If you do report it upstream, please update this bug report with the URL to the upstream bug report, and reopen the report if you would like it tracked by Red Hat. If upstream agrees that this is a real bug, and that they need to fix it, I will monitor their fixes, and consider them for possible inclusion in future Red Hat builds. I will not report it to XFree86, as I think it is not XFree86 bug, but a bug
in Red Hat's build of glibc. Is there any reason for libc.a containing different
set of symbols than libc.so? I think pthread_* symbols should be either included
both in libc.a and libc.so, or to be separated into libpthread.{a,so}.
The distribuion of symbols is ok, regardless of what you think. Code which uses the static libraries better know what they do. C'est la vie I guess. Ulrich is the official upstream GNU glibc maintainer, and we now know what his authoritative opinion is about it being a glibc bug. Jakub's suggested fix of using a compiler specific pragma might work for Linux, but it will not be accepted likely in XFree86 IMHO. They'll want a portable solution that works on the array of OS's that they care about, and so they are the best people to implement such changes in a portable manner if they are aware of the problem and consider it worth fixing. I will not make any Red Hat specific changes of this nature to our XFree86 for a problem that is not Red Hat specific. If you feel strongly about this problem, and don't report it upstream, then it is unlikely to be fixed in future XFree86 releases either if it is a real bug. |
Description of problem: libc.a does not contain pthread_* symbols, while libc.so does. This can be fixed using -lpthread on the command line of the linking command for the static linker, but it complicates any automake/autoconf-based setup, which should then guess what libraries are needed, instead of using something like "gtk-config --libs". The program does not use threads itself. Version-Release number of selected component (if applicable): glibc-2.3.2-27.9.i686.rpm How reproducible: 100% Steps to Reproduce: 1. echo "main(){gtk_init();}" >test.c 2. cc -o ./test test.c `gtk-config --libs` 3. cc -o ./test-static test.c -static `gtk-config --libs` Actual results: Only ./test is created, linking of ./test-static fails with the following message: /usr/X11R6/lib/libX11.a(XlibInt.o)(.text+0x85a): In function `_XEventsQueued': : undefined reference to `pthread_equal' Expected results: Both ./test and ./test-static should be built with the same command, just with -static added for the ./test-static. Additional info: Both libX11.so.6.2 and libX11.a contain the reference to the pthread_equal symbol, so this is not GTK-related or libX11-related problem. Is this a bug in the glibc{,-devel} package? If it isn't, then what _clean_ autoconf/automake solution do you suggest for linking GTK+ applications both statically and dynamically?