What thumps a path into a shared library?

This ought to be stupid simple but I’m slamming my head against the wall to find it.

Fork of CopperSpice project with RPM branch so I can package the library in RPM form now that I have Debian working. I tried to be the least invasive possible when creating the Debian packages, but RPM leaves little choice. Must modify the package cmake files.

Exactly one library file fails the final path test of RPM packaging.

[developer@fedora lib64]$ grep -i --byte-offset --only-matching --text '/home/developer/rpmbuild/BUILDROOT/copperspice-1.8-1.x86_64' *

grep: cmake: Is a directory
grep: copperspice: Is a directory
grep: pkgconfig: Is a directory
[developer@fedora lib64]$

It is also the only library still getting a SONAME and RUNPATH stuffed into it.

[developer@fedora lib64]$ readelf -d libCsCore1.8.so | head -20

Dynamic section at offset 0xb124e0 contains 31 entries:

  Tag        Type                         Name/Value

 0x0000000000000001 (NEEDED)             Shared library: [libz.so.1]
 0x0000000000000001 (NEEDED)             Shared library: [libstdc++.so.6]
 0x0000000000000001 (NEEDED)             Shared library: [libm.so.6]
 0x0000000000000001 (NEEDED)             Shared library: [libgcc_s.so.1]
 0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]
 0x0000000000000001 (NEEDED)             Shared library: [ld-linux-x86-64.so.2]
 0x000000000000000e (SONAME)             Library soname: [libCsCore1.8.so]
 0x000000000000001d (RUNPATH)            Library runpath: [$ORIGIN/../lib64/copperspice/bin:$ORIGIN/..]
 0x000000000000000c (INIT)               0x1f9000
 0x000000000000000d (FINI)               0x7dcf9c
 0x0000000000000019 (INIT_ARRAY)         0xae3df8
 0x000000000000001b (INIT_ARRAYSZ)       56 (bytes)
 0x000000000000001a (FINI_ARRAY)         0xae3e30
 0x000000000000001c (FINI_ARRAYSZ)       16 (bytes)
 0x000000006ffffef5 (GNU_HASH)           0x338
 0x0000000000000005 (STRTAB)             0x78ad8
 0x0000000000000006 (SYMTAB)             0x1b6b8
[developer@fedora lib64]$

Entire process is kicked off by build-copperspice-rpm.sh
Initial CMakeLists.txt is in the same directory
the CsCore library is built by src/core/CMakeLists.txt

I cannot for the life of me figure out what is thumping in the root of the RPM build directory.

Can anyone see where CMake is thumping this into the library?

This is the final set and the only problem I know of stopping RPM creation. Everything is properly built when you get down to path verification. I’ve built many RPM packages before. Just need someone to point me to where this is broken.



However, I do not see the build path in that readelf -d output. Is there somewhere else in the library that has that path?

Thanks Ben,

I should have popped back in to say I found it. CopperSpice has a cs_build_info.h.in file that gets parsed during cmake.


// CopperSpice Version  "1.0.0"

// CopperSpice Version  0x010000  (major << 16) + (minor << 8) + patch

#if defined(__cplusplus)
   struct CsLibraryInfo {
      static constexpr const char *install_prefix = "@prefix@";
      static constexpr const char *built_for = "@target@";


I have had to get most invasive with the CMakeLists.txt, *.cmake, and *.pc files for the project. The current build process is set up to build to some “development” type directory tree because the library is still under rather active development. That “prefix” variable was being set to the full cmake install path. When building RPM or Debian packages one is building into a BUILDROOT or fakeroot tree. You don’t want the full path, you want the relative.

Testing what should be the final 3.5 hour build now.

Thanks for assisting!

Files that produce the final build should be checked into the RPM branch found here. What is there now produces an all-things-to-everyone RPM. Testing the split into run-time and -devel now.