|
From: Dag W. <da...@wi...> - 2003-05-02 04:41:18
|
On Sun, 27 Apr 2003, Julian Seward wrote:
> > I also included a small C program that would check if NPTL threading =
was
> > supported (at runtime). But I superseded that with using getconf dire=
ctly.
> > (This works on all distributions and is much cleaner.)
> >
> > Using getconf was advised on a mailinglist somewhere (I can't remembe=
r
> > where exactly I read that.) However I have the source of the small C
> > program still in my SPEC file for educational purposes.)
> >
> > It would be nice though if valgrind could check for itself if NPTL
> > threading is supported at loadtime ? Or at least take over my changes=
to
> > coregrind/valgrind.in so that it is check in runtime (instead of chec=
king
> > at compile-time)
>=20
> I'm trying to put together 1.9.6, which fixes some glibc-2.3.2+=20
> threading problems and so will be the first V which is properly usable
> for R H 9 and SuSE 8.2.
>=20
> It would be helpful therefore if you could send me the _minimal_ diffs
> against the VALGRIND_2_0_BRANCH in cvs at sourceforge (this is the 1.9.=
X
> stable branch) which allow you to build RPMs as you want.
> > perl -pi.orig -e 's|^nptl_threading=3D.*$|nptl_threading=3D"$(if getc=
onf
> > GNU_LIBPTHREAD_VERSION &>/dev/null; then echo "yes"; else echo "no"; =
fi)"|'
> > coregrind/valgrind.in
If you're going to adopt the change to the valgrind shellscript:
Can't you just do this on a checkout and then commit ? Or just=20
edit that one line by hand ? Doing a checkout seems so much work=20
for so little change.
You have to replace the nptl_threading=3D line with:
nptl_threading=3D"$(if getconf GNU_LIBPTHREAD_VERSION &>/dev/null; then =
echo "yes"; else echo "no"; fi)"
If you're talking about the NPTL checking on loadtime:
I am not a developer so I'm not sure where to commit the change.=20
What's more it expects a define to be able to compile and I have=20
no clue to make that compile on systems that don't have that=20
getconf define (older glibcs).
This is the code I used before I called getconf directly from the=20
script. _CS_GNU_LIBPTHREAD_VERSION does not exist on older glibc !
//#define _XOPEN_SOURCE
#define _POSIX_C_SOURCE 2
#include <unistd.h>
#include <stdio.h>
int main(void) {
char *buf; size_t n;
n=3Dconfstr(_CS_GNU_LIBPTHREAD_VERSION, NULL, (size_t) 0);
if ((buf =3D (char *) malloc(n)) =3D=3D NULL) abort();
confstr(_CS_GNU_LIBPTHREAD_VERSION, buf, n);
fprintf(stdout, "%s\n", buf); exit(0);
}
And if you're talking about the SPEC-file changes, I'm not sure what you=20
want to adopt from it and what not. You can find it at:
http://dag.wieers.com/packages/valgrind/valgrind.spec
> > PS These packages still have a problem with some private GLIBC symbol=
s
> > that are in the dependencies of the package. I can't seem to fix this=
by
> > doing:
> >
> > %define __find_provides() /usr/lib/rpm/find-provides %* | grep -v
> > '^libpthread.so' %define __find_requires() /usr/lib/rpm/find-requires=
%* |
> > grep -v 'libc.so.6(GLIBC_PRIVATE)'
> >
> > So unless I find a clean way of doing this, you might have to install=
with
> > --nodeps on some RH's (RH80 and RH73 afaik).
I still have to get this to work. Someone gave me a solution, but I didn'=
t=20
like it though, it should work from the spec-file directly IMO. Need to=20
check this on the rpm-list.
Kind regards,
-- dag wieers, da...@wi..., http://dag.wieers.com/ --
=ABAny errors in spelling, tact or fact are transmission errors=BB
|