Repository navigation
[BUG] ImportError: libdbCore.so.7.0.10.99.0: cannot open shared object file: No such file or directory #197
Description
(venv) xilinx@Pynq-IMPCAS-ZU9:/opt/epics$ python -V
Python 3.11.14
(venv) xilinx@Pynq-IMPCAS-ZU9:/opt/epics$ uname -a
Linux Pynq-IMPCAS-ZU9 6.6.10-xilinx-v2024.1-g1594cb1cd9ce #1 SMP Sat Apr 27 05:22:24 UTC 2024 aarch64 aarch64 aarch64 GNU/Linux
(venv) xilinx@Pynq-IMPCAS-ZU9:/opt/epics$ uv pip install caproto pyepics pcaspy softioc
Using Python 3.11.14 environment at: venv
Resolved 12 packages in 51ms
Built pcaspy==0.8.1
Built epicscorelibs==7.0.7.99.1.2
Built pvxslibs==1.4.1
Built softioc==4.6.1
Prepared 4 packages in 34m 19s
Installed 12 packages in 154ms
+ caproto==1.3.0
+ epicscorelibs==7.0.7.99.1.2
+ epicsdbbuilder==1.5
+ numpy==2.4.0
+ pcaspy==0.8.1
+ pvxslibs==1.4.1
+ pyepics==3.5.9
+ pyparsing==3.3.1
+ pyyaml==6.0.3
+ setuptools==80.9.0
+ setuptools-dso==2.12.2
+ softioc==4.6.1
(venv) xilinx@Pynq-IMPCAS-ZU9:/opt/epics$ python -c "import softioc"
Traceback (most recent call last):
File "<string>", line 1, in <module>
File "/opt/epics/venv/lib/python3.11/site-packages/softioc/__init__.py", line 14, in <module>
from .imports import dbLoadDatabase, registerRecordDeviceDriver
File "/opt/epics/venv/lib/python3.11/site-packages/softioc/imports.py", line 10, in <module>
from . import _extension
ImportError: libdbCore.so.7.0.10.99.0: cannot open shared object file: No such file or directory
Activity
ra9fael commentedon Jan 8, 2026
Workaround:
OCopping commentedon Jan 8, 2026
I noticed this too in my techui-builder repo, when attempting to run py3.13 CI, and also fixed by installing epicscorelibs>=7.0.10 manually
AlexanderWells-diamond commentedon Jan 8, 2026
Thank you for the report @konosubakonoakua . This issue is due to a recent release of epicscorelibs, and a discrepancy between softioc's build-time and run-time dependencies on epicscorelibs. This is happening for you as we don't have any
aarch64wheels in PyPi. It is happening for @OCopping because we don't have any wheels for Python >= 3.13. So both of you are building the wheels yourself locally and exposing this issue.AlexanderWells-diamond commentedon Jan 8, 2026
I'm still struggling to work out why epicscorelibs downgrades itself between build-time and run-time. Here's a verbose logfile that shows
softiocwanting a version ofepicscorelibs>=7.0.7.99.1.2a1, <7.0.7.99.2:This log shows why we also get an old version of pvxslibs - it tries to find a version of it that is compatible with the lower version of epicscorelibs.
@mdavidsaver notes here that it may be a bug in
epicscorelibs.version.abi_requires(although I suspect by the time we invoke it it's too late - surely we've already got a version of epicscorelibs installed in order to run that function?) or thatuvmay somehow be affecting it - but I think the above log file counteracts that, asuv pip ...should just be a wrapper aroundpipitself. Tomorrow I should try and recreate it using justpip.mdavidsaver commentedon Jan 8, 2026
I am not convinced of this, and a little confused about what I read. At what point is the
softiocpackage built?Selecting: softioc==4.6.1suggests to me that a build from source would be done, using the build dependency frompyproject.toml, which is notepicscorelibs>=7.0.7.99.1.2a1, <7.0.7.99.2.mdavidsaver commentedon Jan 8, 2026
In a manylinux2014_amd64 container, if I run:
The resulting build downloads
epicscorelibs-7.0.10.99.0.0-cp313-cp313-manylinux2014_x86_64.whl. The resultingsoftioc-4.6.1.dist-info/METADATAcontains:And
readelf -d softioc/_extension.cpython-313-x86_64-linux-gnu.soshows:Which is all as I expect.
Full pip output
mdavidsaver commentedon Jan 9, 2026
For reasons I can not fathom, despite running in py3.13, and needing to build from
.tar.gz,uvseems to be looking at the meta-data for the py3.10 wheel for softioc!Looking at the resulting situation,
softiocis correctly built against 7.0.10.... however, 7.0.7 is left installed.
To my mind, this looks like a bug in the dependency resolver of
uv.AlexanderWells-diamond commentedon Jan 9, 2026
Thank you for the investigation Michael. I agree that this appears to be a
uvbug. I've raised it as an issue over there:astral-sh/uv#17378
I'll keep this issue open for the time being.
AlexanderWells-diamond commentedon Jan 13, 2026
So it turns out this is not a
uvbug, it's simply thatpipanduvhave different semantics regarding build-time vs run-time dependency resolution. The last paragraph of the Metadata consistency docs explains the situation, as well as additional discussion in the linkeduvbug.The workaround for all
uvusers is to add a setting to theirpyproject.toml- specifyingmatch-runtime = trueas documented in Augmenting build dependencies.I intend to write a note in our documentation to explain this. I also plan to do another release in the near future, which will include Python3.13 on x86_x64 and will remove the issue of building
pythonSoftIOCitself completely. It will unfortunately not include ARM at this time due to a large number of issues encountered when trying to run the CI on those platforms.I'll leave this open until the docs are written.