NPTL auto detection

[Mike Hearn]

Hi Alexandre,

You said a few months ago Wine would soon detect whether to enable NPTL
support at runtime rather than compile time. Presumably this will get in
as part of the CodeWeavers merge. Do you know how long that might be? It
seems every day people hit this problem and don't realise how to work
around it.

thanks -mike

[Alexandre Julliard]

Mike Hearn  writes:
> You said a few months ago Wine would soon detect whether to enable NPTL
> support at runtime rather than compile time. Presumably this will get in
> as part of the CodeWeavers merge. Do you know how long that might be? It
> seems every day people hit this problem and don't realise how to work
> around it.

I'm working on it; the way we do it in Crossover is not really
applicable to Wine (plus it's frankly ugly), but I'm working on the
proper solution. It's still going to take some time.

[Mike Hearn]

> I'm working on it; the way we do it in Crossover is not really
> applicable to Wine (plus it's frankly ugly), but I'm working on the
> proper solution. It's still going to take some time.

Hmm, let me guess, you have two binaries and a shell script to figure out
which one to run?

[Alexandre Julliard]

Mike Hearn  writes:
> Hmm, let me guess, you have two binaries and a shell script to figure out
> which one to run?

That's the idea yes; actually it's two sets of libraries and a script
that tweaks LD_LIBRARY_PATH etc.

[Sylvain Petreolle]

If I remember correct, there were reports from people complaining about
wine not running with LD_LIBRARY_PATH set, and --with-nptl fixed the
problem.

It wont work for all people that way.
> > Hmm, let me guess, you have two binaries and a shell script to
>
> figure out
> > which one to run?
>
> That's the idea yes; actually it's two sets of libraries and a script
> that tweaks LD_LIBRARY_PATH etc.

=====
Sylvain Petreolle (spetreolle at users dot sourceforge dot net) ICQ #170597259
No more War !

"What if tomorrow the War could be over ?" Morpheus, in "Reloaded".

For the Law of Oil and Fire, Im an European that lives in France.
For all my Brothers and friends, Im a human living on Earth.

___________________________________________________________
Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français !
Yahoo! Mail : http://fr.mail.yahoo.com

[erwin wolff]

The solution of this NPTL problem is somehow solved by the guys of
apache. since 2.0.44 the configure script can autodetect nptl. So if you
want to implement this feature you can "borrow" it from apache.

-------------------------------
Erwin Wolff
[e-mail]

[Vincent Béron]

erwin wolff a écrit:
> The solution of this NPTL problem is somehow solved by the guys of
> apache. since 2.0.44 the configure script can autodetect nptl. So if you
> want to implement this feature you can "borrow" it from apache.

Alexandre's goal is not only to detect it at compile-time (I'd think 
that it could be somewhat easy to do that). The trickiest part is to 
have a binary that can run with or without NPTL, with or without 
LD_KERNEL_ASSUME, etc.

Vincent

[Mike Hearn]

Oh, sorry, should have thought of this before. If it were possible to
reliably detect NPTL breakage in the configure script, would you accept
a patch to add this temporarily? Some of the people hitting this problem
have very little technical knowledge, editing wineinstall , make
distclean etc is a bit beyond them, especially if they don't know where
to get help in the first place.

If so, I don't suppose you know of any handy ways to detect it that we
can put in a configure check?

thanks -mike

On Fri, 2003-05-09 at 17:59, Alexandre Julliard wrote:
> Mike Hearn  writes:
> > You said a few months ago Wine would soon detect whether to enable NPTL
> > support at runtime rather than compile time. Presumably this will get in
> > as part of the CodeWeavers merge. Do you know how long that might be? It
> > seems every day people hit this problem and don't realise how to work
> > around it.
>
> I'm working on it; the way we do it in Crossover is not really
> applicable to Wine (plus it's frankly ugly), but I'm working on the
> proper solution. It's still going to take some time.

[Alexandre Julliard]

Mike Hearn  writes:
> Oh, sorry, should have thought of this before. If it were possible to
> reliably detect NPTL breakage in the configure script, would you accept
> a patch to add this temporarily? Some of the people hitting this problem
> have very little technical knowledge, editing wineinstall , make
> distclean etc is a bit beyond them, especially if they don't know where
> to get help in the first place.

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
it. So I'm not convinced it's really more reliable. The real problem
IMO is that we don't have NPTL rpm packages.

[Mike Hearn]

> 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
> it.

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
check/fix.
> 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

[Dimitrie O. Paun]

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.

The problem is that many people build from source, and ./configure
doesn't do the expected thing: detect the requirements for the current
system.

[Vincent Béron]

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
> system.

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.

Vincent

[Dimitrie O. Paun]

On May 9, 2003 04:18 pm, Vincent Béron wrote:
> 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.

I would feel a lot more confortable about those packages if you give
them your blessing, since you are our RedHat packager. If you do,
they should be named consistently with the other packages, and uploaded
to SF, so we don't have to point people in other directions.

[Vincent Béron]

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
> > it.
>
> 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
> check/fix.

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.

Vincent

[Dimitrie O. Paun]

On 9 May 2003, Mike Hearn wrote:
> If so, I don't suppose you know of any handy ways to detect it that we
> can put in a configure check?

If it is temporary, what about a simple glibc version check?