Thanks for the pointer to the issue, Holger.
I've added a comment describing the root cause in detail, along with a proposed
patch for discussion. The patch would have to be cleaned up a bit, and tested
with Windows and Mac by devs who have access to those build environments. Or a
different
No new contribution, but just for completeness:
https://gitlab.com/kicad/code/kicad/-/issues/8878
https://lists.launchpad.net/kicad-developers/msg45289.html
Holger
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-develope
Attached is an ugly patch that would correct the problem I reported, at least
on Linux. Hopefully, someone better versed in CMake than I can come up with
something less hacky. Also, I don't know if my ugly patch would break other OS
builds. Thus, this patch is just to stimulate discussion -
Please look at eeschema/CMakeLists.txt around line 9. We have:
if( KICAD_SPICE )
set( INC_AFTER ${INC_AFTER} ${NGSPICE_INCLUDE_DIR} )
# Find out the exact libngspice file name
get_filename_component( NGSPICE_DLL_REALPATH "${NGSPICE_DLL}" REALPATH )
get_filename_component( NGSPIC
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 pa
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
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
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, us
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 (0x7f70913de000)
However, according to eeschema_kiface.dir/build.make we have
-DNGSPICE_DLL_FILE=\"libngspice.so
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 expec
10 matches
Mail list logo
