Building rpm packages from static compiled data that your software vendor provides can be a little confusing, for instance simpana, a backup client by commvault.
Commvault provides an installer that copies their binary files in the right place, applies hot-fixes, etc.. For easy distribution i tried to create an rpm package around this installer.
So far, everything seems to be just fine. The RPM file has been created and is ready to install. Sadly the installer fails for some obscure reason..
[3%] Verifying CRC32 for Base/libCvLib.so …
*** File Base/libCvLib.so is corrupt.
*** CRC32 checksums do not match.*** Failed to install package CVGxBase
So there is some CRC32 checking on all kinds of files in the install script, the CRC32 checking is done by “pkgcrc32”. The install script cross references the copied file with the input file “contents”
pkgcrc32 Base/libCvLib.so
rpm: 0xea2faf1c
source: 0xdbdca5e0
At first i thought my source tar archive was corrupt, so I extracted the tar archive, but the CRC32 checksum seemed to be the same as the one from the vendor: 0xdbdca5e0
Oddly the source & binary RPM contain the modified version of that shared object file.
Investigating the RPM build process I found out there is a difference between the extracted source, the buildroot and the buildroot after the building is completed. This means the shared object file is modified during the rpm building.
There are only a few other scripts that are being executed upon an RPM build:
+ /usr/lib/rpm/brp-compress
+ /usr/lib/rpm/brp-strip
+ /usr/lib/rpm/brp-strip-static-archive
+ /usr/lib/rpm/brp-strip-comment-note
One of these script is: “brp-strip-comment-note”, it creates an object dump of your shared object and checks for the .comment symbol, which it, at the end of the script, strips it. This makes the CRC32 checking very unhappy..
You can resolve this matter by putting this option in your .spec file:
%define __os_install_post %{nil}
no more unwanted strips, compression etc on your binary files..