Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.
Bug 102098 - libc.so contains pthread_* symbols, libc.a does not
libc.so contains pthread_* symbols, libc.a does not
Product: Red Hat Linux
Classification: Retired
Component: XFree86 (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Mike A. Harris
David Lawrence
: MoveUpstream
Depends On:
  Show dependency treegraph
Reported: 2003-08-11 08:44 EDT by Jan "Yenya" Kasprzak
Modified: 2007-04-18 12:56 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2003-08-24 04:49:25 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Jan "Yenya" Kasprzak 2003-08-11 08:44:43 EDT
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):

How reproducible:

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
/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?
Comment 1 Jakub Jelinek 2003-08-11 09:49:42 EDT
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))
Comment 2 Jan "Yenya" Kasprzak 2003-08-13 04:21:12 EDT
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).
Comment 3 Mike A. Harris 2003-08-13 04:37:37 EDT
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.
Comment 4 Mike A. Harris 2003-08-24 04:49:25 EDT
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.
Comment 5 Jan "Yenya" Kasprzak 2003-08-25 04:57:21 EDT
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}.
Comment 6 Ulrich Drepper 2003-08-25 05:11:01 EDT
The distribuion of symbols is ok, regardless of what you think.  Code which uses
the static libraries better know what they do.
Comment 7 Mike A. Harris 2003-08-26 09:37:39 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.