> 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. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
