[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: LSB 3.0 and who's doing what?

> At the time I was told that the way threads were being specified in the LSB 
> spec would allow for either the existing implementation or the new NPTL 
> implementation. If that's not the case then something is wrong. Are there 
> tests failing? If so then maybe there's a TSD or INT issue.

Matt - the spec says POSIX threads, it says nothing about nptl
specifically. But it's known that linuxthreads don't implements pthreads
well enough to pass the tests, so we left pthreads out of the LSB
entirely until nptl implementations were mature enough that several
distros passed the testsuite. Debian froze on an upstream version of
glibc that still showed a few failures. Far less than a linuxthreads
implementation would, though.

> > that libstdc++6 from sarge doesn't seem to
> > implement lots of needed symbols,
> This will take some work but all distros are having to deal with it so we get 
> to leverage their work.

I missed this first time... that sounds surprising.  Any libstdc++6
built out of gcc 3.4.2 or later should have all the symbols - there's
nothing that was _added_ by LSB, in fact some symbols left _out_ of the
ABI on the advice of upstream  Posting results would help here - if
these are the vtable errors from lsblibchk that's a problem with the way
libchk is examining virtual tables and does not indicate a problem in
the implementation.

> > and that vsw4 basically bails half way
> > through the test because it kills our XFree86 4.3-based Xvfb.
> This test suite is still in development and also moving to Xorg should help.

The Xvfb has proven somewhat fragile, true.  In terms of library
support, some of the earlier xorg releases actually regressed a bit and
introduced errors that the last XFree versions didn't have, but the good
news is there seem to be lots of people running the tests and bugs get
filed on these very quickly at freedesktop.org.

Reply to: