Question: Are there supposed to be some ngspice include files, and could you please
tell me what they are, so I have some idea of what I am trying to fix.

Prep for trying to compile kicad.

I got ngspice-34, compiled from slackbuilds, and installed.

Installing the package, I got some ngspice libraries:

/usr/lib/libngspice.so -->
/usr/lib/libngspice.so.0 -->
/usr/lib/libngspice.so.0.0.0
-- size 7792820
-- the version of 0.0.0 is a bit unusual
-- file says it is ELF ...

/usr/lib/ngspice/ containing some *.cm files

I have started ngspice and looked at its help, so ngspice does run.

------
I am trying to compile kicad 5.1.5, using slackbuild.
It complains that ngspice is not there.

Kicad build cannot find ngspice.
Kicad messages complains that most ngspice packages do not install the libraries.
From one of the messages, it seems What kicad checks is an include file,
but I have not dove into debugging that yet.

------
The ngspice package has installed (among the docs and libs) one include file :

/usr/include/config.h
-- which is a configure output file.
Not very useful for users.

config.h
/* src/include/ngspice/config.h Generated from config.h by configure. */
Content is #defines, and #undefs, some commented out ... it is configure output.

This include file is useless. I think that the build got the wrong include directory.

------

There are too many variations of problems, and the dependency hell, to investigate this by hit and miss trying guesses.

Slackbuild bug reporting leaves alot to be desired. I am supposed to search their entire email to see
if this has been reported before. There is no search function on that page, and the web search engines have not found anything, .. which has alot of assumptions there too.

Are we 32 or 64bit? It's a 32bit ngspice you have there.

Personally I did a project in 2013/2014 and found LTspice under wine to be the best option. You have to install multilib as most windows programs are 32bit.

I did this stuff. Kicad is a pain, but it compiled. It's very good - mind you, I can't speak for the auto router, because I routed manually. I also used dia(grams for flowcharts?) and drawtiming (timing diagrams) which are clunky but efficient. I compiled them all, and used no slackbuilds. Just build them, and post problems. Slackware folks just don't use this stuff. In fact, nobody does really. It's all VHDL these days.

Auto routers generally have a poor reputation. I had my University project doing 250Mhz, and when I threw that figure out, all the tutors ran away because everyone who tried HF in their projects came unstuck(over autoroute it seems). I had routed many, with skills honed on a light box. One guy eventually took it because as he said: "I'll learn something." He certainly did. You can imagine how I rate that institution…

"I was able to finally build 5.1.9 from Ponce Slackbuild after rebuilding wxPython4 and wxGTK3 a couple of times."

From https://www.linuxquestions.org/quest...-a-4175690031/

And "The Nightmare Thread" https://www.linuxquestions.org/quest...or-4175689368/


Bookmarked as KiCad may come in handy for some upcoming projects here.

What a cool software kit!

Yes, I run 32 bit system. It is Windows free, I don't run Wine.

I read both of those LinuxQuestions posts before posting my question. They do not address the specific problem I am having with the ngspice-34 library install by the slackbuild.
I am running 14.2, as upgraded with patches, not current.
I have dropped back to running 4.4.227 due to needing the console scroll-back (which got removed from the console driver because there was no maintainer there to defend it).

If anyone has gotten ngspice and kicad to compile or install, you only have to look at /var/log/packages/ngspice... and
note the files installed to /usr/include, to answer this question.

I have kicad-5.1.5 and ngspice-33 running happily in 64bit Slackware-14.2. I've not tried compiling kicad-5.1.5 with an installed ngspice-34.

Current is another story

I came across a problem with kicad/ngspice yesterday. Still investigating as to what's causing the problem. I'm using 64bit Current, updated 06/03/2021 using Kernel 5.10.20 and the latest slackbuilds from Ponce.

When compiling kicad-5.1.5 with ngspice 34 I got this error

Might be a clue in the mention in the above extract from the log that

The only change from previous successful compiles of kicad-5.1.5 is that ngspice is now version 34.

Downgraded to ngspice-33 and kicad-5.1.5 compiles successfully.

ngspice-33 and ngspice-34 are both configured with the --with-ngshared parameter

I suspect that if i try to compile kicad-5.1.5 with an installed ngspice-34 in Slackware-14.2 I might well get the same problem as in current.

My initial findings are. I may be wrong.

It would appear that the file ngspice/sharedspice.h was installed in ngspice-33 but isn't in ngspice-34.

kicad tests for the existence of ngspice/sharedspice.h to determine whether ngspice is installed.

Even though ngspice-34 has been successfully installed kicad looks for ngspice/sharedspice.h which isn't there. Therefore kicad deduces that ngspice isn't installed!

1 members found this post helpful.

you should report to the ngspice and kicad maintainers on SBo that the latest ngspice update broke the kicad build.

either ngspice is reverted to version 33 (I can confirm that kicad 5.1.9 builds with that -tested on current-) or kicad is patched to work with 34.

1 members found this post helpful.

Patch file for ngspice.Slackbuild.

After about 5 hours of work digging through kicad CMake files, log files, web pages, and anything ngspice that I could find. and due to the difficulty of figuring out what include files should be there.
Finally found a ngspice library page that actually mentioned the include file by name.
Thank you for the response though, even though I only saw it afterwards.

The sharedspice.h include file was buried in src/include with all the include files used during the compile of ngspice.

The configure output "config.h" is being put into the package /usr/include by the ngspice Makefile,
through the line "make DESTDIR=$PKG install".

It probably is the ngspice Makefile that needs fixing.

