Hello,
We are migrating our Lab workstations from CentOS7 to Rocky Linux 8.6 and one of the needed packages, compat-db47 doesn’t seem to be in the repository. It’s required for one of our Commercial Electronic Design Automation (EDA) tools.
When I search the web I see the RPM for it available in multiple places but I wanted to know if there is a preferred place to download it from.
Also missing are python modules numpy and python-matplotlib . Again, any preferred place to download it from ?
Thanks in advance for the support.
Hi,
I can see the numpy and matplotlib modules without problems:
[root@rocky8 ~]# dnf search numpy
Last metadata expiration check: 1:48:05 ago on Tue 09 Aug 2022 11:40:56 CEST.
======================== Name & Summary Matched: numpy =========================
boost169-numpy2.x86_64 : Run-time component of boost numpy library for Python 2
boost169-numpy3.x86_64 : Run-time component of boost numpy library for Python 3
python2-numpy-doc.noarch : Documentation for numpy
python2-numpy-f2py.x86_64 : f2py for numpy
python3-numpy-f2py.x86_64 : f2py for numpy
python3-numpydoc.noarch : Sphinx extension to support docstrings in NumPy format
python38-numpy-doc.noarch : Documentation for numpy
python38-numpy-f2py.x86_64 : f2py for numpy
python39-numpy-doc.noarch : Documentation for numpy
python39-numpy-f2py.x86_64 : f2py for numpy
============================= Name Matched: numpy ==============================
python2-numpy.x86_64 : A fast multidimensional array facility for Python
python3-numpy.x86_64 : A fast multidimensional array facility for Python
python38-numpy.x86_64 : A fast multidimensional array facility for Python
python39-numpy.x86_64 : A fast multidimensional array facility for Python
============================ Summary Matched: numpy ============================
netcdf4-python.x86_64 : Python/numpy interface to netCDF
python3-Bottleneck.x86_64 : Collection of fast NumPy array functions written in
: Cython
python3-netcdf4.x86_64 : Python/numpy interface to netCDF
python3-nptyping.noarch : Type hints for Numpy
python3-numexpr.x86_64 : Fast numerical array expression evaluator for Python
: and NumPy
[root@rocky8 ~]# dnf search matplot
Last metadata expiration check: 1:48:23 ago on Tue 09 Aug 2022 11:40:56 CEST.
===================================== Name & Summary Matched: matplot =====================================
python3-matplotlib-data.noarch : Data used by python-matplotlib
python3-matplotlib-data-fonts.noarch : Fonts used by python-matplotlib
python3-matplotlib-doc.x86_64 : Documentation files for python-matplotlib
python3-matplotlib-gtk3.x86_64 : GTK3 backend for python3-matplotlib
python3-matplotlib-qt5.x86_64 : Qt5 backend for python3-matplotlib
python3-matplotlib-test-data.x86_64 : Test data for python3-matplotlib
python3-matplotlib-tk.x86_64 : Tk backend for python3-matplotlib
python3-matplotlib-wx.x86_64 : WX backend for python3-matplotlib
========================================== Name Matched: matplot ==========================================
python3-matplotlib.x86_64 : Python 2D plotting library
======================================== Summary Matched: matplot =========================================
python2-cycler.noarch : Cycle through lists in various ways (used by matplotlib)
python3-cycler.noarch : Cycle through lists in various ways (used by matplotlib)
failing that, there is always the ability to install using python-pip packages if something isn’t available in the repositories by default.
Unfortunately, compat-db47 is a package for RHEL7 and therefore doesn’t exist in RHEL8. If you need something like this, then it would mean building it and installing separately.
Thanks a lot @iwalker for that prompt response.
You are right: the numpy and matplotlib packages are there just different pkg names than CentOS 7.
The shared library which the EDA tool cannot find is libdb-4.7.so which is part of the comapt-db47 package.
Unfortunately, the EDA Tools still doesn’t support RHEL 8 (only 6 & 7). We are running CentOS 7 in our Lab very successfully but we got 12 new desktops and CentOS 7 doesn’t support their graphics chipset so we were trying to migrate to Rocky 8 for the new desktops.
Can you suggest how can I build the above shared library and install it in Rocky Linux ?
Thanks again for your support.
I tried mock --rebuild compat-db-4.7.25-28.el7.src.rpm and it did stop with:
configure: error: No rpcgen utility found.
Therefore, the most obvious way to (re)build a package does not succeed hands down. (It might be possible to include the missing pieces, but my mock-fu is very weak.)
Could you create a (CentOS 7-based) container for your application? Those have been the hype lately.
Overall, the name “compat-db47” tells that the library was provided to EL7 in order to keep old (pre-EL7) binaries usable. EL7, EL8, and EL9 all have Berkeley Database version 5.3. The EL7 was released June 2014 – 8 years ago – so the application is older than that? (I know how painful legacy software can be.)
rpcgen does appear in powertools repository, so it could be installed. Maybe that would help it work with mock?
Hello Ian,
I apologize for being little ignorant about the mock build up process.
Are these the steps to do a build:
- install rpcgen. I need to figure out how to install it from the powertool repo.
- Get the compat-db-4.7…rpm. Is there a preferred place to download it from ?
- mock --rebuild
compat-db-4.7.25-28.el7.src.rpm?
If that’s successful, is that it ?
Also the container method sounds promising but will be a completely new effort for me. Trying to minimize that. May have to resort to it if all fails.
Thanks a lot again.
Hi,
You can do that like this:
dnf config-manager --set-enabled powertools
dnf install rpcgen
I’m not sure for points 2,3 maybe @jlehtone would be able to help out as I’ve never used mock.
The only place that seems to have the compat-db47 seems to be CentOS 7. The source I did try was from there:
wget http://vault.centos.org/7.9.2009/os/Source/SPackages/compat-db-4.7.25-28.el7.src.rpm
In order to get mock, one has to have EPEL. Therefore,
sudo dnf install epel-releasesudo dnf install mock- Add yourself to group ‘mock’ with:
sudo usermod -a -G mock srout(if your account is srout) - Existing session does not auto-detect new group memberships. Log out and log back in.
The mock has multiple target configurations that are stored in /etc/mock/. There is probably symbolic link /etc/mock/default.cfg that points to some config. For config that is used, mock creates a chroot sandbox, installs to it target’s tools and whatever the rebuild requires (but apparently it can fail).
See Building RPM packages with mock | Packagecloud Blog
Also, see man mock
Since the mock does not use host’s development tools, installation of ‘rpcgen’ (which was in glibc-common in el7) on the host does not help; it has to be installed into the chroot environment:
mock -r rocky+epel-8-x86_64 --init
mock -r rocky+epel-8-x86_64 --install rpcgen
mock -r rocky+epel-8-x86_64 --no-clean compat-db-4.7.25-28.el7.src.rpm
Alas, even with this the build fails. This time on compiler error:
../../repmgr/repmgr_net.c: In function '__repmgr_listen':
../../repmgr/repmgr_net.c:1139:2: error: format not a string literal and no format arguments [-Werror=format-security]
__db_err(env, ret, why);
^~~~~~~~
The C compiler, gcc, is version 8.5 in Rocky 8 and has default -std=gnu17 GNU dialect of ISO C17.
The gcc in CentOS 7 has version 4.8 and has default -std=gnu90 GNU dialect of ISO C90 (including some C99 features). I’d guess this is the reason for the error. (The configure output did not show any explicit ‘-std=’ so defaults are likely.)
Can one pass additional compiler options into mock process? Honestly, I don’t know.
If the build had succeeded, then there would be RPM-files in directory /var/lib/mock/rocky+epel-8-x86_64/result/
One would still have to install them with the sudo dnf install name(s)-of-rpm-file(s)
This article explains the specific -Werror
It’s basically saying the code could be insecure.
Here’s a patch to the original spec file that works for me:
--- compat-db.spec.orig 2014-09-11 19:36:02.000000000 +0200
+++ compat-db.spec 2022-08-11 11:59:43.420617000 +0200
@@ -27,7 +27,7 @@
URL: http://www.oracle.com/database/berkeley-db/
License: BSD
Group: System Environment/Libraries
-BuildRequires: findutils, libtool, perl, sed, ed
+BuildRequires: findutils, libtool, perl, sed, ed, rpcgen, libtirpc-devel
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
Requires: compat-db47%{?_isa} = %{db47_version}-%{release}
@@ -86,7 +86,9 @@
cp %{SOURCE1} .
%build
-export CFLAGS="$RPM_OPT_FLAGS -fno-strict-aliasing"
+RPM_OPT_FLAGS=$(echo $RPM_OPT_FLAGS | sed 's/-Werror=format-security//')
+export CFLAGS="$RPM_OPT_FLAGS -fno-strict-aliasing -I/usr/include/tirpc"
+export LDFLAGS="$RPM_LD_FLAGS -ltirpc"
for version in %{db4_versions} ; do
pushd db-${version}/dist
./s_config
A copr build can be found here: mlampe/compat-db47 Copr
I have only verified that the rpms produced can be installed. I have no software that needs them, so I didn’t really test them.
2 Likes
Not sure if turning off security is a good idea.
“Turn off security”?? That legacy code has a format string problem since 2011 or earlier. This problem was built into every package produced since. Not promoting the compiler warning to an error (which el8 now does by default) still allows the package to be built. The only alternative is to fix the code.
The “proper” alternative would be to update the applications to use “modern” libdb.
Thanks a lot @jlehtone and @chemal for that mock build.
I was able to install it from the copr repo and now the application runs with few other warnings but I was able to test most of the features that we regularly use.
Can’t thank you guys enough. I was ready to buy some graphics card and go back to CentOS 7. This EDA vendor Cadence is a monopoly in IC design market so currently they support RHEL 6/7 only. Waiting for them to use modern libs will be years!
Also our desktops run in a closed network without any outside access so I am not sure if that alleviates a bit of the security problem.
Thanks a lot again.
It’s just that RH (following Fedora) raised the standards. Packagers now have to fix format-string warnings, because they are automatically promoted to errors. If you had no worries about the packages in el6 and el7, you maintained the status quo. There’s nothing new.
Good point. Makes sense.
I can’t find this package. Can you build it again?
Try again, the link should work now.