Actually, i just realised that the example i gave won't work because the new build system also solved the long-standing issue of rpathing not working correctly. Without a relink step during install, all rpaths are invalidated when using a staged install. Getting this to work would require upgrading the cmake system to use target-specific linking properties. It could be done, and is on my list of things to do (eventually), but the current incarnation avoids the issue by installing dependencies before 'make install' is run for Dyninst.
Thanks. - Tim On Tue, Jul 16, 2019, 5:43 PM Tim Haines <thaines.as...@gmail.com> wrote: > Hi, Stan. > > >Older versions of linux do not have a recent enough tbb or boost to build > dyninst. > > This is also true for elfutils and libiberty (via binutils). > > >One is that dependencies are needed otherwise what I see is something > like 'make -j20' will cause dyninst build errors because pieces are not > available. > > That's interesting, I've not seen this with parallel builds since 10.1. We > enforce the build order by making libcommon > <https://github.com/dyninst/dyninst/blob/540b22834e115a74e335e0359beb3b68208adad5/CMakeLists.txt#L220> > and DyninstRT > <https://github.com/dyninst/dyninst/blob/540b22834e115a74e335e0359beb3b68208adad5/CMakeLists.txt#L128> > dependent on boost. If something isn't dependent upon one of those two, > then it could fail. Could you send me the error message you saw? > > >Another is the tbb and boost builds are installed into the ultimate > install location. > > This is to ensure that Dyninst is a self-contained distribution and that > the Testsuite builds using the exact libraries that Dyninst was built > against (previously, this was not the case). There are consequences to > doing it this way (see the notes in the Wiki > <https://github.com/dyninst/dyninst/wiki/Building-Dyninst>), but elfutils > has been installed this way since it was able to build through > ExternalProject_Add. Before 10.1, the install was done _after_ Dyninst was > built (when doing 'make install' for Dyninst) such that you had to do a lot > of internal juggling of directories to maintain the correct include > locations. The latest build system removes this juggling by installing > _before_ Dyninst is completely built, instead. > > > So what happens with our system builds is it wants to install to the > system library directory, e.g. /usr/lib64/dyninst. I patched that so tbb > and boost do an intermediate install to tbb/install and boost/install, > dyninst builds from that, and CMakeLists.txt installs those. > > It's assumed that you will have access to CMAKE_INSTALL_PREFIX at any > point during the build process. If this is not the case, then you can > build/install Dyninst to a temporary location and then copy it out from > there. For example, > > cmake -DCMAKE_INSTALL_PREFIX=/path/to/temp/dyninst ... > make > make install > sudo cp -R /path/to/temp/dyninst /usr/lib64/ > > > I patched that so tbb and boost do an intermediate install to > tbb/install and boost/install, dyninst builds from that, and CMakeLists.txt > installs those. It works but it the CMakeLists.txt bit is really ugly > > Indeed. That's exactly why I chose to simplify the build system so that it > would be somewhat maintainable. The only added constraint is that > CMAKE_INSTALL_PREFIX is assumed to always be available. This is generally a > valid assumption in CMake, but can be tricky when it's a system directory > (as in your case) but that's true of anything built from source using > CMake. "sudo make install" really only works when no external libraries > have been built for you. The general solution is to use something like > Spack (or easybuild)- which Dyninst does support. > > Thanks. > > - Tim > > > > On Tue, Jul 16, 2019 at 4:46 PM Stan Cox <s...@redhat.com> wrote: > >> Older versions of linux do not have a recent enough tbb or boost to >> build dyninst. The ExternalProject_Add support is nice for those; I >> notice a couple of things. One is that dependencies are needed >> otherwise what I see is something like 'make -j20' will cause dyninst >> build errors because pieces are not available. I'm just using -j1 for >> now; but oh my goodness that increases the build time. Another is the >> tbb and boost builds are installed into the ultimate install location. >> So what happens with our system builds is it wants to install to the >> system library directory, e.g. /usr/lib64/dyninst. I patched that so >> tbb and boost do an intermediate install to tbb/install and >> boost/install, dyninst builds from that, and CMakeLists.txt installs >> those. It works but it the CMakeLists.txt bit is really ugly: >> >> +# Copy TBB and BOOST libraries from temp install dir to dyninst install >> dir >> +# Note: make has not yet run so we need to explicitly set the list >> +set(TBB_AND_BOOST_LIBS tbb/install/lib/libtbbmalloc_proxy.so >> tbb/install/lib/libtbbmalloc_proxy.so.2 tbb/install/lib/libtbbmalloc.s >> o tbb/install/lib/libtbbmalloc.so.2 tbb/install/lib/libtbb.so >> tbb/install/lib/libtbb.so.2 boost/install/lib/libboost_atomic.a boost/ >> install/lib/libboost_atomic.so >> boost/install/lib/libboost_atomic.so.1.61.0 >> boost/install/lib/libboost_chrono.a boost/install/lib/lib >> boost_chrono.so boost/install/lib/libboost_chrono.so.1.61.0 >> boost/install/lib/libboost_date_time.a boost/install/lib/libboost_date_t >> ime.so boost/install/lib/libboost_date_time.so.1.61.0 >> boost/install/lib/libboost_filesystem.a >> boost/install/lib/libboost_filesystem. >> so boost/install/lib/libboost_filesystem.so.1.61.0 >> boost/install/lib/libboost_system.a boost/install/lib/libboost_system.so >> boost/in >> stall/lib/libboost_system.so.1.61.0 boost/install/lib/libboost_thread.a >> boost/install/lib/libboost_thread.so boost/install/lib/libbo >> ost_thread.so.1.61.0 boost/install/lib/libboost_timer.a >> boost/install/lib/libboost_timer.so >> boost/install/lib/libboost_timer.so.1.61 >> .0) >> +foreach(F ${TBB_AND_BOOST_LIBS}) >> + install(PROGRAMS "${Dyninst_BINARY_DIR}/${F}" DESTINATION >> "${CMAKE_INSTALL_PREFIX}/lib") >> +endforeach() >> _______________________________________________ >> Dyninst-api mailing list >> Dyninst-api@cs.wisc.edu >> https://lists.cs.wisc.edu/mailman/listinfo/dyninst-api >> >
_______________________________________________ Dyninst-api mailing list Dyninst-api@cs.wisc.edu https://lists.cs.wisc.edu/mailman/listinfo/dyninst-api
