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
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
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
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
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
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
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
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
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
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
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,
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
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:
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
14 matches
Mail list logo
