kicad-developers team mailing list archive
-
kicad-developers team
-
Mailing list archive
-
Message #45291
Re: libngspice versioning by libtool
On Mon, Aug 2, 2021 at 11:32 AM Carsten Schoenert <c.schoenert@xxxxxxxxxxx>
wrote:
> 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.
>
> This error has been discussed on the list before, but basically it is
caused by using the same source tree and trying to build both 5.1 and
master by switching back and forth between them using git checkout. There
were several changes to where auto-generated header files are located
between the two, so if you switch between the two it can get the wrong
header files - specifically this error is it using the 5.1 header file
which was created in the source tree in the master branch build instead of
the new one for the master branch that was created in the build directory.
One way to fix this is to use different trees for the two, or remove the
ignored generated files.
-Ian
>
> > 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
>
> _______________________________________________
> 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
>
Follow ups
References
-
old ngspice in 599 macOS nightly
From: Holger Vogt, 2021-07-21
-
Re: old ngspice in 599 macOS nightly
From: Holger Vogt, 2021-07-22
-
Re: old ngspice in 599 macOS nightly
From: Adam Wolf, 2021-07-22
-
Re: old ngspice in 599 macOS nightly
From: Holger Vogt, 2021-07-22
-
Re: old ngspice in 599 macOS nightly
From: Carsten Schoenert, 2021-07-22
-
Re: old ngspice in 599 macOS nightly
From: Holger Vogt, 2021-07-24
-
Re: old ngspice in 599 macOS nightly
From: Carsten Schoenert, 2021-07-24
-
Re: old ngspice in 599 macOS nightly
From: Holger Vogt, 2021-07-27
-
Re: libngspice versioning by libtool
From: Carsten Schoenert, 2021-07-27
-
Re: libngspice versioning by libtool
From: Holger Vogt, 2021-07-27
-
Re: libngspice versioning by libtool
From: Ian McInerney, 2021-07-27
-
Re: libngspice versioning by libtool
From: Holger Vogt, 2021-07-28
-
Re: libngspice versioning by libtool
From: Ian McInerney, 2021-07-28
-
Re: libngspice versioning by libtool
From: Carsten Schoenert, 2021-07-29
-
Re: libngspice versioning by libtool
From: Carsten Schoenert, 2021-07-29
-
Re: libngspice versioning by libtool
From: Holger Vogt, 2021-07-30
-
Re: libngspice versioning by libtool
From: Carsten Schoenert, 2021-07-30
-
Re: libngspice versioning by libtool
From: Holger Vogt, 2021-07-31
-
Re: libngspice versioning by libtool
From: Carsten Schoenert, 2021-08-02