Build libdynamorio.so standalone

[Byron Hawkins]

I'm using DynamoRIO as a standalone library in a project that does not use cmake, and I've recently encountered the "too-recent" errors after upgrading to Fedora 34 (which has libc 2.33). What I'd prefer is to build libdynamorio.so without any comopnents that interact with libc. But so far it isn't working.

It's possible to make DynamoRIO a subproject in my meson build configuration, but meson gives me no way to call the  cmake function "configure_DynamoRIO_standalone". The cmake flag "DYNAMORIO_STANDALONE" is apparently not modifiable from the cmake command line. So I tried "-DBUILD_TOOLS=OFF -DBUILD_[EVERYTHING...]=OFF", but there are endless build problems with references to missing components (for example, dr_api.h includes dr_config.h, which is never generated in this build configuration).

Is there another way to just build libdynamorio.so without any other components? If not, what's the recommended workaround? Some possibilities are:

1. tweak the cmake files to skip "check_libc", since I won't ever use those components anyway

2. make a trivial cmake project as a wrapper and call "configure_DynamoRIO_standalone". These seems fairly complicated since I don't know much about cmake and have never made a cmake project from scratch.

3. tweak the cmake files to understand "-DDYNAMORIO_STANDALONE" on the command line and call "configure_DynamoRIO_standalone".

Does anyone have a recommendation for how to work out this build scenario?

[Derek Bruening]

I didn't think libdynamorio.so was checked at all for libc imports as it has zero libc dependencies: it's things like drrun that are checked.  If you could paste the error you see to confirm which binary it is?

--
You received this message because you are subscribed to the Google Groups "DynamoRIO Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dynamorio-use...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/dynamorio-users/8afb69db-d5ea-48ea-97c1-312967360261n%40googlegroups.com.

[Byron Hawkins]

Yes, that's the idea, by limiting the build to libdynamorio.so, the "too-recent" errors are no longer a problem. However, the build is not usable. For example, if my project has "#include dr_api.h", there are build errors (in my external project, not in dynamorio) because (a) file "dr_api.h" has "#include dr_config.h", and (b) file "dr_config.h" does not exist.

The only way to get a "dr_config.h" is with "-DBUILD_TOOLS=ON". But that will cause "too-recent" errors on libc. Ideally, a build with "-DBUILDTOOLS=OFF" would generate a "dr_api.h" that does not "#include dr_config.h". In the current DR build system, this is already possible using a cmake function. But I can't call cmake functions from my meson project, so I'm stuck with workarounds.

For now I just downloaded the latest release, which does not complain about my libc, perhaps because I never run any of the DR executables.

You received this message because you are subscribed to a topic in the Google Groups "DynamoRIO Users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/dynamorio-users/Y2cUFCgESHA/unsubscribe.
To unsubscribe from this group and all its topics, send an email to dynamorio-use...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/dynamorio-users/CAO1ikSYT38FO9LQc7RUku5EdQYwV2_z0wXE1VAxABrth8ovjyg%40mail.gmail.com.

[Derek Bruening]

Oh, ok, I misread the original email as being about libdynamorio.so itself encountering libc complaints.

> For now I just downloaded the latest release, which does not complain about my libc, perhaps because I never run any of the DR executables.

It's because it was built on Github Actions with a toolchain that doesn't pull in new libc features.

One solution would be to distinguish a build for local use on that same machine from a build meant to be used on other machines.  The recent-libc checks would only be performed in the latter case.  The latter case could be tied to the use of make/package.cmake.  Not sure if it already sets some var that the libc checking code can look at it or whether some new variable needs to be added.

To view this discussion on the web visit https://groups.google.com/d/msgid/dynamorio-users/CAKYbu6g_vDeyb4eWbuBm8LAmsnwmPTFFgdK2nSyRLk_GP4e81w%40mail.gmail.com.

[Derek Bruening]

Xref https://github.com/DynamoRIO/dynamorio/issues/5130#issuecomment-961510399