kicad-developers team mailing list archive

Thread
Date

Re: ngspice library version

To: kicad-developers@xxxxxxxxxxxxxxxxxxx
From: "Steven A. Falco" <stevenfalco@xxxxxxxxx>
Date: Mon, 23 Aug 2021 11:41:09 -0400
In-reply-to: <f1969936-8a65-07af-abea-52fba7caf2c6@his.com>
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0

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@xxxxxxxxxxxxxxxxxxx
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp



_______________________________________________
Mailing list: https://launchpad.net/~kicad-developers
Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

References

ngspice library version
From: Steven A. Falco, 2021-08-23
Re: ngspice library version
From: Reece R. Pollack, 2021-08-23