Bugzilla will be upgraded to version 5.0 on December 2, 2018. The outage period for the upgrade will start at 0:00 UTC and have a duration of 12 hours
Bug 65777 - static and shared versions of libpthread built differently
static and shared versions of libpthread built differently
Product: Red Hat Linux
Classification: Retired
Component: libc (Show other bugs)
i686 Linux
medium Severity high
: ---
: ---
Assigned To: Jakub Jelinek
Depends On:
  Show dependency treegraph
Reported: 2002-05-31 12:59 EDT by Suresh Rao
Modified: 2008-05-01 11:38 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2002-12-15 15:44:18 EST
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 Suresh Rao 2002-05-31 12:59:25 EDT
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 5.0; Windows NT; DigExt)

Description of problem:
On IA32 RH 7.2, why is the static libpthread.a built with -UFLOATING_STACKS and 
the dynamic libpthread.so is built with -DFLOATING_STACKS? For consistency both 
should be built with -DFLOATING_STACKS. Because of this difference, we are 
seeing many issues from users regarding limited thread stack sizes. Can the 
default be to build them with -DFLOATING_STACKS for the distribution.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Standard 7.2 distribution

Additional info:
Comment 1 Jakub Jelinek 2002-05-31 14:54:15 EDT
This is done on purpose. FLOATING_STACKS require a quite recent kernel
(2.4.8 or above) and i686, so if libpthread.a was compiled that way, statically
linked programs against that wouldn't run or wouldn't run correctly on pre 2.4.8 kernels
or on pre-i686 machines. When libpthread is linked dynamically, such decision
is done on runtime (dynamic linker chooses either /lib/libpthread.so.0 or
/lib/i686/libpthread.so.0 based on actual kernel version, plus the fact whether
i686 or i386 glibc is installed ensures that dynamically linked programs against
-lpthread can run on pre-i686.
Having a libpthread.a which would at runtime choose whether it wants to use
FLOATING_STACKS or not would slow it down a lot, so I think it is out of the question.
What are the reasons why somebody wants to link -lpthread statically in BTW?
IMHO -Bstatic ... -Bdynamic -lpthread works just fine.

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