Component libraries (.lib) contain component definitions or SPICE like netlists.
The SPICE netlists components (such as bridges or some MOSFETS) get drawn as boxes without ports.
I saw 2 separate failure origins masking one another.
ORIGIN N.1
This fails in the -dev version due to a failing check between QucsVersion and LibVersion:
FiX
components/libcomp.cpp:108
if (LibVersion > QucsVersion) // wrong version number ?
return -3;
since
PACKAGE_VERSION = 0.0.21-dev
but in main.cpp:
QucsVersion = VersionTriplet(PACKAGE_VERSION)
returns:
QucsVersion="0.0.0"
I cracked on towards misc.cpp: VersionTriplet() and stripped the -dev for a quick fix but I fully agree with the todo comment.
Once the symbol is loaded, a segmentation fault arises when LibComp::newOne tries to copy the new component - See CONTEXT 2
The problem starts in CONTEXT 1 when getComponentFromName recreates component (around line 1700: c->recreate(0);) just 1 Property remains after recreate.
That's because Libcomp::recreate() -> LibComp::createSymbol() -> LimbComp::loadSymbol() -> Component:analyseLine() erases the last property in line 1108.
I decided to extend the loop in 1806 from
for(int i = 0; i < (numProps - 1) && pp != Props.end(); ++i)
to
for(int i = 0; i < (numProps) && pp != Props.end(); ++i)
The ultimate reason for that -1 is beyond my scope, so the solution might well have been adding something extra in libXXX.lib due to an improper format design.
STATING the problem
Component libraries (.lib) contain component definitions or SPICE like netlists. The SPICE netlists components (such as bridges or some MOSFETS) get drawn as boxes without ports.
I saw 2 separate failure origins masking one another.
ORIGIN N.1
This fails in the -dev version due to a failing check between QucsVersion and LibVersion:
since PACKAGE_VERSION = 0.0.21-dev
but in main.cpp: QucsVersion = VersionTriplet(PACKAGE_VERSION)
returns: QucsVersion="0.0.0"
I cracked on towards misc.cpp: VersionTriplet() and stripped the -dev for a quick fix but I fully agree with the todo comment.
LibComp::loadSection LibComp::loadSymbol LibComp::createSymbol MultiviewComponent::recreate getComponentFromName Schematic::dragEnterEvent
ORIGIN N.2
Once the symbol is loaded, a segmentation fault arises when LibComp::newOne tries to copy the new component - See CONTEXT 2
The problem starts in CONTEXT 1 when getComponentFromName recreates component (around line 1700: c->recreate(0);) just 1 Property remains after recreate. That's because Libcomp::recreate() -> LibComp::createSymbol() -> LimbComp::loadSymbol() -> Component:analyseLine() erases the last property in line 1108.
I decided to extend the loop in 1806 from
for(int i = 0; i < (numProps - 1) && pp != Props.end(); ++i)
to
for(int i = 0; i < (numProps) && pp != Props.end(); ++i)
The ultimate reason for that -1 is beyond my scope, so the solution might well have been adding something extra in libXXX.lib due to an improper format design.
Component::prop LibComp::newOne MouseActions::MPressElements Schematic::dropEvent