Re: [Kicad-developers] eeschema depends on libngspice.so instead of libngspice.so.0?
Hi Stefan,
On 10/30/18 4:22 PM, Brüns, Stefan wrote:
[snip]
> Some inline comments:
>> diff --git a/eeschema/CMakeLists.txt b/eeschema/CMakeLists.txt
>> index e56f3c849..cd4d0d78e 100644
>> --- a/eeschema/CMakeLists.txt
>> +++ b/eeschema/CMakeLists.txt
>> @@ -7,6 +7,15 @@ add_definitions( -DEESCHEMA )
>> if( KICAD_SPICE )
>> set( INC_AFTER ${INC_AFTER} ${NGSPICE_INCLUDE_DIR} )
>> +
>> +# Find out the exact libngspice file name
>> +get_filename_component( NGSPICE_REAL_PATH "${NGSPICE_LIBRARY}" REALPATH
>> ) +get_filename_component( NGSPICE_LIB_FILE "${NGSPICE_REAL_PATH}" NAME
>> ) +
>> +set_property( SOURCE sim/ngspice.cpp
>> +APPEND PROPERTY COMPILE_DEFINITIONS
>> +NGSPICE_LIB_FILE="${NGSPICE_LIB_FILE}"
>> +)
>> endif()
>> include_directories( BEFORE ${INC_BEFORE} )
>> @@ -359,7 +368,15 @@ target_link_libraries( eeschema_kiface
>> legacy_gal
>> ${wxWidgets_LIBRARIES}
>> ${GDI_PLUS_LIBRARIES}
>> +${NGSPICE_LIBRARY}
>
> Likely duplicates the line below and probably breaks when NGSPICE_LIBRARY is
> unset
You are correct. I have noticed that as well and in the patch that has
been committed [1] NGSPICE_LIBRARY is linked only conditionally.
>> )
>>
>> +
>> +if( KICAD_SPICE )
>> +target_link_libraries( eeschema_kiface
>> +${NGSPICE_LIBRARY}
>> +)
>> +endif()
>
> This does not achieve what you likely intended. At least on openSUSE, kicad
> is
> linked with the as-needed linker flag, discarding any symbols and libraries
> not actually linked to.
Good point, thank you sharing the information. Do you know how smart is
the linker when the flag is enabled? Is it enough to call a function
from libngspice in a part of code that is actually never executed? Do we
need to create a dedicated dummy executable and install it as well?
Kind regards,
Orson
> Kind regards,
>
> Stefan
1.
https://git.launchpad.net/kicad/commit/?id=b445b0fab28f7dd41273801d06d7705215c57c0f
signature.asc
Description: OpenPGP digital signature
___
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] eeschema depends on libngspice.so instead of libngspice.so.0?
On Montag, 29. Oktober 2018 13:12:19 CET Maciej Sumiński wrote:
> Hi Carsten,
>
> On 10/27/18 11:50 AM, Carsten Schoenert wrote:
> [snip]
>
> > I'd really appreciate if the situation could be improved here somewhere
> > in the future!
>
> Can you check if the attached patch solves the problem? It still does
> not recognize the right libngspice file under Windows, but I need to
> know if it is a step in the right direction.
>
> Cheers,
> Orson
Some inline comments:
> diff --git a/eeschema/CMakeLists.txt b/eeschema/CMakeLists.txt
> index e56f3c849..cd4d0d78e 100644
> --- a/eeschema/CMakeLists.txt
> +++ b/eeschema/CMakeLists.txt
> @@ -7,6 +7,15 @@ add_definitions( -DEESCHEMA )
> if( KICAD_SPICE )
> set( INC_AFTER ${INC_AFTER} ${NGSPICE_INCLUDE_DIR} )
> +
> +# Find out the exact libngspice file name
> +get_filename_component( NGSPICE_REAL_PATH "${NGSPICE_LIBRARY}" REALPATH
> ) +get_filename_component( NGSPICE_LIB_FILE "${NGSPICE_REAL_PATH}" NAME
> ) +
> +set_property( SOURCE sim/ngspice.cpp
> +APPEND PROPERTY COMPILE_DEFINITIONS
> +NGSPICE_LIB_FILE="${NGSPICE_LIB_FILE}"
> +)
> endif()
> include_directories( BEFORE ${INC_BEFORE} )
> @@ -359,7 +368,15 @@ target_link_libraries( eeschema_kiface
> legacy_gal
> ${wxWidgets_LIBRARIES}
> ${GDI_PLUS_LIBRARIES}
> +${NGSPICE_LIBRARY}
Likely duplicates the line below and probably breaks when NGSPICE_LIBRARY is
unset
> )
>
> +
> +if( KICAD_SPICE )
> +target_link_libraries( eeschema_kiface
> +${NGSPICE_LIBRARY}
> +)
> +endif()
This does not achieve what you likely intended. At least on openSUSE, kicad is
linked with the as-needed linker flag, discarding any symbols and libraries
not actually linked to.
Kind regards,
Stefan
___
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] eeschema depends on libngspice.so instead of libngspice.so.0?
On 10/30/18 6:57 AM, Carsten Schoenert wrote: > Hello Orson, > > Am 29.10.18 um 21:06 schrieb Maciej Suminski: >>> works for me with current HEAD from today within Debian testing. >>> >> I should have said it earlier: one of the goals is to make dh_shlibdeps >> happy, but I do not use Debian so I have no way of verifying it. > > to check this I'd need to do a complete packaging with importing > tarballs etc. > For now I've "just" tested your patch against the current HEAD so the > build will work and also simulation task later if eeschema is opened. > dh_shlibdeps is going through the list of listed *.so.* files for a > binary and collecting the belonging packages. > > If ldd on eeschema is showing libngspice.so.0 then also sh_shlibdeps > will add the package libngspice0. This is something I haven't tested > yesterday (due a lack of time). Alright, then I think the new patch should be sufficient. Also, the shared library name is no longer hard-coded, but detected in CMake configuration step. I have just pushed the patch to the master and 5.0 branches. Cheers, Orson signature.asc Description: OpenPGP digital signature ___ 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] eeschema depends on libngspice.so instead of libngspice.so.0?
Hello Orson, Am 29.10.18 um 21:06 schrieb Maciej Suminski: >> works for me with current HEAD from today within Debian testing. >> > I should have said it earlier: one of the goals is to make dh_shlibdeps > happy, but I do not use Debian so I have no way of verifying it. to check this I'd need to do a complete packaging with importing tarballs etc. For now I've "just" tested your patch against the current HEAD so the build will work and also simulation task later if eeschema is opened. dh_shlibdeps is going through the list of listed *.so.* files for a binary and collecting the belonging packages. If ldd on eeschema is showing libngspice.so.0 then also sh_shlibdeps will add the package libngspice0. This is something I haven't tested yesterday (due a lack of time). -- Regards Carsten Schoenert ___ 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] eeschema depends on libngspice.so instead of libngspice.so.0?
On 10/29/18 6:38 PM, Carsten Schoenert wrote: > Hello Orson, > > Am 29.10.18 um 13:12 schrieb Maciej Sumiński: >> Can you check if the attached patch solves the problem? It still does >> not recognize the right libngspice file under Windows, but I need to >> know if it is a step in the right direction. > > works for me with current HEAD from today within Debian testing. > I should have said it earlier: one of the goals is to make dh_shlibdeps happy, but I do not use Debian so I have no way of verifying it. Cheers, Orson signature.asc Description: OpenPGP digital signature ___ 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] eeschema depends on libngspice.so instead of libngspice.so.0?
Hello Orson, Am 29.10.18 um 13:12 schrieb Maciej Sumiński: > Can you check if the attached patch solves the problem? It still does > not recognize the right libngspice file under Windows, but I need to > know if it is a step in the right direction. works for me with current HEAD from today within Debian testing. -- Regards Carsten Schoenert ___ 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] eeschema depends on libngspice.so instead of libngspice.so.0?
Hi Carsten,
On 10/27/18 11:50 AM, Carsten Schoenert wrote:
[snip]
> I'd really appreciate if the situation could be improved here somewhere
> in the future!
Can you check if the attached patch solves the problem? It still does
not recognize the right libngspice file under Windows, but I need to
know if it is a step in the right direction.
Cheers,
Orson
diff --git a/eeschema/CMakeLists.txt b/eeschema/CMakeLists.txt
index e56f3c849..cd4d0d78e 100644
--- a/eeschema/CMakeLists.txt
+++ b/eeschema/CMakeLists.txt
@@ -7,6 +7,15 @@ add_definitions( -DEESCHEMA )
if( KICAD_SPICE )
set( INC_AFTER ${INC_AFTER} ${NGSPICE_INCLUDE_DIR} )
+
+# Find out the exact libngspice file name
+get_filename_component( NGSPICE_REAL_PATH "${NGSPICE_LIBRARY}" REALPATH )
+get_filename_component( NGSPICE_LIB_FILE "${NGSPICE_REAL_PATH}" NAME )
+
+set_property( SOURCE sim/ngspice.cpp
+APPEND PROPERTY COMPILE_DEFINITIONS
+NGSPICE_LIB_FILE="${NGSPICE_LIB_FILE}"
+)
endif()
include_directories( BEFORE ${INC_BEFORE} )
@@ -359,7 +368,15 @@ target_link_libraries( eeschema_kiface
legacy_gal
${wxWidgets_LIBRARIES}
${GDI_PLUS_LIBRARIES}
+${NGSPICE_LIBRARY}
)
+
+if( KICAD_SPICE )
+target_link_libraries( eeschema_kiface
+${NGSPICE_LIBRARY}
+)
+endif()
+
set_target_properties( eeschema_kiface PROPERTIES
# Decorate OUTPUT_NAME with PREFIX and SUFFIX, creating something like
# _eeschema.so, _eeschema.dll, or _eeschema.kiface
diff --git a/eeschema/sim/ngspice.cpp b/eeschema/sim/ngspice.cpp
index 3b6e4dd74..3cfbf8b1f 100644
--- a/eeschema/sim/ngspice.cpp
+++ b/eeschema/sim/ngspice.cpp
@@ -293,7 +293,7 @@ void NGSPICE::init_dll()
const vector dllPaths = { "", "/mingw64/bin", "/mingw32/bin" };
#endif /* __WINDOWS__ */
#ifdef __WXMAC__
-wxFileName dllFile( "", "libngspice.0.dylib" );
+wxFileName dllFile( "", NGSPICE_LIB_FILE );
const vector dllPaths = {
GetOSXKicadUserDataDir() + "/PlugIns/ngspice",
GetOSXKicadMachineDataDir() + "/PlugIns/ngspice",
@@ -320,7 +320,7 @@ void NGSPICE::init_dll()
if( !m_dll.IsLoaded() ) // try also the system libraries
m_dll.Load( wxDynamicLibrary::CanonicalizeName( "ngspice" ) );
#else
-m_dll.Load("libngspice.so.0");
+m_dll.Load( NGSPICE_LIB_FILE );
#endif /* __WINDOWS || __WXMAC__ */
if( !m_dll.IsLoaded() )
signature.asc
Description: OpenPGP digital signature
___
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] eeschema depends on libngspice.so instead of libngspice.so.0?
Hi Wayne, On 10/27/18 11:08 PM, Wayne Stambaugh wrote: [snip] > Me too. This is why I had reservations about Stefan's patch. It is a > temporary fix at best. As soon as the libngspice so version number > changes, we will be in trouble. Even worse when one disto is still > using 0 and another distro uses 1. Pulling in the correct library > version at config/build time is the way to go. I considered Stefan's patch is a step in the right direction. Until now, we called for any libngspice.so, and that would be satisfied even if the API changes in libngspice.so.1. Anyway, I agree it is a temporary fix. Cheers, Orson signature.asc Description: OpenPGP digital signature ___ 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] eeschema depends on libngspice.so instead of libngspice.so.0?
On 10/27/2018 05:50 AM, Carsten Schoenert wrote: > Hi, > > Am 27.10.18 um 11:31 schrieb Maciej Suminski: >>> As a potential step into the right direction it would be good if >>> eeschema would search for libngspice.so.0 on Linux platforms. I can then >>> add a manual dependency on the library package instead on the -dev >>> package (which is gladly for ngspice rather small compared to other -dev >>> packages). >> >> Done, courtesy of Stefan who provided the patch. > > Yeah, I also already picked up this patch to fix the Debian build for > 5.0.1 a few hours ago. > > ... >> I know that Holger has already helped us a few times with ngspice >> support, I appreciate that. If I recall correctly, the issue has been >> discussed on forum.kicad.info, but indeed deserves a separate bug report >> with a minimal example. > > I'm sure Holger is willing to help. But yes, first the real problem > needs to be visible and clear. :) > We have found some missing header files within libngspice while writing > a small autopkgtest for Debian. Holger is knowing this and will have a > look at this. > >> In any case, we still need to keep the current approach until the fix is >> available in packages, meaning it will take time. Even then I would >> rather stay on the safe path and let us recover from errors by reloading >> the library. > > Sure, but dlopen used in this way has some downsides especially on > Linux. Like I also was trapped by this. There is a reason why we have > dh_shlibdeps in Debian, it saves so much times to collect the > dependencies automatically! > dlopen without a dependency is evil because people will normally see > just a segfault and don't know what is missing. And it's annoying and > time consuming on the user side to fix such problems. > > I'd really appreciate if the situation could be improved here somewhere > in the future! > Me too. This is why I had reservations about Stefan's patch. It is a temporary fix at best. As soon as the libngspice so version number changes, we will be in trouble. Even worse when one disto is still using 0 and another distro uses 1. Pulling in the correct library version at config/build time is the way to go. Cheers, Wayne ___ 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] eeschema depends on libngspice.so instead of libngspice.so.0?
Hi, Am 27.10.18 um 11:31 schrieb Maciej Suminski: >> As a potential step into the right direction it would be good if >> eeschema would search for libngspice.so.0 on Linux platforms. I can then >> add a manual dependency on the library package instead on the -dev >> package (which is gladly for ngspice rather small compared to other -dev >> packages). > > Done, courtesy of Stefan who provided the patch. Yeah, I also already picked up this patch to fix the Debian build for 5.0.1 a few hours ago. ... > I know that Holger has already helped us a few times with ngspice > support, I appreciate that. If I recall correctly, the issue has been > discussed on forum.kicad.info, but indeed deserves a separate bug report > with a minimal example. I'm sure Holger is willing to help. But yes, first the real problem needs to be visible and clear. :) We have found some missing header files within libngspice while writing a small autopkgtest for Debian. Holger is knowing this and will have a look at this. > In any case, we still need to keep the current approach until the fix is > available in packages, meaning it will take time. Even then I would > rather stay on the safe path and let us recover from errors by reloading > the library. Sure, but dlopen used in this way has some downsides especially on Linux. Like I also was trapped by this. There is a reason why we have dh_shlibdeps in Debian, it saves so much times to collect the dependencies automatically! dlopen without a dependency is evil because people will normally see just a segfault and don't know what is missing. And it's annoying and time consuming on the user side to fix such problems. I'd really appreciate if the situation could be improved here somewhere in the future! -- Regards Carsten Schoenert ___ 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] eeschema depends on libngspice.so instead of libngspice.so.0?
Hi Carsten, On 10/27/18 12:12 AM, Carsten Schoenert wrote: > Hello Orson, > > Am 26.10.18 um 22:30 schrieb Maciej Suminski: >> What about libngspice.so.0 symlink? Which package ships that? Anyway, it >> makes sense to request a particular version of the library in case the >> API changes in the future. > > Simon already has written some more technical explanation but to answer > your question here in detail, libspice.so.0 is provided (for the reason > Simon mentioned) in the plain library package in Debian, and this is > libngspice0. > > https://packages.debian.org/sid/amd64/libngspice0/filelist > >>> So looking manually at the binaries build from the kicad source by ldd I >>> can see a lot linked libraries but no library libngspice.so.0! Seems the >>> library is simply opened by dlopen. So that's the reason why the >>> packaging isn't adding a dependency on the package libngspice0. >> >> You are correct. The library used to be linked with eeschema, but we >> have faced problems that could be resolved only by reloading the >> library. I am afraid it has to stay this way for the time being. > > As a potential step into the right direction it would be good if > eeschema would search for libngspice.so.0 on Linux platforms. I can then > add a manual dependency on the library package instead on the -dev > package (which is gladly for ngspice rather small compared to other -dev > packages). Done, courtesy of Stefan who provided the patch. > nsgpice and especially the upstream packaging did from a Debain POV > really big steps forwards and I'm really happy that Holger from the > upstream team was really responsive to my questions and suggestions in > the past year! Without this it wouldn't be possible that KiCad in Debian > can now use ngspice from Debian main! > > So far I know Holger is also reading on this list, so I suggest to get > in contact with Holger Vogt about the problems you have or had in the > past. I'm quite sure Holger is willing to improve the situation if possible. I know that Holger has already helped us a few times with ngspice support, I appreciate that. If I recall correctly, the issue has been discussed on forum.kicad.info, but indeed deserves a separate bug report with a minimal example. In any case, we still need to keep the current approach until the fix is available in packages, meaning it will take time. Even then I would rather stay on the safe path and let us recover from errors by reloading the library. Cheers, Orson signature.asc Description: OpenPGP digital signature ___ 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] eeschema depends on libngspice.so instead of libngspice.so.0?
On 10/27/18 12:35 AM, Stefan Brüns wrote: > On Samstag, 27. Oktober 2018 00:12:21 CEST Carsten Schoenert wrote: >> As a potential step into the right direction it would be good if >> eeschema would search for libngspice.so.0 on Linux platforms. I can then >> add a manual dependency on the library package instead on the -dev >> package (which is gladly for ngspice rather small compared to other -dev >> packages). > > See > https://build.opensuse.org/package/view_file/electronics/kicad/0001-Use-fixed-version-for-libngspice.so.0.patch?expand=1 > for a patch ... Thank you Stefan, I have just pushed your patch to the master and 5.0 branches. Regards, Orson signature.asc Description: OpenPGP digital signature ___ 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] eeschema depends on libngspice.so instead of libngspice.so.0?
On Samstag, 27. Oktober 2018 00:12:21 CEST Carsten Schoenert wrote: > As a potential step into the right direction it would be good if > eeschema would search for libngspice.so.0 on Linux platforms. I can then > add a manual dependency on the library package instead on the -dev > package (which is gladly for ngspice rather small compared to other -dev > packages). See https://build.opensuse.org/package/view_file/electronics/kicad/0001-Use-fixed-version-for-libngspice.so.0.patch?expand=1 for a patch ... Kind regards, Stefan -- Stefan Brüns / Bergstraße 21 / 52062 Aachen home: +49 241 53809034 mobile: +49 151 50412019 signature.asc Description: This is a digitally signed message part. ___ 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] eeschema depends on libngspice.so instead of libngspice.so.0?
Hello Orson, Am 26.10.18 um 22:30 schrieb Maciej Suminski: > What about libngspice.so.0 symlink? Which package ships that? Anyway, it > makes sense to request a particular version of the library in case the > API changes in the future. Simon already has written some more technical explanation but to answer your question here in detail, libspice.so.0 is provided (for the reason Simon mentioned) in the plain library package in Debian, and this is libngspice0. https://packages.debian.org/sid/amd64/libngspice0/filelist >> So looking manually at the binaries build from the kicad source by ldd I >> can see a lot linked libraries but no library libngspice.so.0! Seems the >> library is simply opened by dlopen. So that's the reason why the >> packaging isn't adding a dependency on the package libngspice0. > > You are correct. The library used to be linked with eeschema, but we > have faced problems that could be resolved only by reloading the > library. I am afraid it has to stay this way for the time being. As a potential step into the right direction it would be good if eeschema would search for libngspice.so.0 on Linux platforms. I can then add a manual dependency on the library package instead on the -dev package (which is gladly for ngspice rather small compared to other -dev packages). nsgpice and especially the upstream packaging did from a Debain POV really big steps forwards and I'm really happy that Holger from the upstream team was really responsive to my questions and suggestions in the past year! Without this it wouldn't be possible that KiCad in Debian can now use ngspice from Debian main! So far I know Holger is also reading on this list, so I suggest to get in contact with Holger Vogt about the problems you have or had in the past. I'm quite sure Holger is willing to improve the situation if possible. -- Regards Carsten Schoenert ___ 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] eeschema depends on libngspice.so instead of libngspice.so.0?
On Freitag, 26. Oktober 2018 22:30:03 CEST Maciej Suminski wrote: > > $ dpkg -S /usr/lib/x86_64-linux-gnu/libngspice.so.0.0.0 > > > >> libngspice0:amd64: /usr/lib/x86_64-linux-gnu/libngspice.so.0.0.0 > > What about libngspice.so.0 symlink? Which package ships that? Anyway, it > makes sense to request a particular version of the library in case the > API changes in the future. > > > So looking manually at the binaries build from the kicad source by ldd I > > can see a lot linked libraries but no library libngspice.so.0! Seems the > > library is simply opened by dlopen. So that's the reason why the > > packaging isn't adding a dependency on the package libngspice0. > > You are correct. The library used to be linked with eeschema, but we > have faced problems that could be resolved only by reloading the > library. I am afraid it has to stay this way for the time being. The safest approach would be to create a shim library/module which links to libngspice.so.x at build time. Any API changes would be catched at build time and the soversion would be fixed afterwards. Shipping this module as part KiCad would also make automatic dependency resolution work again. Kind regards, Stefan -- Stefan Brüns / Bergstraße 21 / 52062 Aachen home: +49 241 53809034 mobile: +49 151 50412019 signature.asc Description: This is a digitally signed message part. ___ 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] eeschema depends on libngspice.so instead of libngspice.so.0?
Hi, On 26.10.2018 22:30, Maciej Suminski wrote: > What about libngspice.so.0 symlink? Which package ships that? Anyway, it > makes sense to request a particular version of the library in case the > API changes in the future. The .so.0 symlink is created from the SONAME field in the library. This is the correct way to reference a library by ABI. > You are correct. The library used to be linked with eeschema, but we > have faced problems that could be resolved only by reloading the > library. I am afraid it has to stay this way for the time being. The packaging tools look for hard dependencies between ELF objects. Anything else needs to be specified explicitly (which is totally allowed). Do the SPICE people know about the problems? Simon signature.asc Description: OpenPGP digital signature ___ 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] eeschema depends on libngspice.so instead of libngspice.so.0?
Hi Carsten, On 10/26/18 9:22 PM, Carsten Schoenert wrote: > Hi, > > I got a bug report [1] for KiCad in Debian testing/unstable because of a > not working ngspice based simulation in eeschema. > > I was first searching for the reason why the packaging isn't detecting > that the assumed library libngspice.so.0.0.0 was detected as a dependency. > The bugreporter stated that he is needed the package libnsgpice0-dev to > get eeschema working with simulation. So I tried around this information > and the reporter is right. If I start eeschema without this package > installed I get an error message that libngspice.so was not found. > > This is an error in my eyes because eeschema is not looking for the > needed library with the API version it's build against. As libngspice is > using a API version 0 the correct library to look for would be > libngspice.so.0 and not libngspice.so that is normally a symlink to the > most recent version of the library and only used while linking. > Thus we ship -dev packages in Debian with a symlink of a file libfoo.so > to full versioned named library. For libngspice0 this looks like this: > >> $ ls -l /usr/lib/x86_64-linux-gnu/libngspice.so* >> lrwxrwxrwx 1 root root 19 Okt 15 19:50 >> /usr/lib/x86_64-linux-gnu/libngspice.so -> libngspice.so.0.0.0 >> lrwxrwxrwx 1 root root 19 Okt 15 19:50 >> /usr/lib/x86_64-linux-gnu/libngspice.so.0 -> libngspice.so.0.0.0 >> -rw-r--r-- 1 root root 7091024 Okt 15 19:50 >> /usr/lib/x86_64-linux-gnu/libngspice.so.0.0.0 > >> $ dpkg -S /usr/lib/x86_64-linux-gnu/libngspice.so >> libngspice0-dev:amd64: /usr/lib/x86_64-linux-gnu/libngspice.so > $ dpkg -S /usr/lib/x86_64-linux-gnu/libngspice.so.0.0.0 >> libngspice0:amd64: /usr/lib/x86_64-linux-gnu/libngspice.so.0.0.0 What about libngspice.so.0 symlink? Which package ships that? Anyway, it makes sense to request a particular version of the library in case the API changes in the future. > So looking manually at the binaries build from the kicad source by ldd I > can see a lot linked libraries but no library libngspice.so.0! Seems the > library is simply opened by dlopen. So that's the reason why the > packaging isn't adding a dependency on the package libngspice0. You are correct. The library used to be linked with eeschema, but we have faced problems that could be resolved only by reloading the library. I am afraid it has to stay this way for the time being. Regards, Orson > [1] https:/bugs.debian.org/911965 > signature.asc Description: OpenPGP digital signature ___ 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
[Kicad-developers] eeschema depends on libngspice.so instead of libngspice.so.0?
Hi, I got a bug report [1] for KiCad in Debian testing/unstable because of a not working ngspice based simulation in eeschema. I was first searching for the reason why the packaging isn't detecting that the assumed library libngspice.so.0.0.0 was detected as a dependency. The bugreporter stated that he is needed the package libnsgpice0-dev to get eeschema working with simulation. So I tried around this information and the reporter is right. If I start eeschema without this package installed I get an error message that libngspice.so was not found. This is an error in my eyes because eeschema is not looking for the needed library with the API version it's build against. As libngspice is using a API version 0 the correct library to look for would be libngspice.so.0 and not libngspice.so that is normally a symlink to the most recent version of the library and only used while linking. Thus we ship -dev packages in Debian with a symlink of a file libfoo.so to full versioned named library. For libngspice0 this looks like this: > $ ls -l /usr/lib/x86_64-linux-gnu/libngspice.so* > lrwxrwxrwx 1 root root 19 Okt 15 19:50 > /usr/lib/x86_64-linux-gnu/libngspice.so -> libngspice.so.0.0.0 > lrwxrwxrwx 1 root root 19 Okt 15 19:50 > /usr/lib/x86_64-linux-gnu/libngspice.so.0 -> libngspice.so.0.0.0 > -rw-r--r-- 1 root root 7091024 Okt 15 19:50 > /usr/lib/x86_64-linux-gnu/libngspice.so.0.0.0 > $ dpkg -S /usr/lib/x86_64-linux-gnu/libngspice.so > libngspice0-dev:amd64: /usr/lib/x86_64-linux-gnu/libngspice.so $ dpkg -S /usr/lib/x86_64-linux-gnu/libngspice.so.0.0.0 > libngspice0:amd64: /usr/lib/x86_64-linux-gnu/libngspice.so.0.0.0 So looking manually at the binaries build from the kicad source by ldd I can see a lot linked libraries but no library libngspice.so.0! Seems the library is simply opened by dlopen. So that's the reason why the packaging isn't adding a dependency on the package libngspice0. [1] https:/bugs.debian.org/911965 -- Regards Carsten Schoenert ___ 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
