Thanks for the info. The SONAME is correct:
$ objdump -p /lib64/libngspice.so.0.0.1 | grep SONAME
SONAME libngspice.so.0
As I discovered and mentioned in my second email, the problem seems to be in
the explicit loading of $NGSPICE_DLL_FILE, which is set to the more constrained
name.
I'll check out the link you provided.
Thanks,
Steve
On 8/23/21 11:28 AM, Reece R. Pollack wrote:
Typically the way this is handled is that the application is linked against a
symlink to the library that references the library's SONAME rather than the
full name of the library. In the runtime system, a symlink with this name
points at the correct file.
To check the SONAME in the library, use this incantation:
objdump -p //path/to/library/ |grep SONAME
I run Kubuntu rather than Fedora, so I don't know the SONAME of Fedora's
libngspice. On Kubuntu 20.04, I get this:
$ objdump -p /usr/lib/x86_64-linux-gnu/libngspice.so.0.0.0 |grep SONAME
SONAME libngspice.so.0
On the build system, I have these files:
libngspice.so -> libngspice.so.0.0.0
libngspice.so.0 -> libngspice.so.0.0.0
libngspice.so.0.0.0
The application developer typically links against libngspice.so rather than
libngspice.so.0.0.0 to avoid having to know which library version is installed.
At build time the linker will pick up the SONAME embedded in this .so file.
At runtime the loader will use the SONAME to find the library. You can use "ldd" to see what
libraries the built application is linked against. The part to the left of the "=>" is
the SONAME, and the part to the right is the name of the file that will be used on /this/ system.
Here's a link to the Debian policy on shared libraries for a detailed
explanation of how this works:
https://www.debian.org/doc/debian-policy/ch-sharedlibs.html
On 8/23/21 10:29 AM, Steven A. Falco wrote:
I just got a bug report for the official Fedora version of KiCAD stating that
ngspice was not found. An attempt to perform a simulation results in KiCAD
crashing.
The Fedora KiCAD package specifies libngspice.so.0.0.0, but the library has now
bumped to libngspice.so.0.0.1. I would have expected that to be fine, because
the new library should be compatible. But apparently, the loader is looking
for an exact match, and refuses to use the newer library.
For now, I'm rebuilding the official package to match the new ngspice library,
but I'm wondering if there is a way to improve this situation, such that KiCAD
links with libngspice.0 rather than insisting on an exact match of the minor
number.
Steve
_______________________________________________
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help : https://help.launchpad.net/ListHelp
_______________________________________________
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help : https://help.launchpad.net/ListHelp
_______________________________________________
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help : https://help.launchpad.net/ListHelp
