Ok, there has been a recent change in how dyninst config treats
libiberty. My recipe below works for 10.2.1, but fails for both
current master and api_breakages.
In 10.2.1, cmake ignores LibIberty_ROOT_DIR and even says:
CMake Warning:
Manually-specified variables were not used by the project:
LibIberty_ROOT_DIR
But master and api_breakages do test for and actually use libiberty
but aren't setting an include directory and thus fail with:
/home/krentel/dyninst/dyninst/common/src/symbolDemangle.c:34:10:
fatal error: libiberty/demangle.h: No such file or directory
#include <libiberty/demangle.h>
The failure doesn't depend on STERILE build.
So, exactly how are you building dyninst master?
And why are you not seeing build failures like this?
This is a cmake error right?
Not setting an include directory?
--Mark
On 10/27/20 13:16, Mark W. Krentel wrote:
Uh, exactly how are you building dyninst api_breakages?
I tried building this directly from cmake using spack-built prereqs.
I get this failure about unable to find libiberty include directory
[ 9%] Building CXX object
common/CMakeFiles/common.dir/src/addrtranslate-linux.C.o
[ 9%] Building CXX object
common/CMakeFiles/common.dir/src/symbolDemangleWithCache.C.o
[ 10%] Building C object
common/CMakeFiles/common.dir/src/symbolDemangle.c.o
/home/krentel/dyninst/dyninst/common/src/symbolDemangle.c:34:10: fatal
error: libiberty/demangle.h: No such file or directory
#include <libiberty/demangle.h>
^~~~~~~~~~~~~~~~~~~~~~
compilation terminated.
make[2]: *** [common/CMakeFiles/common.dir/build.make:531:
common/CMakeFiles/common.dir/src/symbolDemangle.c.o] Error 1
make[1]: *** [CMakeFiles/Makefile2:516:
common/CMakeFiles/common.dir/all] Error 2
make: *** [Makefile:130: all] Error 2
I ran cmake (from a script, so cmake, not ccmake) as:
-DBoost_ROOT_DIR=/home/krentel/Spack/install/linux-fedora26-x86_64/gcc-7.3.1/boost-1.72.0-rr5wnwst3gs4d7trleowhmfzozlsfj4b
-DElfUtils_ROOT_DIR=/home/krentel/Spack/install/linux-fedora26-x86_64/gcc-7.3.1/elfutils-0.180-ssvmwyzbhnjianyboxxkygoza3mpue74
-DLibIberty_ROOT_DIR=/home/krentel/Spack/install/linux-fedora26-x86_64/gcc-7.3.1/libiberty-2.33.1-rqdhvmvj7cdxs6fietjsut5j72ytv7er
-DTBB_ROOT_DIR=/home/krentel/Spack/install/linux-fedora26-x86_64/gcc-7.3.1/intel-tbb-2020.3-ysaadslo6sebbjsfqcczq2mbyndwsb33
-DCMAKE_BUILD_TYPE=RelWithDebInfo
-DCMAKE_INSTALL_PREFIX=/home/krentel/dyninst/install
-DUSE_OpenMP=ON
-DSTERILE_BUILD=ON
I checked that the libiberty (and other spack) paths are correct,
there is an include directory and it does contain libiberty/demangle.h.
But I noticed in the cmake configure, there are settings for libiberty
lib dirs, not not include dirs.
-- Found LibIberty:
/home/krentel/Spack/install/linux-fedora26-x86_64/gcc-7.3.1/libiberty-2.33.1-rqdhvmvj7cdxs6fietjsut5j72ytv7er/lib64/libiberty.a
-- LibIberty library dirs:
/home/krentel/Spack/install/linux-fedora26-x86_64/gcc-7.3.1/libiberty-2.33.1-rqdhvmvj7cdxs6fietjsut5j72ytv7er/lib64
-- LibIberty libraries:
/home/krentel/Spack/install/linux-fedora26-x86_64/gcc-7.3.1/libiberty-2.33.1-rqdhvmvj7cdxs6fietjsut5j72ytv7er/lib64/libiberty.a
Same for ccmake, there is no libiberty include variable.
Is it possible that your cmake config is not testing and setting a
libiberty include directory ??
And maybe this fails for me because I'm using STERILE_BUILD and maybe
other builds aren't and thus picking up the system libiberty ??
--Mark
On 10/26/20 16:02, Tim Haines wrote:
Hi, all.
We have several API-breaking changes we want to include in the next
major release of Dyninst (11.0). To help everyone prepare for these
changes, I've stored them on a topic branch, api_breakages
<https://github.com/dyninst/dyninst/tree/api_breakages>, instead of
merging them into master. If you could try building your software
against this branch and let me know if you have any troubles (also
let me know if you don't have any!), it will very much help us stay
ahead of any bumps in the road we may encounter for this upcoming
release. I've outlined the specific API changes below.
Many thanks.
- Tim
P.S. Apologies if you've seen this before. I'm having troubles with
the mailing list and my gmail account.
parseAPI
Removed CFGFactory::destroy_all
dyninstAPI
Removed BPatch_regExpr class
Removed "findFunctionByAddr(void *addr)". Replace with either
"findFunctionByEntry" or "findFunctionsByAddr". See
https://github.com/dyninst/dyninst/issues/820#issuecomment-683375892
<https://github.com/dyninst/dyninst/issues/820#issuecomment-683375892>
for details.
Removed "BPatch_process::enableDumpPatchedImage"
Removed "BPatch_snippet::getCost()", "BPatch_snippet::getCostAtPoint"
patchAPI
"Patcher::create" now returns a "boost::shared_ptr<Patcher>" instead
of a "Patcher*"
symtabAPI
If you have any classes which inherit from "SerializerBase" or
"Serializable", those base classes should be removed. Please note
that this will have no effect on the behavior of your programs as the
serialization feature has been disabled since 2012.
_______________________________________________
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
_______________________________________________
Dyninst-api mailing list
Dyninst-api@cs.wisc.edu
https://lists.cs.wisc.edu/mailman/listinfo/dyninst-api
