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

[Matthew LeGendre <legendre1@xxxxxxxx>]

On Fri, 7 Mar 2014, Josh Stone wrote:
> On 03/07/2014 07:48 AM, Jim Galarowicz wrote:
> > 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.
Josh is correct.  The RT library was split into a seperate CMake project 
as part of BlueGene/Q support.  We manually invoke that project from the 
top-level CMake with what we think are the necessary options.
Except we're not passing some of the options you're using, such as the 
explicit LIB and INCLUDE install locations.  I should just have to add 
those to the list of options passed to the RT library.
> 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.
That would work.

But the fix should just involve modifying a single line (knock on wood). 
How about I'll send you a patch, and if that works it can get pushed to 
master.
-Matt