Re: [Kicad-developers] libngspice versioning by libtool
Am 02.08.21 um 13:11 schrieb Ian McInerney: > 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. Hmm, yes I can vaguely remember... > carsten@x260:~/gitprojects/kicad-upstream/kicad/build [5.1] $ LANG= git st > On branch 5.1 > Your branch is up to date with 'origin/5.1'. > > Untracked files: > (use "git add ..." to include in what will be committed) > ../eeschema/sch_text_help_md.h > ../pcbnew/dialogs/panel_setup_rules_help_md.h Would be nice if these files can be removed out of the way while the cmake run is done. The current behavior is a bit annoying. I'm quite sure this will come up regularly. :) -- Regards Carsten ___ 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
Re: [Kicad-developers] libngspice versioning by libtool
On Mon, Aug 2, 2021 at 11:32 AM Carsten Schoenert 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
Re: [Kicad-developers] libngspice versioning by libtool
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 ___ 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
Re: [Kicad-developers] libngspice versioning by libtool
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. 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? Holger ___ 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
Re: [Kicad-developers] libngspice versioning by libtool
Am 30.07.21 um 14:53 schrieb Holger Vogt: [snip] > Ah, and what is the versioning now? The API has not changed, it was > however not described correctly in sharedspice.h, which now (ngspice-35) > will be fixed. So you have changed the internal behavior of one or more symbols? This is of course a modification of the API. From the commit message that I wrote for ngspice: > Existing symbols behave now different or existing symbols were removed. > > --> Increase 'current' by 1, set 'revision' to 0, set 'age' to 0 > (c+1,r=0,a=0) > !!!Note!!! > The ABI version is also affected by this (needs a bump too, the library > isn't backward compatible any more. So libngspice normally would need to get a bump of the current version. Existing source projects aren't able to get built against the new library version without the modifications to the source and would fail already at configure time because the API version of the new library isn't matching. Now the fun begins because also the header files would need to go into a new different folder than the old ones in most of the cases. You can try to avoid such hassle by introducing a wrapper function that is basically the old symbol call that is internally redirecting to the new symbol. By this you "only" introduce a new symbol and from an outside view the library is behaving the same as before. That's what other libraries always try to do because introducing a new API version has a lot of necessary required following steps, especially outside the library. If ever possible this is to get avoided. -- Regards Carsten ___ 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
Re: [Kicad-developers] libngspice versioning by libtool
The current HEAD in branch 5.1. is getting configured successful but is
failing while compiling with this error message with then updated
packages of libngspice0 and libngspice0-dev:
[ 87%] Building CXX object
pcbnew/CMakeFiles/pcbnew_kiface_objects.dir/dialogs/dialog_pns_length_tuning_settings.cpp.o
[ 87%] Building CXX object
eeschema/CMakeFiles/eeschema_kiface.dir/sim/netlist_exporter_pspice_sim.cpp.o
[ 87%] Building CXX object
eeschema/CMakeFiles/eeschema_kiface.dir/sim/ngspice.cpp.o
[ 87%] Building CXX object
pcbnew/CMakeFiles/pcbnew_kiface_objects.dir/dialogs/dialog_pns_length_tuning_settings_base.cpp.o
/home/carsten/gitprojects/kicad-upstream/kicad/eeschema/sim/ngspice.cpp:341:47:
error: cannot initialize a parameter of type 'ControlledExit *' (aka 'int
(*)(int, int, int, int, void *)') with an rvalue of type 'int (*)(int, bool,
bool, int, void *)': type mismatch at 2nd parameter ('NG_BOOL' (aka 'int') vs
'bool')
m_ngSpice_Init( , , , NULL, NULL,
, this );
^
1 error generated.
make[2]: *** [eeschema/CMakeFiles/eeschema_kiface.dir/build.make:2588:
eeschema/CMakeFiles/eeschema_kiface.dir/sim/ngspice.cpp.o] Fehler 1
make[2]: *** Es wird auf noch nicht beendete Prozesse gewartet
Looks currently to me if something needs to get cherry picked from
master into 5.1. At least I can remembering that some fixing around this
was already happen in the past.
Boolean data have always been of type 'int' in spice3f5 and ngspice.
Unfortunately their type internally was coined 'bool' and then typedefed
to int.
When I started shared ngspice, I inadvertently have named the boolean
values as 'bool' in sharedspice.h as well, even if they were of type
'int'. In a C++ environment this may be of evil because bool is a
(fixed) type in C++, taking one byte, whereas 'int' takes four bytes.
So I have made a correction in sharedspice.h, calling the boolean type
NG_BOOL instead of 'bool' and typedefed it to 'int'.
This has to be reflected in the calling program as well.
Ah, and what is the versioning now? The API has not changed, it was
however not described correctly in sharedspice.h, which now (ngspice-35)
will be fixed.
___
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
Re: [Kicad-developers] libngspice versioning by libtool
Hi again,
Am 29.07.21 um 10:29 schrieb Carsten Schoenert:
> From a quick built of ngspice (branch pre-master with current HEAD) I
> can run a KiCad 5.99 without issues with a new version of
> libngspice0.so.0.0.1.
>
> Will do further testing this.
to shorten the story, I can use any existing old version of KiCad 5.1.9
.10 and also .99 together with an updated package libngspice to
pre-master 35 of ngspice within a Debian testing. Al my testing did
happen on Debian testing.
I could also configure, built and use successful some old tree of KiCad
5.99 to together with a new library of libngspice.so.0.0.1.
The current HEAD (4633840) is able to get a target built configured, but
breaks later with some non libngspice related failure.
> [ 42%] Building CXX object
> eeschema/CMakeFiles/eeschema_kiface_objects.dir/dialogs/dialog_print_using_printer.cpp.o
> [ 42%] Building CXX object
> common/CMakeFiles/pcbcommon.dir/__/pcbnew/kicad_clipboard.cpp.o
> [ 42%] Building CXX object
> common/CMakeFiles/pcbcommon.dir/__/pcbnew/netlist_reader/kicad_netlist_reader.cpp.o
> [ 42%] Building CXX object
> eeschema/CMakeFiles/eeschema_kiface_objects.dir/dialogs/dialog_print_using_printer_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
> [ 42%] Building CXX object
> eeschema/CMakeFiles/eeschema_kiface_objects.dir/dialogs/dialog_rescue_each.cpp.o
> make[1]: *** [CMakeFiles/Makefile2:2983: common/CMakeFiles/pcbcommon.dir/all]
> Fehler 2
> make[1]: *** Es wird auf noch nicht beendete Prozesse gewartet
The current HEAD in branch 5.1. is getting configured successful but is
failing while compiling with this error message with then updated
packages of libngspice0 and libngspice0-dev:
> [ 87%] Building CXX object
> pcbnew/CMakeFiles/pcbnew_kiface_objects.dir/dialogs/dialog_pns_length_tuning_settings.cpp.o
> [ 87%] Building CXX object
> eeschema/CMakeFiles/eeschema_kiface.dir/sim/netlist_exporter_pspice_sim.cpp.o
> [ 87%] Building CXX object
> eeschema/CMakeFiles/eeschema_kiface.dir/sim/ngspice.cpp.o
> [ 87%] Building CXX object
> pcbnew/CMakeFiles/pcbnew_kiface_objects.dir/dialogs/dialog_pns_length_tuning_settings_base.cpp.o
> /home/carsten/gitprojects/kicad-upstream/kicad/eeschema/sim/ngspice.cpp:341:47:
> error: cannot initialize a parameter of type 'ControlledExit *' (aka 'int
> (*)(int, int, int, int, void *)') with an rvalue of type 'int (*)(int, bool,
> bool, int, void *)': type mismatch at 2nd parameter ('NG_BOOL' (aka 'int') vs
> 'bool')
> m_ngSpice_Init( , , , NULL, NULL,
> , this );
> ^
> 1 error generated.
> make[2]: *** [eeschema/CMakeFiles/eeschema_kiface.dir/build.make:2588:
> eeschema/CMakeFiles/eeschema_kiface.dir/sim/ngspice.cpp.o] Fehler 1
> make[2]: *** Es wird auf noch nicht beendete Prozesse gewartet
Looks currently to me if something needs to get cherry picked from
master into 5.1. At least I can remembering that some fixing around this
was already happen in the past.
--
Regards
Carsten
___
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
Re: [Kicad-developers] libngspice versioning by libtool
Hi, Am 28.07.21 um 14:14 schrieb Ian McInerney: > Depending on how the OpenSUSE build system si setup, a prebuilt version > from their repository might not work with a library with a different > version. Many build systems for Linux packages will encode a dependency > on a specific version of the shared library, which is included in the > filename. When that changes (called an SONAME bump), the dependent > packages must be rebuilt to pickup the new SONAME. this is only true if the current version (aka API version) has changed. As long the SO version is the same a rebuild package with a greater version will get built. >From a quick built of ngspice (branch pre-master with current HEAD) I can run a KiCad 5.99 without issues with a new version of libngspice0.so.0.0.1. Will do further testing this. -- Regards Carsten ___ 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
Re: [Kicad-developers] libngspice versioning by libtool
Depending on how the OpenSUSE build system si setup, a prebuilt version from their repository might not work with a library with a different version. Many build systems for Linux packages will encode a dependency on a specific version of the shared library, which is included in the filename. When that changes (called an SONAME bump), the dependent packages must be rebuilt to pickup the new SONAME. Try building KiCad with the new ngspice library and see what happens. I think that should pick up your new version and work properly. -Ian On Wed, Jul 28, 2021 at 8:23 AM Holger Vogt wrote: > Pre-built 5.1.10, installed from openSUSE Leap 15.3 Electronics > repository, delivered with ngspice-34. > > I have opened an issue at > https://gitlab.com/kicad/code/kicad/-/issues/8878 > > If this is a non-issue (hopefully) and future 5.1.11 and 5.99 will not > have any problems, I would be happy to add versioning to ngspice shared > library. > > ___ > 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
Re: [Kicad-developers] libngspice versioning by libtool
Pre-built 5.1.10, installed from openSUSE Leap 15.3 Electronics repository, delivered with ngspice-34. I have opened an issue at https://gitlab.com/kicad/code/kicad/-/issues/8878 If this is a non-issue (hopefully) and future 5.1.11 and 5.99 will not have any problems, I would be happy to add versioning to ngspice shared library. ___ 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
Re: [Kicad-developers] libngspice versioning by libtool
At this point, KiCad isn't defining a version requirement on ngspice, so any way you choose to do it would work for us. As for the issue compiling earlier, did you try to use your new ngspice build with a pre-built KiCad version or did you build that KiCad version yourself? -Ian On Tue, Jul 27, 2021 at 7:13 PM Holger Vogt wrote: > Carsten, > > it is not about what I should do, but what the KiCad devs should do to > allow me adding versioning to shared ngspice. I will add versioning if > it is aknowledged by KiCad/Eeschema. > > Holger > > > ___ > 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
Re: [Kicad-developers] libngspice versioning by libtool
Am 27.07.21 um 20:12 schrieb Holger Vogt: > Carsten, > > it is not about what I should do, but what the KiCad devs should do to > allow me adding versioning to shared ngspice. I will add versioning if > it is aknowledged by KiCad/Eeschema. That's not the question in my eyes. It's not something that you need to be allowed to do. In my eyes it the responsibility of every maintainer to do it right. It's really hard to package some libraries because we need to do a lot of extra work and tricks so the user can use the library in the end. Serving a proper versioned library is the only right way in the long run. What non versioned work can produce is better than ever visible in the Windows world. Every peace of software brings in it's own bundled version of the same peace of software because it's just a hassle to use system wide installed libraries even if they are from M$ itself. I thought this topic was already clear. There is now an extra variable in sharedspice.h that the Windows world can rely on. -- Regards Carsten ___ 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
Re: [Kicad-developers] libngspice versioning by libtool
Carsten, it is not about what I should do, but what the KiCad devs should do to allow me adding versioning to shared ngspice. I will add versioning if it is aknowledged by KiCad/Eeschema. Holger ___ 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
Re: [Kicad-developers] libngspice versioning by libtool
Hello Holger, Am 27.07.21 um 14:03 schrieb Holger Vogt: > So what would be the correct action? > > When I compile ngspice, I get (besides libngspice.so.0.0.0 or > libngspice.so.0.0.1) two aliases libngspice.so.0 and libngspice.so. What > would be the correct version to link to? there is nothing you need to do here (and you shouldn't do anything here!), the correct linking of all relevant files is always done by libtool as part of the intended versioning schema inside libtool based on idea of ELF Symbol Versioning. For those who are not really familiar with this I suggest to read some old written stuff by Ulrich Drepper that explains some internals. https://akkadia.org/drepper/symbol-versioning libtool naming, something you need to remember every time if working with the versioning for libraries. libtool uses three elements to give a library a version. 1. Current (== API version) 2. Revision (== iteration of the library) 3. Age (== iteration on the availability of new symbols) This built currently the following library for ngspice with it's full name as all these elements using 0 for a version as nothing as a version is given to the libtool call: libngspice.so.0.0.0 And this is the schema that libtool is using to create the full name. current ---\ /--- revision | | shared object file --\ | | libngspice.so.0.0.0 | | library name --/ | age -/ Looking at the output of libtool we see currently this if ngspice is built with --with-ngshared: > $ ls -l /usr/lib/x86_64-linux-gnu/libngspice* > lrwxrwxrwx 1 root root 19 31. Jan 12:43 > /usr/lib/x86_64-linux-gnu/libngspice.so -> libngspice.so.0.0.0 > lrwxrwxrwx 1 root root 19 31. Jan 12:43 > /usr/lib/x86_64-linux-gnu/libngspice.so.0 -> libngspice.so.0.0.0 > -rw-r--r-- 1 root root 7340384 31. Jan 12:43 > /usr/lib/x86_64-linux-gnu/libngspice.so.0.0.0 We see two links, the first one is the basic library name that is pointing to the full version. The other link is using an additional number which is simply '0' which is also pointing to the full name. This means these two links can only exist one time, but we can have multiple full named libraries installed, the trick is the symlinking here to point to the the most recent version normally. Going back to the second link (libngspice.so.0 -> libngspice.so.0.0.0). You might already see what this '0' means here, it's the number of 'Current' or also known as the API version. Greater means breaking (non backward compatible) changes as also the API has changed by this. This is happen e.g. if the maintainer has removed symbols from the library for hopefully good reasons. Now we are already by the compatibility of a library. A library is backwards compatible if in a newer version all existing symbols are still available and the behavior of the symbols doesn't have changed. By this all old and existing applications can also use a newer library version. And this is visible by the link of libngspice.so.0, the number '0' means here exactly this. What's if the maintainer has just done bug fixing or improved the performance of the library? No new symbols were added and no existing symbols have been modified or removed! For this the new version needs to increase the revision. We would move on from libngspice.so.0.0.0 tolibngspice.so.0.0.1 (and so on) And now the new library has become some new symbols, all existing symbols stays the same as before. Now the age needs to get increased and the revision falls back to 0. For libngspice this would look like this. libngspice.so.0.0.1 will go tolibngspice.so.0.1.0 And now the most intrusive thing that can happen, the new library has at least one of there symbols removed. Remember, the library isn't backwards compatible any longer! The API version has changed! Current will get increased and revison and also age will get reset to '0'. libngspice.so.0.1.0 will go tolibngspice.so.1.0.0 And libtool will create a new link named libngspice.so.1 pointing to the new full named file. If you doing this for the first time it's all a bit confusing as you can see this all has nothing to do with semver. But once you have understand the idea it's quite obvious what needs to be done. PS: I'm far away from being an expert in such things! Forgive me if somethings isn't fully correct explained. -- Regards Carsten ___ 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
