glibc - it doesn't matter for valgrind as we only have one version and
by not versioning them we work no matter what version is asked for.
CCMAIL: 86289-done@bugs.kde.org
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2605
library - it seems that I misunderstood hom the versioning works and
a system looking for a GLIBC_PRIVATE version of the clock routines
would not find the GLIB_2.2.3 one even with the inheritance. It only
seemed to be working on glibc 2.3 systems because of the version
overrides in the source code, but it failed on glibc 2.2.5 systems.
The new approach is to explicity create two versions of the routines
in question, one with a version of GLIBC_2.2.3 and one with a version
of GLIBC_PRIVATE instead. This has been tested on six different systems
and appears to work everywhere.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2586
the GLIBC_2.2.3 section which is where they were in glibc before
they were moved to GLIBC_PRIVATE around the 2.2.5 time frame.
This makes older systems work correctly as librt will be looking
for the symbols with that version. In order to make newer systems
work we make GLIBC_PRIVATE a child of the most recent version in
the file (currently GLIBC_2.3.3) so that a librt which is looking
for the symbols with a version of GLIBC_PRIVATE will find them.
The real glibc pthread libraries have GLIBC_PRIVATE as a child of
the most recent version anyway, so this shouldn't cause any problems
and with this change librt seems to be OK both on old RedHat 7.1 systems
with glibc 2.2.3 and on Fedora Core 2 systems with glibc 2.3.3.
Hopefully this will fix FAQ 3.4 but I haven't removed that just yet.
CCMAIL: 86696-done@bugs.kde.org
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2581
Valgrind's dependency on the dynamic linker for getting started, and
instead takes things into its own hands.
This checkin doesn't add much in the way of new functionality, but it
is the basis for all future work on Valgrind. It allows us much more
flexibility in implementation, and well as increasing the reliability
of Valgrind by protecting it more from its clients.
This patch requires some changes to tools to update them to the changes
in the tool API, but they are straightforward. See the posting "Heads
up: Full Virtualization" on valgrind-developers for a more complete
description of this change and its effects on you.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2118
