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"?
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.
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.
-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@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
