RPM Packaging - what is thumping in the build root?

Discuss anything related to product development
Post Reply
seasoned_geek
Posts: 253
Joined: Thu Jun 11 2020 12:18 pm

RPM Packaging - what is thumping in the build root?

Post by seasoned_geek »

All,

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](https://github.com/RolandHughes/copperspice/tree/RPM) 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.


Code: Select all

[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
libCsCore1.8.so:8298432:/home/developer/rpmbuild/BUILDROOT/copperspice-1.8-1.x86_64
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


Code: Select all

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.

Once this is done I will redo the Debian packaging since I already had to walk on project cmake files to get RPM this far along.

Thanks,
seasoned_geek
Posts: 253
Joined: Thu Jun 11 2020 12:18 pm

Re: RPM Packaging - what is thumping in the build root?

Post by seasoned_geek »

I don't know what is causing the problem, but I finally tracked down the where.

hexdump --canonical libCsCore1.8.so > ~/h.log

Code: Select all

007e9f60  41 53 53 45 52 54 20 66  61 69 6c 75 72 65 20 69  |ASSERT failure i|
007e9f70  6e 20 25 73 3a 20 22 25  73 22 2c 20 66 69 6c 65  |n %s: "%s", file|
007e9f80  20 25 73 2c 20 6c 69 6e  65 20 25 64 00 31 2e 38  | %s, line %d.1.8|
007e9f90  2e 31 00 00 00 00 00 00  49 6e 20 66 69 6c 65 20  |.1......In file |
007e9fa0  25 73 2c 20 6c 69 6e 65  20 25 64 3a 20 4f 75 74  |%s, line %d: Out|
007e9fb0  20 6f 66 20 6d 65 6d 6f  72 79 00 00 00 00 00 00  | of memory......|
007e9fc0  2f 68 6f 6d 65 2f 64 65  76 65 6c 6f 70 65 72 2f  |/home/developer/|
007e9fd0  72 70 6d 62 75 69 6c 64  2f 42 55 49 4c 44 52 4f  |rpmbuild/BUILDRO|
007e9fe0  4f 54 2f 63 6f 70 70 65  72 73 70 69 63 65 2d 31  |OT/copperspice-1|
007e9ff0  2e 38 2d 31 2e 78 38 36  5f 36 34 2f 75 73 72 00  |.8-1.x86_64/usr.|
007ea000  43 6f 70 70 65 72 53 70  69 63 65 20 42 75 69 6c  |CopperSpice Buil|
007ea010  64 20 49 6e 66 6f 72 6d  61 74 69 6f 6e 3a 20 0a  |d Information: .|
007ea020  20 20 20 56 65 72 73 69  6f 6e 3a 20 20 20 20 20  |   Version:     |
007ea030  20 20 20 20 20 25 73 0a  20 20 20 42 75 69 6c 64  |     %s.   Build|
007ea040  20 44 61 74 65 3a 20 20  20 20 20 20 20 25 73 0a  | Date:       %s.|
007ea050  20 20 20 49 6e 73 74 61  6c 6c 20 50 72 65 66 69  |   Install Prefi|
007ea060  78 3a 20 20 20 25 73 0a  20 20 20 42 75 69 6c 74  |x:   %s.   Built|
007ea070  20 46 6f 72 3a 20 20 20  20 20 20 20 20 25 73 0a  | For:        %s.|
007ea080  00 32 30 32 33 2d 30 33  2d 30 38 00 3a 2f 63 73  |.2023-03-08.:/cs|
007ea090  2f 65 74 63 2f 63 73 2e  63 6f 6e 66 00 44 65 76  |/etc/cs.conf.Dev|
007ea0a0  69 63 65 50 61 74 68 73  00 45 66 66 65 63 74 69  |icePaths.Effecti|
007ea0b0  76 65 50 61 74 68 73 00  4d 4d 2f 64 64 2f 79 79  |vePaths.MM/dd/yy|
007ea0c0  79 79 00 78 38 36 5f 36  34 2d 72 65 64 68 61 74  |yy.x86_64-redhat|
offset 007e9fc0

Looks like some form of "build_info" that includes the CMAKE_INSTALL_PREFIX is being included deep in the library.

Yes, this is what is killing us.

Code: Select all

include/QtCore/cs_build_info.h:35:      static constexpr const char *install_prefix = "/home/developer/rpmbuild/BUILDROOT/copperspice-1.8-1.x86_64/usr";
Post Reply