I’m trying to become really dangerous and start looking over the source code to see if I’m able to help. The answer so far is no, I can’t even get the .9.3.b release to compile. I have a Ubuntu 16.04. LTS system up and running, have run through all the prereques, given up on Qtcreator (which is just plain broken on my system apparantly) and done a command line compile of the current head. That sails along nicely til it gets in to partschecker.ccp at which time recipe for target release failed comes up. Same thing happens on the .9.3.b release branch code, so I’m fairly sure its something I’m doing rather than the code. Can anyone suggest what I’m doing wrong please?
Well for this one I can answer my own question (although I’m still interested if there is anyone out there willing and able to answer development questions!): they are being very literal when they say "download version 0.23x of libgit2 (at this point libgit2-0.23.4.zip is what you want as it has security patches backported). At version 24 there is an api change that breaks Fritzing (there is a new parameter that Fritzing isn’t supplying apparently). I still can’t get either version to run after I compile them but at least I can compile now. Once I get this worked out (assuming I do of course), I’ll post a how to here on how to do it as we need more folks helping to develop …
I was also able to compile it with LibGit2 0.23.4 but I also was unable to get it running due to it not being able to find /lib/Fritzing
I followed these https://github.com/fritzing/fritzing-app/wiki/4.-Publishing-a-Release instructions on building an actual final release and it does run although I do not notice any changes in the program from a user perspective. The one thing I felt had changed was the performance. Now that could be just me thinking it was running faster but they may have also made improvements that do actually make it faster.
Also be sure to have Fritzing-Parts in the same folder as you have Fritizing-App before building the release as it seems to import the core library while building.
Yep, did that one fritzing-app and fritizing-parts repos in the same directory. When I installed it using this from the 1.3 linux notes (because I can’t get Qt Creator to work yet) :
cd /path/to/fritzing-app
qmake
make
sudo make install
to command line build, it complains that it can’t find the github2 shared library it just linked against when run (although I think I ran fritzing rather than fritzing.sh which may be my problem). I’'ll continue poking and see what I end up with. I suspect fixing the libgit2 dependency is a good first project, too simple for a real developer to waste time on but good practice for me .
Be sure to try building the final release like in that link. It moves all the files you just built into a new directory in the correct structure.
All you do is run release.sh 0.9.XX from Frizting-app/tools/linux_release_script/ . You can give it a new version number in the files listed in that link but in reality you don’t have to. All those changes do is change the labels in the program to the new version number. For testing you can leave them and it will just show as 0.9.3b when you start it and when you check the version in help etc.
Given my system is already setup for this I went fresh… Just to test a quick build to see if it works for me.
This is what I did…
~/fritzing-downloaddir/
rm -R fritzing-app
(this removed my git pull completely, I don’t recommend this command, as to test fresh for me…)
Then
git clone https://github.com/fritzing/fritzing-app.git
git clone https://github.com/fritzing/fritzing-parts.git
(parts clone didnt exist here for me)
which now gives me a fresh github clone of both repos APP/Parts clone
cd fritzing-app
qmake
make -j24
(if you use the -j flag, know your core(s) situation first, ie; how many you have to use, no willy nilly 24 okay)
./Fritzing
Fires right up… BUT! I have a separate issue myself. First run, worked a treat. Close and open again. I get this wonderful error on 2 different system(s) with total from scratch builds…
Sorry, we have a problem with the swapping mechanism.
Fritzing still works, but you won’t be able to change parts properties
Ouch… Time to hunt out another problem. This should be marked as a bug. If I can duplicate on 2 different systems, we have a problem. I’ll look more into this when I have time. As for why it’s not compiling or opening, lets see if we can figure this out for you guys, that way we can see if you can get onto this next error I’m currently seeing.
A Quick shows;
lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 16.04.2 LTS
Release: 16.04
Codename: xenial
Running a Kubuntu remix, with all supporting dependences in-place.
Yep I’m seeing that one too on both the 9.3.b release build (which I tried to verify my tool chain is working) and the current head build done the same as you did above.
Also seeing this one, just about to try sublimeartistry’s suggestion to create a release and see if that cures my woes. I’m also making progress on the Qtcreator front, despite dire warnings about no C tool chain it does appear to be working. It was just silently building Fritzing in the background somewhere (I only discovered that when I tried to quit Qtcreator and it asked if I wanted to cancel the build it was running, answering no and leaving it alone for a while ended up with a runable Fritzing version although it has the above parts issue just like the standalone compiled version). Its good to know there is still someone around that is familiar with how the build should work though so thanks for that and any help much appreciated!.
Your libgit2 isn’t installed and or linked properly. Look into this a bit more. Thats what is sounds like to me.
I do remember having some issues with Ubuntu version 14.04, but I have since moved away from that version. I might have one system left running it. I’ll have to check, if so I’ll give it a try.
I can’t say exactly why I have each one but I am sure they have all been dependencies for different projects i’ve played with over the last 3 years of running this install. Many of them are also the result of Epsons proprietary driver install which is an unfortunate requirement to use a particular printer as none of the generic ones work correctly.
I would agree that is what it sounds like but if you run Fritzing.sh as the Github Wiki says to you get this warning.
And when you look for that file/folder in fritzing-app/lib there is nothing called fritzing in that folder so there is clearly something other than lib2git causing it to not run as expected. Also if you look at my previous comment you can see when I run qmake it finds lib2git [quote=“sublimeartistry, post:8, topic:4149”]
Project MESSAGE: found libgit2 library in /home/b/Software/fritzing-app/…/libgit2/build
[/quote]
That makes me think lib2git is correct but I may be wrong.
So my Fritzing.sh is the same if executed ie;
sh Fritzing.sh Fritzing.sh: 16: Fritzing.sh: /home/sysadmin/Downloads/fritzing-MAIN-BUILD/fritzing-app/lib/Fritzing: not found
Anyhow… just look past that part for now, we can figure that out later…
After Fritzing is properly compiled from command line. IE; my reference above. You’ll just get an Fritzing (executable file) in your main fritzing-app (compile directory) Have another go @ it.
Look into the package manager see where your libgit2 is installed and issue some sudo ln -s system links. boom should work a treat. (should, but we all know how this goes, no matter the end software)
anyhow if it compiles and its just looking for libgit2… Just system link to whatever is installed, poke around a bit
I don’t think that will work. One of my earlier problems was that I used the latest version of libgit2. However at version .24, they changed the api and that breaks Fritzing (the api has an additional parameter Fritzing doesn’t set), so you have to go back to the 0.23.4 version (around 5 versions old now) to get it to work and that doesn’t appear to be the system version (libgit2-24 shows up in a apt-cache search libgit2 on my newly installed Ubuntu 16.04. LTS) that it would install, there isn’t a copy present by default as far as I can see. Once I get backup working so I can restore it easily I’ll try this and see what it loads and go from there. I’m keeping notes of my missteps and hope in the end to be able to provide a clear set of directions to get a build system running to try and interest more people in helping.
I decided to start over to see if I could identify the differences between my compilation and @landracer’s . The only thing I noticed is the fact I have to manually download a newer version of Boost and put it in Frizting-app/src/lib/ because the one available through apt-get is too old. In the end I ended up with the exact same issue as before.
If I package it as a release it works fine.
note: before retrying I added my build of libgit2 to my PATH but that also has not helped.
It seems like a library path isn’t being set correctly somewhere because it seems to find the library fine when it compiles and links, but at run time it has forgotten where it found it.
Library path isn’t the same as $PATH. Because the library is in a non standard place the invocation needs the linux equivilent of a libpath pointing at the new library location. It just struck me that doing a make install in the libgit2 directory will probably install the library in the correct local system libraries and thus be found (I’m pretty sure I didn’t do a make install on lingit2). No I haven’t yet tried the release script, I’m currently modifying my backup perl script (which currently only does Windows) to find and backup the linux system too. With that I can restore the entire system to a previous state in about 5 minutes using the system rescue CD tools without me having to figure out what the current drive letters are . I did a reinstall of Ubuntu from the CD last night so I have a clean system to back up to be able to go back to when I screw up.
Thank you. As you can see I am not a programmer by trade. More a hardware person that has had to learn software to actually do what I want with my hardware.
Good News Everybody.
From your hint I was able to run ldd ./Fritzing and it showed which libraries it had found and where. As well as showing that it could not find libgit2. I also ran ldd on the compiled version and found that although it ran it was also missing libgit2.so.23 .
I linked libgit2.so.23 from my build to /usr/lib/x86_64-linux-gnu/ , ran sudo ldconfig and after that Fritzing worked from the compiled binary .
Me too (although knowing hardware makes the software much much easier ) although I qualified in analog circuit design some 40 years ago, I spent the last 25 as a software type and the last 20 in a University data center running Unix (mostly not Linux though) and running open source software so I know a fair bit about installing stuff but not necessarily developing per se. Now in retirement I’m playing with hardware again.
Good job guy’s! system link(s) Gotta lov’em! Anyhow get used to doing that. Not say because of Fritzing, but any other software you might compile from source. This missing a library here or there happens, I’ve seen it a bunch lately… But once you sudo ln -s /x/x /x/x then things usually work a treat.
Anyhow, now that you guys have it working. You’re not seeing that same error with the swapping mechanism? interesting… Well I’ll have to have a look into my own lil issue.
.
. I did a reinstall of Ubuntu from the CD last night so I have a clean system to back up to be able to go back to when I screw up.
.
Gotta lov’em! Anyhow get used to doing that. Not say because of Fritzing, but any other software you might compile from source. This missing a library here or there happens, I’ve seen it a bunch lately… But once you sudo ln -s /x/x /x/x then things usually work a treat.