release cmake configury: unable to install under /usr/lib64/... about dyninst HOT 7 CLOSED

@hainest, what do you think about include(GNUInstallDirs) and then use the variables: CMAKE_INSTALL_BINDIR, CMAKE_INSTALL_INCLUDEDIR and CMAKE_INSTALL_LIBDIR as defaults for the dyninst variables. These are advanced cached options and are supposed use pick lib or lib64 depending on the platform and would allow user definitions.

from dyninst.

Looking at the old code, it's not clear to me that DYNINST_INSTALL_LIBDIR would have had any influence on the install paths. Previously, they were hard-coded in INSTALL_{LIB,INCLUDE}_DIR and then extended to be absolute paths relative to CMAKE_INSTALL_PREFIX. This has never been the correct method of setting installation paths in CMake, so it was removed.

The current DYNINST_INSTALL_{LIB,BIN,INCLUDE,CMAKE}DIR are internal variables that cannot be set by users. At one point, I had thought it might be useful to let users set the installation structure, but ultimately decided against it as it would make the resulting CMake package non-portable. The downside is that all libraries are installed in 'lib' and not 'lib64', but both are generally in linker/loader default search paths. We've been testing on Fedora 37-39 with both the default /usr/lib and a custom CMAKE_INSTALL_PREFIX/lib without any trouble.

If there is a need to have them in */lib64, I could add a config variable for that.

from dyninst.

Hi, Tim, thanks for the response. Yeah I don't doubt that what you have there works (installing 64-bit binaries into /usr/lib). The problem is that as a distro packager, that's outside the guidelines used for cohesion of the whole system. I suppose the packaging scripts could move these files into /usr/lib64 after all your cmake stuff is finished. But it would be better if the package could be made to fit directly into distro filesystem standards.

from dyninst.

Similarly, installing dyninst headers right under /usr/include kinda works, but /usr/include/dyninst would let it cohabit with the many other system libraries better.

from dyninst.

@kupsch That works for me. Did you want to take this one?

from dyninst.

I'll take care of it.

Thanks.

from dyninst.

@fche let us know if the fix for this works for your use case.

from dyninst.