NPTL auto detection
vberon at mecano.gme.usherb.ca
Fri May 9 15:13:15 CDT 2003
Mike Hearn a écrit:
>>Well, you can detect the lib in use at compile time but that isn't
>>necessarily what will be used at run time, things like changing the
>>kernel or even simply setting LD_ASSUME_KERNEL differently will break
> This is true. Unfortunately, with the current state of Linux packaging
> today, the assumption is that if you don't have a package available for
> your exact distro and version, you need to compile from source. So, for
> users without an RPM available, they will compile it and get this
Problem is, this assumption is often true. The LSB is supposed to help
with the file location part, but functionnality-wise, the glibc-2.3.1
shipped with RH8 doesn't use NPTL, while the version (IIRC) shipped in
Debian unstable did a few months ago. So if your package (RPM, deb, tgz,
anything via alien) is compiled to use it, it can be unusable on some of
the other distros, even when installed packages versions are the same
(because of different configuration choices by distros).
>>So I'm not convinced it's really more reliable. The real problem
>>IMO is that we don't have NPTL rpm packages.
> 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
What would be better is to have them moved to Sourceforge, alongside the
other ones. Some small things would need to be improved though
(documentation is not built, for example).
I should have a working RH9 setup early next week (if time permit), so I
may tackle it.
More information about the wine-devel