This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: testing glibc


> LD_LIBRARY_PATH=/some/dir  program

That uses the installed dynamic linker, which means you're not testing what
you've built, even when running this way happens to work.

> sometimes when the program uses dlopen and crashes do
> LD_LIBRARY_PATH=/some/dir   /some/dir/lib/ld-linux-x86-64.so.2 program
> (or relink program)

I'd expect this to work.  (You can also write it:
	/.../ld.so --library-path /...
which won't change the environment the program sees.)

> ls: error while loading shared libraries: __vdso_gettimeofday: invalid
> mode for dlopen(): Invalid argument

You might try some settings like LD_DEBUG=libs (or just strace) to see what
it is loading and verify that it's not loading some shared libraries from
the installed system rather than from your testing install.

Have you tried using the testrun.sh script from the build directory?  That
approximates the way that 'make check' runs everything.  This uses stuff
directly out of the build directory, rather than from the 'make install'
locations.  But if that works better than what you're doing, it may give
some clues about what the problems are.

> When I run it with the new ld-linux.so it seems to be unable to read the
> system shared library path, so nothing works.

It will be looking at /some/dir/etc/ld.so.cache, so it won't find
everything the system-installed ldconfig put in /etc/ld.so.cache.
That shouldn't really matter, unless you're running a program that
uses other libraries in nonstandard locations and wasn't built with
a proper DT_RUNPATH.  You could try copying /etc/ld.so.cache to that
location.  Or you could try running /some/dir/sbin/ldconfig, though
you probably have to copy /etc/ld.so.conf (and ld.so.conf.d/* or anything
else your system's ld.so.conf uses via include).  You could also try
configuring libc with --prefix=/some/dir --sysconfdir=/etc--but then
you really want to make sure you don't use sudo to run 'make install'
(which you shouldn't need if you own /some/dir).

> What's the currently recommended way to test glibc without replacing the
> system libc?

Things along the lines of what you're doing should work, and we'd like to
figure out what the problems are if they don't.  But it's certainly fiddly,
and probably always will be.  The most reliable method will probably always
be to use a chroot.


Thanks,
Roland


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]