kicad-developers team mailing list archive

["Steven A. Falco" <stevenfalco@xxxxxxxxx>]

Comments below.

On 8/23/21 11:45 AM, Reece R. Pollack wrote:
> It doesn't matter what file name is used for the .so when linking an application. The SONAME of the library is embedded in the library file itself, and is extracted from the library when the application is linked.
>
> Does the Fedora package that provides libngspice create the appropriate symlink "libngspice.so.0" to the actual image file "libngspice.so.0.0.1"?

Here are the links on a failing machine.  They look fine.

$ ls -l /lib64 | grep libngspice*
lrwxrwxrwx    1 root root        19 Aug  9 00:32 libngspice.so.0 -> libngspice.so.0.0.1*
lrwxrwxrwx    1 root root        19 Aug  9 00:32 libngspice.so -> libngspice.so.0.0.1*
-rwxr-xr-x    1 root root  10442176 Aug  9 00:51 libngspice.so.0.0.1*

> What does ldd show on the failing systems (not your system)? The string to the right of the "=>" is the name of the file that satisfies the requirement /on that system/ and is determined by ldd at the time ldd is run. If this shows "not found", then there is a libngspice configuration problem on that system.

ldd reports that /lib64/libngspice.so.0 will satisfy the dependency and is present on the system.  However, that is not how KiCAD actually loads the library, as I'll discuss below.

$ ldd _eeschema.kiface | grep spice
        libngspice.so.0 => /lib64/libngspice.so.0 (0x00007f075e3f7000)

> My guess is that the symlinks are installed as part of the development package for libngspice and not as part of the base package that provides the library itself. This is a common packaging error.
The problem is that KiCAD manually tries to load the library, using a call to m_dll.Load((), based on the NGSPICE_DLL_FILE variable, rather than using the normal linking mechanism.

Please see NGSPICE::init_dll() around line 278 in eeschema/sim/ngspice.cpp.  Specifically, the #else clause at line 324 has  m_dll.Load( NGSPICE_DLL_FILE );.  Unfortunately, at the time the build was made, the build system set NGSPICE_DLL_FILE to libngspice.so.0.0.0, because that was the current version at the time of the build.  But that version is no longer present on the failing system; now it has libngspice.so.0.0.1 instead.

The libngspice.so.0.0.0 version is therefore hard compiled into the program, and no links can fix that.

Thus, for KiCAD to be able to manually load the library, we need to change the way the NGSPICE_DLL_FILE variable is computed.  It needs to be set to the more generic libngspice.so.0 rather than libngspice.so.0.0.0 or libngspice.so.0.0.1, because the latter are too specific, and won't necessarily survive a system upgrade.

	Steve

> -Reece
>
> On 8/23/21 11:06 AM, Steven A. Falco wrote:
> > I've done a bit of digging.  According to ldd, the desired version is appropriate, just specifying the first digit of the version info:
> >
> > libngspice.so.0 => /lib64/libngspice.so.0 (0x00007f70913de000)
> >
> > However, according to eeschema_kiface.dir/build.make we have -DNGSPICE_DLL_FILE=\"libngspice.so.0.0.1\" as shown in this excerpt:
> >
> > cd /builddir/build/BUILD/kicad-5.1.10/x86_64-redhat-linux-gnu/eeschema && /usr/bin/g++ $(CXX_DEFINES) -DNGSPICE_DLL_FILE=\"libngspice.so.0.0.1\" $(CXX_INCLUDES) $(CXX_FLAGS) -MD -MT eeschema/CMakeFiles/eeschema_kiface.dir/sim/ngspice.cpp.o -MF CMakeFiles/eeschema_kiface.dir/sim/ngspice.cpp.o.d -o CMakeFiles/eeschema_kiface.dir/sim/ngspice.cpp.o -c /builddir/build/BUILD/kicad-5.1.10/eeschema/sim/ngspice.cpp
> >
> > Since eeschema/sim/ngspice.cpp explicitly uses the NGSPICE_DLL_FILE variable to load the DLL, that is apparently why the more general ldd version is not used.
> >
> > eeschema/sim/ngspice.cpp:    m_dll.Load( NGSPICE_DLL_FILE );
> >
> > So it seems the fix would be to truncate NGSPICE_DLL_FILE to remove the MAJOR.MINOR component and just have -DNGSPICE_DLL_FILE=\"libngspice.so.0\"
> >
> >     Steve
> >
> > 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