1 members found this post helpful.

you should send this proposed fix to the maintainer of ngspice on SBo if you wish it to be applied there...

The Slackbuild maintainer was notified by an email. It is a gmail account, so depending on how often it is checked, I may hear back some time next year.
I cannot consider that accomplished until I hear back, according to the sequence of bug reporting from the Slackbuild site.

Filed a bug report with ngspice, .. SourceForge bug reporting system.

Compiled kicad successfully.
It started, and displayed, so at least that is accomplished.

Got sidetracked with the wxWidgets, due to all the concern displayed in the other threads.
Got a requirement of wxWidgets, got a optional requirement of wxWidgets (depending on which bit of requirements you read),
and only a few clues as to what would satisfy those requirements. There is that Slackbuild page pointing at wxGTK.

Reading wxWidgets site pages is of little help. Enthusiasm about explaining how great it is to use.
Not much about explaining why it has multiple parts, and which parts you need to do what.

As far as I have determined,
.. wxWidgets is the interface part, referenced to compile a program.
.. wxGTK is a wxWidgets "instance" that supplies a wxWidgets library instance.
.. wxPython ... Don't know, they never explain it. Wild guess, it is a Python encapsulation of the wxWidgets inteface so that Python can use wxWidgets.
.. wxX11, wxWidgets for X11, which I almost installed, BUT ...
It may be that having two wxWidgets "instances" on the machine at one time will break things.
So for now at least I am only having the wxGTK installed.
I am 80% sure this is a safe conclusion.

The Slackbuild wxGTK package installs both parts, the wxWidgets include files as "wx-3.0", and a confusing set of wx libraries (/usr/lib) that have "gtk" in their library name.

Thank you for your attention.

Re wxwidgets:

When I compiled it from scratch in 2013, there was one 'wxwidgets' project, and that was what you needed. The landscape has clearly changed a lot.

I would cd to the top source and start searching for a qt dir, for .py scripts, etc. The cmake or configure script should check for necessary packages.

After looking at the wxWidgets include files, I have some additional observations.

.. wxWidgets include files look like they would be the same for all wxWidgets package instances.
They have x11, gtk, and windows sections.
.. Because the include files TEST for which graphics interface is in use, the resultant binary
will not be binary compatible with other instances of wxWidgets.
I would not expect a binary compiled under wxGTK, to run with wxX11, even though
either could be used on a Linux machine.
-- wxWidgets only supplies source code interface compatibility.
.. If you compile everything youself, this will not be a problem.
.. If you get any binary from someone else (like ponce), and you are using wxX11 instead of wxGTK,
then it will not work. Not predictable how it will fail.
.. There are tests in the include files for GTK vrs GTK2.
Using GTK gets the same fields as X11, but GTK2.0 is separated out as a separate include file.
They alter object fields, and enums depending upon the tests.
If you get a binary compiled to a different version of GTK than you are running,
there likely will be binary interface incompatibilities in wxWidgets.
.. This does not account for why there are run-time libraries, or what they accomplish.

Conjecture:

The wxWidgets library and all programs using wxWidgets must be compiled using the same machine.
There is no binary compatibility guaranteed between wxWidget code compiled on different machines.

Consider a user that gets wxWidgets from Alien, and then gets a program using wxWidgets from ponce,
and then compiles themselves a third program using wxWidgets.
There is no guarantee that these programs will be binary compatible with the installed run-time wxWidgets libraries.

Because the wxWidgets include files contain unregulated graphic system dependencies, they might not be compatible
with actual graphics packages installed on the user system.
This incompatibility is not constrained by any requirements listed for the package. It is not detectable by running ldd.
Everything the wxWidgets include files could test must be considered a requirement on the user system.

The wxWidgets include files do not produce a set of wxWidget library interfaces that is stable across different user systems.

This conjecture is hard to disprove.
For any possible incompatible graphics difference, it may be possible to find an definite
dependence on that graphics difference in the wxWidgets include files.
That would prove the conjecture for that particular graphics difference.

To disprove the conjecture we have to consider all the possible graphics differences
that might be possible, and convince ourselves that no dependency exists for
that graphic difference in the wxWidgets include files. Considering the number of
include files involved, the complexity of examining their tests, this is not likely
to be accomplished.

Even if wxWidgets maintainers had promised that there was some binary compatibility,
it would be hard to believe that they had accomplished that. With all the graphics
tests in the include files, they are wide open to binary dependencies.

Let me try and clarify.

Include files are used at compile time only. A lot of the time, you get away with libraries because of the way they are referenced in the code. For the library libexample-1.2.26.so, ld might make the following symlinks

libexample.so --> libexample-1.2.26.so
libexample.so.1 --> libexample-1.2.26.so
libexample-1.2 --> libexample-1.2.26.so

Then it goes to source code to see which library was called. The last number is usually a bugfix and less often called. If there's a compatibility break or major revision, however, you might have libexample-2.0.so and that won't satisfy anything. Often you can try a symlink from the library you have to the one that they want to make it compile, and most times it does work and doesn't crash. At worst, it's a reboot, and some wiping of egg from your face.

Things using graphical stuff are inclined to bump versions quite often. This is inclined to make distros that do a lot of testing (e.g. debian, centos) and use older versions unsuitable for this stuff.

Business kid, you are wasting a perfectly good explaining on someone who has been do this for 40 years. I started writing software professionally in 1975, on a 4004 calculator chip, by hand cause we did not have an assembler the first 2 years, .. and everything was uphill and into the wind both ways.