Unable to build for armhf

[theofficialgman]

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

[probonopd]

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?

[TheAssassin]

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.

[probonopd]

@theofficialgman it would be great if you coul give us step-by-step instructions on how we can reproduce this issue. Thanks!

[theofficialgman]

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

[TheAssassin]

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.

[TheAssassin]

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.

[TheAssassin]

For zsync2, see AppImageCommunity/zsync2@5731f09. 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.

[TheAssassin]

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.

[probonopd]

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.