[Valgrind-users] Re: Valgrind RH RPM packages for RH62, RH72, RH80 and RH9

[Dag W. <da...@wi...>]

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