NPTL auto detection
vberon at mecano.gme.usherb.ca
Fri May 9 15:18:23 CDT 2003
Dimitrie O. Paun a écrit:
> On Fri, 9 May 2003, Mike Hearn wrote:
>>We do, over at newrpms.sunsite.dk iirc, the biggest problems being that I
>>think they depend on ALSA (not sure why) and that nobody knows about them
>>unless they visit IRC. Plus they are for Redhat only (but really it's
>>mostly redhat users with the problems).
>>Perhaps it'd be easier to simply place a prominant warning on the
>>winehq homepage with pointers to newrpms.sunsite.dk
> Please don't -- we have a place on SF where we have packages, let's
> not complicate things. In fact, our RedHat RPMs are NTPL read,
> this is what the release notes say:
> Notes: This release is compiled for a fully patched installation of
> Red Hat Linux 8.0, including (but not limited to) the
> glibc-2.3.2-4.80.6 errata package. It may or may not work with
> the original glibc package installed by Red Hat Linux 8.0.
No they're not. Trust me :)
As I just said, the different glibc-2.3.x packages shipped by RH for RH8
do not work with NPTL. ./configure is not called with --with-nptl in
my RPMs. The results on other distros (eg, RH9) are probably not too good.
What we need is effectively a set of RPMs for RH9 on SF.net. The RPMs on
newrpms.sunsite.dk are built with ./configure --with-nptl, so they would
probably qualify. They are derived from my packages, themselves derived
from the one RH shipped with RH8.
> The problem is that many people build from source, and ./configure
> doesn't do the expected thing: detect the requirements for the current
That's true. The same thing could be said regarding OpenGL versions,
depending on the supplier of the driver and include files on both the
compilation machine and where it is run.
More information about the wine-devel