Download pit for S5 G900F fails with heimdall-frontend but succeeds with command-line binaries 1.4.1

[ghost]

Both binaries were compiled from the source I downloaded from master today (1.4.1) I didn't save the error, but it gave the typical error seen in other s5 pit download issues regarding not being able to end the transfer successfully etc.

When using heimdall-frontend I was not able to download the pit file using Utilities, and I was not able to flash either, because when starting the flash process it wanted to download the pit file, even though I had selected the pit file as part of the flashing process. (which seems to be another bug, but it might be a nice safety check?)

None of this bothers me. I was just trying heimdall-frontend because I was feeling lazy. I use commandline stuff 99% of the time, and I used the commandline afterwards, which worked. I'm just reporting this for the sake of people who need frontends.

So it seems that heimdall-frontend and heimdal binaries use different code?

the compile process went a little something like this on Ubuntu 14.04

apt-get install build-essential cmake zlib1g-dev qt5-default libusb-1.0-0-dev libgl1-mesa-glx libgl1-mesa-dev
#download Heimdall master from github
cd /tmp; unzip Heimdall.zip; cd Heimdall
mkdir build; cd build
cmake -DCMAKE_BUILD_TYPE=Release ..
make -j 4
cd bin
sudo ./heimdal--frontend >/dev/null 2>&1 &

[Benjamin-Dobell]

It does seem a bit odd that Heimdall Frontend would fail where Heimdall command line succeeds, as the former utilises the latter.

My guess is that you ended up with multiple heimdall CLI commands on your computer and Heimdall Frontend was calling the wrong one. If you go into the about screen you can see what version of Heimdall command line the Frontend is using.

[ghost]

Oh that explains it. I thought it seemed a little crazy/unusual that the frontend would re-implement the code from the CLI. I mean at first it looked like it was just dumping the CLI output. But then when I experienced the above I figured it was re-implementing the code. I didn't think of the (rather obvious) possibility that it was just running whatever was in $PATH.

After reading your response now, I realized what happened.

The newly compiled heimdall-frontend must have been using the ubuntu 14.04 installed Heimdall 1.4, which experiences that problem. Of course when I ran the new CLI binary, I ran it directly.

sudo make install not working? BTW, after running make, I tried to run sudo make install but it said make: *** No rule to make targetinstall'. Stop.`. Then I scratched around in some make file and I saw some text "INSTALL" something, but I'm not very familiar with modifying build scripts and didn't want to spend unnecessary time on the issue, so I just ran it from the terminal.

If make install had worked, then I wouldn't have experienced this.

Ideas to prevent this problem

• Surely make install should work?

• What about adding a warning popup msgbox if heimdall-frontend is a higher version than the heimdall binary it finds in $PATH?

• Surely it's reasonable/important for testing and development that when you compile heimdall (which includes a CLI binary and a GUI-binary-that-runs-the-CLI-binary) that the GUI binary should check in it's own directory for the heimdall binary and run that preferentially over whatever random old binary happens to be in $PATH?