Re: [DynInst_API:] Dyninst 8.2(top of git) build issues

[Josh Stone <jistone@xxxxxxxxxx>]

On 03/07/2014 07:48 AM, Jim Galarowicz wrote:
> Hi Dyninst team,
> 
> When I tried to build the existing 8.1.2 version on Fedora 20 with
> gcc-4.8.2 I encountered some compile errors in proccontrol,

For dyninst-8.1.2, note that F20 does have packages already.  If you
still want to compile your own, you can use the same patch we have to
fix the ptrace conflict:

http://pkgs.fedoraproject.org/cgit/dyninst.git/plain/dyninst-pokeuser.patch

This fix has been included in dyninst.git master already.

> so I downloaded yesterdays Dyninst git tree snapshot and tried to
> build it using my spec file created to use the new cmake style
> build.

I had also experimented with a dyninst rpm in the new cmake build, and
had no issues, but this was a while ago.  See below...

> We (OSS team) have always set the libdir to lib64 on x86_64 machines and
> installed the dyninst includes into <install_dir>/include/dyninst.
> When I use this cmake command (on Fedora 20 using gcc-4.8.2), I get some
> files that don't follow that lib64 and <install_dir>/include/dyninst
> suggestions.
> 
>   cmake . -DCMAKE_INSTALL_PREFIX=$RPM_BUILD_ROOT%{prefix}
> -DINSTALL_LIB_DIR=$RPM_BUILD_ROOT%{prefix}/lib64
> -DINSTALL_INCLUDE_DIR=$RPM_BUILD_ROOT%{prefix}/include/dyninst
> -DCMAKE_PREFIX_PATH=$RPM_BUILD_ROOT%{prefix}
> -DCMAKE_BUILD_TYPE=RelWithDebInfo
> -DLIBDWARF_LIBRARIES=$LIBDWARFDIR/%{libdir}
> -DLIBDWARF_INCLUDE_DIR=$LIBDWARFDIR/include
> -DLIBELF_LIBRARIES=$LIBELFDIR/%{libdir} -DLIBELF_INCLUDE_DIR=$LIBELFINC
> -DPATH_BOOST=$DYNINST_BOOST_ROOT -DLIBIBERTY_LIBRARY=$LIBIBERTYLIBDIR
> -DIBERTY_LIBRARY=$LIBIBERTYLIBDIR
> 
> These files are flagged by rpm as installed but not packaged because we
> are expecting them to be in the specified directory paths.
> Can you see/tell if I am doing something wrong in the cmake command, or
> is this a dyninst build/configure issue?
> 
>    /opt/krellroot/include/dyninstAPI_RT.h
>    /opt/krellroot/include/dyninstRTExport.h
>    /opt/krellroot/lib/libdyninstAPI_RT.a
>    /opt/krellroot/lib/libdyninstAPI_RT.so
>    /opt/krellroot/lib/libdyninstAPI_RT.so.8.2
>    /opt/krellroot/lib/libdyninstAPI_RT.so.8.2.0

Since these are exactly just the RT files, this reminded me that Matt
split dyninstAPI_RT into a cmake subproject a few months ago, in commit
fef984b105cc.  I guess it is not passing all of the -D options through,
and we should fix this.

Alternatively, at least as a stopgap, you can probably invoke cmake
manually on dyninstAPI_RT/ with all your options, to overwrite the
nested invocation from the top level.


Josh