I’m just doing a test restore of Ubuntu, after which I’ll try this and see if the swapping mechanism problem still occurs for me. I suspect the local build of the boost and libgit2 libraries is because they don’t usually exist on common linux systems and thus need to be essentially staticly linked for Fritzing to work and something we are doing (perhaps not running the release script) is breaking that. I’ll continue poking and try and figure it out. Once I’ve got restore working correctly I can damage the system while trying things and then just restore it .
Exactly what I’m getting… Interesting… I’d like to hunt this issue out. Thank you for confirming what I was seeing… Seem’s like a bug to me. It should be filed on git-hub. Anyhow… Thanks for verifying
This looks to be documentation error. If I install parts beside fritzing-app I get the swapping error, if I move it in to fritzing-app/fritzing-parts as it is in the distributed version, then (along with the link for the libgit2 library) it seems to work from the command line. There does seem to be a bug as I think (although I know nothing yet about qmake) that
should be setting the appropriate library path so it finds the shared library, but it doesn’t seem to. I’ll write up and post the exact sequence of commands that got me to an apparently working environment for anyone else who we can convince to join in. Now on to trying to figure out Qtcreater so I can start running the debugger and see if I can make heads or tails out of the error I create with bad xml. On windows Fritzing hangs, on Linux it causes a seg fault so the debugger should give me at least a clue of where to look. Thanks for all the help guys!
OK, I’m at a loss. My base system has an older (5.4 I think) version of Qt in the base system (and I assume things are using it since its there). I have installed a 5.6 /5.9.1 version of Qt in my home directory and setting it to use 5.6 and compiling in Qtcreator seems to work fine. However when I do a qmake and then a make in the fritzing-app directory I can see it linking against the system Qt libraries and it doesn’t work (the screen comes up but the file menu is missing presumably because of the old Qt version). I dug up a stackoverflow answer on reconfiguring /etc/ld.so.conf/x86_64-linux-gnu.conf to add the new Qt library directory (and libgit2) and then ran sudo ldconfig to make it take effect but the link still uses the system Qt libraries so I either didn’t do it right (and I think if I had done it right I may have broken the rest of the system that wants to use Qt anyway which may or may not have mattered), so what is the correct way to get the fritzing-app to use the new Qt libraries and be happy?
Maybe. Once I manage to get the python part checking script finished, I’m going to move back to poking at development and see what I can do. I’m pretty close (but also have thought that for a long time ) on the script. I’m just finishing up schematic subparts to check the connectors are in the correct groups in the schematic svg, and need to add the check for silkscreen being before copper1/copper0 in pcb and it should be done. Of course it may not survive contact with the real world, but we will see . I don’t understand much about Qt yet but they do seem to have support and the Qt folks themselves have reached out so if I have questions I think there is probably help there. Much of it is going to be figuring out how Fritzing works internally. I know where the seg fault bug is, and the fix is else where in Fritizng when the part fails it needs to back out the database changes which happens usually when you say “no don’t save this part” so the code is there, I just need to figure out where it is and how it works. However that may not be easy . I have a fair amount of experience at fixing faults in open source projects but not a lot at straight development (that is some of the delay in fixing the parts script). Hopefully I can make some progress here once the part script is working.
.
.