kicad-developers team mailing list archive

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

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