|
From: Nicholas N. <n.n...@gm...> - 2009-02-06 03:44:50
|
Hi,
I have a proposal for simplifying the build system, particularly
installation of files.
Currently things get installed in two ways:
- "in-place": the .in_place directory is always made with "make", it
contains symlinks back to various files in tool dirs.
- "install": it contains copies of files.
The files that are built in the tree have names like:
memcheck-x86-linux, libcoregrind_x86_darwin.a,
vgpreload_memcheck-x86-darwin.so, libmpiwrap-X86_LINUX.so. But when
installed into either .in_place or the installation directory, they
get renamed to x86-linux/{memcheck,libcoregrind.a,vgpreload_memcheck.so,libmpiwrap.so}.
This requires various pieces of appalling sed hackery at install-time.
But I don't see any good reasons for it. I also don't see any good
reason for the inconsistency in the original names, eg. '-' vs '_',
caps vs. non-caps.
I have a patch which gets rid of the platform-specific directory in
the installation dir, and just keeps the platform-specific suffixes on
the various files. The launcher requires minor changes to find
things, but it's not difficult. It cuts out various horrendous parts
of Makefile.am files, some of which are the worst lines in the entire
build system.
It also avoids a big problem on Darwin, which has to do with my old
friends, the .dSYM directories. I need to generate and install
vgpreload_memcheck-x86-darwin.so.dSYM alongside
vgpreload_memcheck-x86-darwin.so. The problem is that the .dSYM
directory has a file within it,
vgpreload_memcheck-x86-darwin.so.dSYM/Contents/Resources/DWARF/vgpreload_memcheck-x86-darwin.so.
(In case you're wondering, the two .so files aren't the same -- the
top-level one lacks debug info, the one with .dSYM has it.) But if
the .dSYM dir gets renamed during installation to match the renamed
.so, the internal .so name no longer matches and Valgrind's dSYM debug
info reader gets confused. My patch above which avoids the renaming
fixes this problem. I'd rather not use sed to rename the internal
.so.
There's a possible problems with these installed files: libvex.a,
libvex_coregrind.a, libmpiwrap.so. I think the first two are there in
case you want to distribute your own tool without also distributing
Valgrind. (But we don't include libreplacemalloc_toolpreload.a, so
it's incomplete; I've added that in the patch.) But it wouldn't be
hard to an external tool to adjust to this change, and AFAIK there
aren't any being distributed. (We should probably also change the
library names from e.g. libvex_x86_linux.a to libvex-x86-linux.a.)
Changing x86-linux/libmpiwrap.so to libmpiwrap-x86-linux.so shouldn't
cause many problems, since it's designed to be manually included in a
program by a user. Some people might have scripts that need trivial
updates.
External Valgrind-invoking programs like Valkyrie shouldn't need to be
changed -- they will be calling $INSTALL/bin/valgrind, which hasn't
moved.
Thoughts?
Nick
|
|
From: Greg P. <gp...@ap...> - 2009-02-06 05:00:11
|
On Feb 5, 2009, at 7:44 PM, Nicholas Nethercote wrote: > It also avoids a big problem on Darwin, which has to do with my old > friends, the .dSYM directories. I need to generate and install > vgpreload_memcheck-x86-darwin.so.dSYM alongside > vgpreload_memcheck-x86-darwin.so. The problem is that the .dSYM > directory has a file within it, > vgpreload_memcheck-x86-darwin.so.dSYM/Contents/Resources/DWARF/ > vgpreload_memcheck-x86-darwin.so. > (In case you're wondering, the two .so files aren't the same -- the > top-level one lacks debug info, the one with .dSYM has it.) But if > the .dSYM dir gets renamed during installation to match the renamed > .so, the internal .so name no longer matches and Valgrind's dSYM debug > info reader gets confused. My patch above which avoids the renaming > fixes this problem. We might need to make Valgrind's dSYM locator more robust in the face of renames anyway. I'm not sure what the expected behavior of other tools is when a dSYM directory is renamed. One other way valgrind's dSYM locator can be improved. Built executables include a UUID that is also recorded in the dSYM, and Spotlight indexes dSYMs by that UUID. So Valgrind can use the Spotlight command-line tools to search for a dSYM that matches the executable's UUID. This means the dSYM can be anywhere indexed by Spotlight, not just next to the executable where Valgrind currently looks. % dwarfdump -u --arch=x86_64 /usr/lib/libSystem.B.dylib UUID: 4EA82519-85FD-0407-2381-BEB16342275B (x86_64) % mdfind "com_apple_xcode_dsym_uuids='4EA82519-85FD-0407-2381- BEB16342275B'" /Volumes/precious/cvs/Libc/libSystem.B.dylib.dSYM -- Greg Parker gp...@ap... Runtime Wrangler |
|
From: Nicholas N. <n.n...@gm...> - 2009-02-06 05:12:50
|
On Fri, Feb 6, 2009 at 3:59 PM, Greg Parker <gp...@ap...> wrote: > > We might need to make Valgrind's dSYM locator more robust in the face of > renames anyway. I'm not sure what the expected behavior of other tools is > when a dSYM directory is renamed. Ok. Even if we do that, I still think avoiding the awful renaming within Valgrind would be a win. N |
|
From: Tom H. <to...@co...> - 2009-02-06 08:32:50
|
Nicholas Nethercote wrote:
> The files that are built in the tree have names like:
> memcheck-x86-linux, libcoregrind_x86_darwin.a,
> vgpreload_memcheck-x86-darwin.so, libmpiwrap-X86_LINUX.so. But when
> installed into either .in_place or the installation directory, they
> get renamed to x86-linux/{memcheck,libcoregrind.a,vgpreload_memcheck.so,libmpiwrap.so}.
>
> This requires various pieces of appalling sed hackery at install-time.
> But I don't see any good reasons for it. I also don't see any good
> reason for the inconsistency in the original names, eg. '-' vs '_',
> caps vs. non-caps.
I suspect it's partly historical in that we decided to put each backend
in a separate directory then found that automake really wanted to
generate everything in one directory so we resorted to hackery to get
the installation to adjust things.
> I have a patch which gets rid of the platform-specific directory in
> the installation dir, and just keeps the platform-specific suffixes on
> the various files. The launcher requires minor changes to find
> things, but it's not difficult. It cuts out various horrendous parts
> of Makefile.am files, some of which are the worst lines in the entire
> build system.
Sounds reasonable to me.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|