kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxx>]

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