Qucs / qucs

Qucs Project official mirror
http://qucs.sourceforge.net/
GNU General Public License v2.0
1.16k stars 213 forks source link

Qucs modular build initially failed (for strange reason) #1062

Closed GerryHickman closed 2 years ago

GerryHickman commented 2 years ago

Starting at this page https://github.com/Qucs/qucs I first built and installed 'ADMS' and 'qucsator', and tested them using command line. I then switch to branch "qucs/modular", install Qt5 deps, and build using autotools. The build nearly completed, but failed at the link stage ../src/.libs/libqucs.so: undefined reference toistream_t::ctob()'` It was complaining about one tiny missing function. This func is borrowed from the 'gnucap' project.

include/ap.h (declaration here)
ap_convert.cc (defined here in 'gnucap'
src/io.cpp (not defined here, strange?)

I created a dummy definition of it, and the build completed. I was able to run main/qucs and the Qucs QMainWindow appeared on the screen with the component tray on the left and the schematic editor on the right, I was able to import a schematic and run a simulation.

felix-salfelder commented 2 years ago

On Wed, Dec 29, 2021 at 07:30:17AM -0800, GerryHickman wrote:

The build nearly completed, but failed at the link stage ../src/.libs/libqucs.so: undefined reference toistream_t::ctob()'` It was complaining about one tiny missing function. This func is borrowed from the 'gnucap' project.

Dear Gerry.

Thanks for testing.

I could not reproduce the linker error with g++ (Debian 11.2.0-10) 11.2.0.

include/ap.h (declaration here) ap_convert.cc (defined here in 'gnucap' src/io.cpp (not defined here, strange?)

The i/o is borrowed from gnucap, and we could just use vanilla libgnucap, if there wasn't some friction still. I have only replicated a minimum subset in order to get started.

This way there is no need to install Gnucap (yet), but it is needed to build Gnucsator anyway...

I created a dummy definition of it, and the build completed.

Did that (in a bit of a rush). Please also try "make check" at some point and close this ticket if the fix works as expected.

GerryHickman commented 2 years ago

It's odd that you don't get the linker error on Debian, unless your linker either doesn't check for undefined symbols, or your code is different. Your dummy version looks similar to mine, so should work.

I'm confused about 'qucsator' vs 'Gnucsator'; which one should we be using with Qucs modular?

felix-salfelder commented 2 years ago

On Thu, Dec 30, 2021 at 06:38:12AM -0800, GerryHickman wrote:

It's odd that you don't get the linker error on Debian, unless your linker either doesn't check for undefined symbols, or your code is different. Your dummy version looks similar to mine, so should work.

ctob is used in an inlined function. Maybe this is interpreted differencly by your compiler (which one is it?). I don't think this is a big deal either way. (Thanks for reporting the issue!)

I'm confused about 'qucsator' vs 'Gnucsator'; which one should we be using with Qucs modular?

By default, Qucs was developped around 'qucsator', and this is the default simulator. Gnucsator is a drop-in alternative program based on Gnucap that imitates Qucsator (similar invocation, common "netlist" format and "dat" format). At the moment Gnucsator only supports a subset of Qucsator components, but adding more should be very easy.

Modular Qucs has a driver for Qucsator (which also runs Gnucsator if you wish), but there is also a driver for Gnucap (under development). No more need for netlist files an dat files.

Modular Qucs is designed to support any simulator (through plugins) in the future. Or just analyse circuits without the need for an external program (but plugins).

There is work to do... no matter which direction you choose to take.

GerryHickman commented 2 years ago

I agree about the inline func, could explain diffs.

I actually found inconsistencies between 'qucsator' and 'qucs/modular', one minute it was clang++ and then it was gcc, and then then it wanted to add 'O0' to the debug build, and then the default was non-debug. On RHEL most packages are built with debug 'on' and then symbols get stripped during packaging. I'll need to test it more carefully.

Thanks for clarification about different simulators and how they can be "plugged in".

sv1 commented 2 years ago

Hello all,

I am on Debian 11 and have succefully compiled qucs modular branch!!!

Running main/qucs I get a lot of:

incomplete:io.cpp:379:warn parse warning /Component>: no match error 1 >>>>> error 1 >>>>> <.ID -26 13 D> error 1 >>>>> <.PortSym -30 0 1 0> error 1 >>>>> <.PortSym 30 0 2 180> error 3 no proto ><@@# @@@ incomplete:io.cpp:379:warn parse warning Component: no match error 1 >>>>> error 1 >>>>> @@# @@@

but finally the main window appears.

My project are visible on the left panel but I can not open any of them with double click.

Also the "Tools" menu on the menubar does not open.

The output of "make check" gives the following result:

================================================================== Testsuite summary for qucs 0.1.0

TOTAL: 51 PASS: 50 SKIP: 0 XFAIL: 1 FAIL: 0 XPASS: 0 ERROR: 0

Question: Although I issue "git submodule init" and "update", I think nothing happens!!! Is this a git config problem?

Keep up the good work!!

felix-salfelder commented 2 years ago

On Thu, Jan 13, 2022 at 10:40:00AM -0800, sv1 wrote:

I am on Debian 11 and have succefully compiled qucs modular branch!!!

Thanks for trying.

error 1 >>>>>

This is an artifact/incomplete. io_error.h +26.

I haven't fully decided how to do it. Perhaps such messages should all go through Object::message, or Element::message, see object.cpp.

Error "level" 1 is supposed to be a log message. Nothing actually wrong here.

TOTAL: 51 PASS: 50 SKIP: 0 XFAIL: 1 FAIL: 0 XPASS: 0 ERROR: 0

XFAIL means expected failure. So all PASS.

Question: Although I issue "git submodule init" and "update", I think nothing happens!!! Is this a git config problem?

There are no submodules. The basic plugins are in plain subdirectories and others are in independent repos. It's too early to worry about a metapackage.