Hi, all.
The build issues with libiberty have been resolved in the latest commit to
HEAD. I have force-rebased the api_breakages branch, so you'll likely need to
purge your local copy and grab a fresh one. Please let me know if you encounter
any troubles (also let me know if you don't!).
Thanks.
- Tim
________________________________
From: Mark W. Krentel <kren...@rice.edu>
Sent: Tuesday, October 27, 2020 1:46 PM
To: Tim Haines <thai...@astro.wisc.edu>; dyninst-api@cs.wisc.edu
<dyninst-api@cs.wisc.edu>
Subject: Re: [DynInst_API:] API-breaking changes for upcoming Dyninst 11.0
release
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 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<mailto:Dyninst-api@cs.wisc.edu>
https://lists.cs.wisc.edu/mailman/listinfo/dyninst-api
_______________________________________________
Dyninst-api mailing list
Dyninst-api@cs.wisc.edu<mailto: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
