kicad-developers team mailing list archive

[Carsten Schoenert <c.schoenert@xxxxxxxxxxx>]

Hi Holger,

Am 31.07.21 um 15:52 schrieb Holger Vogt:
> Hello Carsten,
> 
> there are two thing now open:
> 
> I have made an update to ngspice in branch pre-master:
> Now all boolean symbols transferred over the ABI are of true boolean 
> type. So the interfacing from any caller does not need to be changed, 
> your compile should then (hopefully) finish successfully.

today I was able to have a look again. Thanks for patience.

I've rebuilt a new snapshot of Debian packages for ngspice and installed
the libngspice specific packages for further testing.

The build of the current master of kicad is still failing with the same
error message as previously. This isn't ngspice related I guess.

> [ 42%] Building CXX object common/CMakeFiles/pcbcommon.dir/__/pcbnew/netlist_reader/kicad_netlist_reader.cpp.o
> [ 42%] Building CXX object bitmap2component/CMakeFiles/bitmap2component.dir/bitmap2component.cpp.o
> [ 42%] Building CXX object eeschema/CMakeFiles/eeschema_kiface_objects.dir/dialogs/dialog_netlist_base.cpp.o
> /home/carsten/gitprojects/kicad-upstream/kicad/pcbnew/netlist_reader/kicad_netlist_reader.cpp:241:22: error: use of undeclared identifier 'T_pinfunction'
>                 case T_pinfunction:
>                      ^
> /home/carsten/gitprojects/kicad-upstream/kicad/pcbnew/netlist_reader/kicad_netlist_reader.cpp:247:22: error: use of undeclared identifier 'T_pintype'
>                 case T_pintype:
>                      ^
> /home/carsten/gitprojects/kicad-upstream/kicad/pcbnew/netlist_reader/kicad_netlist_reader.cpp:371:14: error: use of undeclared identifier 'T_property'
>         case T_property:
>              ^
> 3 errors generated.
> make[2]: *** [common/CMakeFiles/pcbcommon.dir/build.make:689: common/CMakeFiles/pcbcommon.dir/__/pcbnew/netlist_reader/kicad_netlist_reader.cpp.o] Fehler 1
> make[2]: *** Es wird auf noch nicht beendete Prozesse gewartet...


The build of the current HEAD in the branch 5.1 (configured the same way
as the master branch) successes now again with ngspice c4470db.
And so far KiCad is also usable.


> Concerning loading the ngspice shared library:
> With the help of reading the commit
> https://gitlab.com/kicad/code/kicad/-/commit/b445b0fab28f7dd41273801d06d7705215c57c0f
> the procedure seems to be:
> With cmake function get_filename_component() at compile time KiCad 
> detects a path to ngspice and hard-codes it in NGSPICE_DLL_FILE.
> This variable then is used to load ngspice dynamically at runtime. So 
> everything depends what string one finds in NGSPICE_DLL_FILE (ngspice.cpp).
> 
> Unfortunately I have not been able to compile KiCad so far 
> (wxPython/Phoenix seems to be not yet available in openSUSE Leap 15.3). 
> So, Carsten, if you can compile, could you have a look at the contents 
> of NGSPICE_DLL_FILE?

I'm not that familiar with CMake and there are probably some differences
need to be done between the three operating systems in the end as they
behave differently. So I think I can't say really helpful things in that
matter. I'd use at least different names for the variable that is
pointing to the ngspice specific library, we usually talk about "shared
objects" (SO) within Linux/GNU and dynamic linked libraries (DLL) on the
Windows side. I've no idea how MacOS is calling these files, maybe also
shared objects.

For the Linux world it would be needed to link against the name
libngspice.so.0 currently as this is the API version that is required,
but before the CMake checking needs to prove that the current minimal
required version is available on the system. That's currently c:a:r
0.0.x if the set of available symbols is enough.

This can be done by using pkg-config (pkg-config --modversion ngspice).

The build configuration of ngspice is currently using the package
version that is abstracted by autoconf and configure.ac (currently this
is 35) for adding a version number into ngspice.pc.
There is no specific requirement which version number has to be used
here, some packages (probably most of it) simply use a semver based
package version, some packages using here the library SO version. Both
is usable.

Package maintainers need to ensure later that the required version is
defined correctly for the packaged KiCad application.

I think the most important thing on this is that the maintainers of
KiCad know what CMake needs to check at build time. If this is simply a
check that Ngspice >= 35 is required than this is all to be done I think.

Using dlopen should be the right things in Linux systems, but this is
used all the times yet so far I know.

-- 
Regards
Carsten