AppImageCommunity
Unable to build for armhf
Attempting to build on 32bit systems requires _FILE_OFFSET_BITS=64 (as you do for i386 in the CI). However doing this on armhf results in an attempt to link to non-existent symbols in the system libz.so.1 library
/usr/bin/ld: libzsync2_standalone.a(zsclient.cpp.o): undefined reference to symbol 'gzopen64@@ZLIB_1.2.3.3'
/usr/bin/ld: /lib/arm-linux-gnueabihf/libz.so.1: error adding symbols: DSO missing from command line
collect2: error: ld returned 1 exit status
the only current solution I have is to build an older version of appimageupdate before gpgme became a requirement which avoids needing to set _FILE_OFFSET_BITS=64
Sorry to hear. Unfortunately I don't know why armhf libz apparently doesn't have this symbol. @TheAssassin do you have an idea what could be done here?
This issue report lacks a lot of data and makes it impossible to help (unless I start guesstimating, which I do not have the time for and won't be joy for either party).
Let's start with the OS you're trying to build on. Next, you should post how you build and also include a log. Also, since the issue is within zsync2, you should try to build that separately first. The issue may be moved there.
P.S.: A log of your CI (if public) and a link to your build scripts will do for now.
@theofficialgman it would be great if you coul give us step-by-step instructions on how we can reproduce this issue. Thanks!
I am building similar to how you do in your CI (but checking out a particular tag):
You can see the log in the CI as part of the MuseScore buildscript that I wrote https://github.com/theofficialgman/MuseScore/actions/runs/7134771921/job/19430234833#step:7:8300
At the time the build commands were as follows on a focal armhf docker container (run as part of that MuseScore CI with docker run): https://github.com/theofficialgman/MuseScore/blob/25567eedf2de058235125ec0552a41161be71966/build/ci/linux/setup-arm.sh#L298-L314
I'll update the Docker-based build scripts a bit so we can easily try to build for armhf with these. Of course, I'll start with zsync2. Once that works, you'll have a reference setup to work with.
We have to use Debian now as it still supports i386 with zsync2 (bionic is EOL, focal does not ship i386). zsync2 builds fine there, so I suspect it might be Ubuntu that is causing problems here. I'll try and build zsync2 with the new build scripts for Ubuntu focal and armhf. But I don't expect any problems there either, honestly.
I am going to publish the scripts as soon as possible.
For zsync2, see https://github.com/AppImageCommunity/zsync2/commit/5731f09813a560c42152adb3ec26000f34a7f0f9. Builds fine with Debian on all architectures, no changes needed. Locally, I changed the Dockerfile to use Ubuntu focal for a single armhf build which also worked. I'll work on AppImageUpdate next.
Error reproduced. The thing is, I don't see how libzsync2 was involved in it, though. Likely a misinterpretation due to the just 2(!) mere lines of log shared. People, share actual build logs!
I now set the flag only on the required libappimageupdate in the CMake scripts depending on whether we had to build for a 32-bit target. That fixes the linking issue.
Building works fine for both platforms using our own CI scripts on both Debian bullseye and Ubuntu focal (the latter using the patching explained above). This is about all the debugging I'm able to do now. Please see our reference build environment. Cannot reproduce.
As a side effect, ARM builds will soon be available. The only tool missing is linuxdeploy-plugin-qt.
People, share actual build logs!
If you follow https://github.com/theofficialgman/MuseScore/actions/runs/7134771921/job/19430234833#step:7:8300, then click on the gear icon, select "View raw logs" you get the full build log.
... which was not provided initially and I don't really like to search for stuff on my own in complex build setups. It's not asked too much for to just provide a log in a pastebin or as an attachment in my opinion. The user knows where to look for one, the maintainer wants to spend their time on issue solving as good as possible.
... which was not provided initially and I don't really like to search for stuff on my own in complex build setups. It's not asked too much for to just provide a log in a pastebin or as an attachment in my opinion. The user knows where to look for one, the maintainer wants to spend their time on issue solving as good as possible.
@TheAssassin don't make false accusations that you can't backup. @probonopd is correct. I opened the issue, you both asked for a full log and CI links, then I provided both. Simple as that. No need to make up stuff. I provided one comment, easy to read and follow, with everything you asked https://github.com/AppImageCommunity/AppImageUpdate/issues/230#issuecomment-1847601624 . The first link was the full log linked directly to where the error appeared. The second link was the highlighted CI docker launch command. The third link was the relevant part of the build-script highlighted for making appimageupdate.
Just say "oops sorry I must have missed that".
don't make false accusations
How is it a false accusation? I referred to your first comment, and you should read it in that context. It should be standard to provide a build log when asking a maintainer to debug a build failure. I should have made that clearer. However, I'm spending time on debugging your problem at the moment.
More evidence to my point that we need issue templates everywhere.
And please remember that I'm spending my time on your issue... A misunderstanding on both sides is not the same as a lie. I'm doing this in my free time. I did not make any explicit accusations towards you. And I've spent the day with similar issues where no logs were provided. It gets extremely tiring after the third time you write such a comment. And I've had to write hundreds by now.
Edit: also, I mentioned I wanted people to share just the excerpt that is relevant, but that in its entirety. Your link points to what I criticized as too elaborate (even though it includes that log, there is a ton of other stuff as well). You excluded that in your slightly aggressive response.
I do not have time to explain how wrong you are on your points. It's not constructive. You were called out on it by me and probonopd so I suggest you think about it.
I don't see how you can even tell people they're wrong given your anything-but-constructive accusation. People who "don't have the time to explain" their point have no point.
Also, this is off topic. And @probonopd's response was not aggressive in any way. That's one major difference. So don't compare your response to his.