DynamoRIO
Simplify packaging of DynamoRIO
Add a pointer to any prior users list discussion.
This issue is a follow up of the discussion started in #5152.
Is your feature request related to a problem? Please describe.
Currently, packaging of DynamoRIO for OS distributions like Debian is not possible (without patches) due to a list of incompatibilities. The following list should help to keep track of the current status and changes that will be required.
Describe the solution you'd like
The following aspects should be changed:
- CMake
- [x] Add support for install-relocation via DESTDIR env variable #5152
- [ ] libdynamorio-dev: Make CMake scripts of DynamoRIO work with system install paths
- [ ] libdynamorio-dev: Make export targets relocatable (make LIBDIR / BINDIR configurable via cache variable)
- drrun
- [x] rework injection logic to support other directory structures as well (e.g.
/usr/lib/<multiarch-triplet>/dynamorio.so, config in/etc/dynamorio, etc...)- #5548
- #5443
- [ ] Find installed dynamorio tools / clients via conf.d style integration (each new client drops a file in
/etc/dynamorio/tools.d/). This makes it possible for third-party tools that are packaged as well to easily integrate into DR.
- [x] rework injection logic to support other directory structures as well (e.g.
- Libraries
- [x] Check if the
libdynamorio.soneeds the execution bit or if there are other strategies. Installing a library with execution bit set is discouraged or even forbidden for some distros. (It is required!) - [ ] Add SO version, describing ABI compatibility
- [x] Do not rely on checked-in binaries (like elftc). These should always be built from the sources (e.g. via externalProject). Xref #4422
- [x] fix build errors around dwarf2 when building in chroot Xref https://github.com/DynamoRIO/dynamorio/issues/5153#issuecomment-1573528227
- [x] Check if the
Describe alternatives you've considered
It is possible to work around some limitations (like expected directory layout of drrun) by using wrappers and ignoring checks. However, this is neither a clean solution, nor sustainable.
Additional context
- Debian policies: https://www.debian.org/doc/debian-policy/index.html
- Debian guide "How do I add a new package to the archive?"
- please note, I'm not a Debian "sponsor", so I cannot integrate that directly
We pull in and run the Dr. Memory CMake code (triggered by an option though so not required) to include it in our packages and it would need some of the same types of changes to be included in a distro package.
When building the current version of DynamoRIO in a schroot (via Debian sbuilder), the build breaks at the following step. When building the exact same configuration outside of the chroot, the build finishes correctly.
cd /<<PKGBUILDDIR>>/build_deb_release/ext/drsyms && /usr/bin/cc -DDRSYM_HAVE_LIBELFTC -DDR_HOST_X64 -DDR_HOST_X86 -DLINUX -DUSE_VISIBILITY_ATTRIBUTES -DX64 -DX86_64 -D_LARGEFILE64_SOURCE -Ddrsyms_EXPORTS -I/<<PKGBUILDDIR>>/build_deb_release -I/<<PKGBUILDDIR>>/build_deb_release/cmake/../include -I/<<PKGBUILDDIR>>/ext/drsyms/ext/lib64/release -I/<<PKGBUILDDIR>>/build_deb_release/ext/include -I/<<PKGBUILDDIR>>/ext/drsyms/libelftc/include -fPIC -fPIC -fno-exceptions -m64 -fno-strict-aliasing -funsigned-char -fno-stack-protector -fvisibility=internal -std=gnu99 -fno-unwind-tables -O3 -g3 -g -O2 -ffile-prefix-map=/<<PKGBUILDDIR>>=. -specs=/usr/share/dpkg/no-pie-compile.specs -Wall -Werror -Wwrite-strings -Wvla -Wno-unused-but-set-variable -Wno-stringop-truncation -Wno-format-truncation -Wno-stringop-overflow -fno-stack-protector -m64 -o CMakeFiles/drsyms.dir/drsyms_common.c.o -c /<<PKGBUILDDIR>>/ext/drsyms/drsyms_common.c
make[4]: *** No rule to make target '../ext/drsyms/libelftc/lib64/libdwarf.a', needed by 'ext/lib64/release/libdrsyms.so'. Stop.
make[4]: *** Waiting for unfinished jobs....
update: This is a Debian specific thing that all prebuilt binaries are removed from the sources package. If required, they need to be listed explicitly (which I now did until #4422 is implemented).