ARM build failure

[antimicrox]

ARM build failure

[gombosg]

Thanks! So it is the same armv7hl compilation issue after all!
@pktiuk any ideas why this happens only in this specific (32-bit) architecture? And as we see, it happens when compiling in Raspbian and also on Fedora, so it's probably not OS-specific.

Either it's because the architecture or because linking works differently with ld?
After some googling I found this. Looks like an -fcommon compilation flag could help. Or maybe some source change is needed?

I made a Fedora scratch build (fails on armv7hl) so you can compare logs for various architectures.

EDIT: here's a comparison of successful aarch64 and failed armv7hl build logs: https://editor.mergely.com/msJqKcMr/

[pktiuk]

Also Raspbian OS is only available in 32-bit. official site

There is also 64bit version, but it is still in beta (publishing 8 GB version ob pi4 made it necessary), it is also compatible with pi3.
If this is caused only by 32 bit architecture we should be able to run it on this beta version.

After some googling I found this. Looks like an -fcommon compilation flag could help. Or maybe some source change is needed?

This change looks promising, we should check it. I don't think we should change anything in source code (but I may be wrong).
The only place where these changes will be applied will be CMakeLists.txt.

[pktiuk]

Yes

CHECK_CXX_COMPILER_FLAG("-std=c++11" COMPILER_SUPPORTS_CXX11)

set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -fcommon") #this line should just work fine


if(COMPILER_SUPPORTS_CXX11)
    if (NOT WIN32)
        set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=c++11")

[pktiuk]

There was a very similar issue on legacy repo. juliagoda/antimicroX#111
It seemed to be caused by lack of package qtbase5-dev in raspbian repositories.

I think the simplest solution for now would be installing AntiMicroX using flatpak package.

@AriaMoradi
Could you check this?

[AriaMoradi]

qtbase5-dev version 5.11.3+dfsg1-1+rpi1+deb10u is installed.
Is'nt flatpak made for amd64 too(edit: I meant only)?

[pktiuk]

qtbase5-dev version 5.11.3+dfsg1-1+rpi1+deb10u is installed.

Interesting. If it is installed, everything should work properly.
According to terminal output it is a problem with linking, not with compilation itself.
Maybe a proper solution would be cross-compiling package for arm...
I will investigate it later.

Is'nt flatpak made for amd64 too?

Yes, flatpak is built for x86_64 (called also amd64) and aarch64.

flatpak repo

[gombosg]

AFAIK Raspberry is ARM and not x86 architecture. So this is the same as:

https://bugzilla.redhat.com/show_bug.cgi?id=1849216

Let me know id you find a solution, then I can also fix the Fedora package.

[pktiuk]

@gombosg
Yes, Raspberry Pi is ARM-based, so it should use aarch64 (name for 64-bit version of arm) package.

[gombosg]

Hm, interesting. In Fedora, 64-bit aarch64 builds just fine, but I got the same error (see the bug link above) for 32-bit armv7l, which is some older ARM architecture.

@AriaMoradi is it possible that your OS is somehow 32 bit armv7l architecture? You can learn easily with uname, can you paste uname -a output here?

[AriaMoradi]

@gombosg
Yes, Raspberry Pi is ARM-based, so it should use aarch64 (name for 64-bit version of arm) package.

confirmed. aarch64 == ARMv8-A which raspberry pi 3 and 4 both support(Cortex-A53 and Cortex-A72 respectively).

[AriaMoradi]

Hm, interesting. In Fedora, 64-bit aarch64 builds just fine, but I got the same error (see the bug link above) for 32-bit armv7l, which is some older ARM architecture.

@AriaMoradi is it possible that your OS is somehow 32 bit armv7l architecture? You can learn easily with uname, can you paste uname -a output here?

Yes. Although we confirmed it supports aarch64(it does not!, see edit), the kernel is armv7l which from what I gather is what they call aarch32 or 32-bit:

$ uname -a
Linux raspberrypi 5.4.72-v7+ #1356 SMP Thu Oct 22 13:56:54 BST 2020 armv7l GNU/Linux

Also Raspbian OS is only available in 32-bit. official site

edit: further info
It can only run ELF 32-bit executables

# bash from archlinuxarm armv7
armor@raspberrypi:/tmp/bash/armv7h/usr/bin $ file bash
bash: ELF 32-bit LSB shared object, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-armhf.so.3, BuildID[sha1]=90b5e2841db5c8fc2d73daedd74f0fa59d5a0f4e, for GNU/Linux 3.2.0, stripped
# bash from archlinuxarm aarch64
armor@raspberrypi:/tmp/bash/aarch64/usr/bin $ file bash
bash: ELF 64-bit LSB shared object, ARM aarch64, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-aarch64.so.1, BuildID[sha1]=8972a9606bc894a93a6e9ed47dec62808ca7c482, for GNU/Linux 3.7.0, stripped
# bash from system
armor@raspberrypi:/tmp/bash/aarch64/usr/bin $ file /bin/bash
/bin/bash: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-armhf.so.3, for GNU/Linux 3.2.0, BuildID[sha1]=3e5e2847bbc51da2ab313bc53d4bdcff0faf2462, stripped
# only armhf is available on the system
armor@raspberrypi:/tmp/bash/aarch64/usr/bin $ ls /lib/ld-linux*
/lib/ld-linux-armhf.so.3  /lib/ld-linux.so.3

this link says that there are some closed source libraries that are not available for aarch64.

[gombosg]

Let me do a test then with this. Is it CMAKE_CXX_FLAGS right?

[AriaMoradi]

looks like -fcommon is related to C code and not C++. It fixes linker errors which are related to forgetting extern when it needs to be there. But it sometimes works in C++ that i can't find docs for.
Also I'm building with gcc 8.3.0 and it's mentioned that it's a bug introduced when upgrading to gcc 10. so more confusion?
source1
source2

This is from gcc manpages:

       -fno-common
           In C code, this option controls the placement of global variables
           defined without an initializer, known as tentative definitions in
           the C standard.  Tentative definitions are distinct from
           declarations of a variable with the "extern" keyword, which do
           not allocate storage.

           Unix C compilers have traditionally allocated storage for
           uninitialized global variables in a common block.  This allows
           the linker to resolve all tentative definitions of the same
           variable in different compilation units to the same object, or to
           a non-tentative definition.  This is the behavior specified by
           -fcommon, and is the default for GCC on most targets.  On the
           other hand, this behavior is not required by ISO C, and on some
           targets may carry a speed or code size penalty on variable
           references.

           The -fno-common option specifies that the compiler should instead
           place uninitialized global variables in the BSS section of the
           object file.  This inhibits the merging of tentative definitions
           by the linker so you get a multiple-definition error if the same
           variable is defined in more than one compilation unit.  Compiling
           with -fno-common is useful on targets for which it provides
           better performance, or if you wish to verify that the program
           will work on other systems that always treat uninitialized
           variable definitions this way

edit1: this issue might be related MaskRay/ccls#23
edit2: useful info? https://xspdf.com/resolution/58686127.html
edit3: https://stackoverflow.com/questions/32811828/gcc-g-and-multiple-definitions-of-global-variables
edit4: https://vector-of-bool.github.io/docs/dds/err/link-failure.html
edit5: maybe I'm into something: (https://documentation-service.arm.com/static/5eecb6a0b7429076afea0524?token=)

1.10 -fcommon, -fno-common
    Generates common zero-initialized values for tentative definitions.
    Tentative definitions are declarations of variables with no storage class and no initializer.
    The -fcommon option places the tentative definitions in a common block. This common definition is not
    associated with any particular section or object, so multiple definitions resolve to a single symbol
    definition at link time.
    The -fno-common option generates individual zero-initialized definitions for tentative definitions. These
    zero-initialized definitions are placed in a ZI section in the generated object. Multiple definitions of the
    same symbol in different files can cause a L6200E: Symbol multiply defined linker error, because the
    individual definitions clash with each other.
  Default
    The default is -fno-common.

edit6: maybe can be fixed at the linker level? https://manpages.debian.org/testing/binutils/gold.1.en.html and https://www.eecs.umich.edu/courses/eecs373/readings/Linker.pdf
edit7: well that's all I could find from the depths of the internet. maybe it's a gcc bug... or ld? gold?

[gombosg]

Yes, -fcommon didn't solve it, I got the same build error.
We could try some LFDLAGS but I have no clue how they work. Also, keep in mind that only armv7hl architecture is failing, and only during the linking phase, so the failure is likely due to

• either 32/64 bit differences
• ld linker differences, like default flags or other settings.

I checked, in Fedora LDFLAGS are the same for aarch64 and armv7hl.

[AriaMoradi]

Yes, -fcommon didn't solve it, I got the same build error.
We could try some LFDLAGS but I have no clue how they work. Also, keep in mind that only armv7hl architecture is failing, and only during the linking phase, so the failure is likely due to

• either 32/64 bit differences
• ld linker differences, like default flags or other settings.

I checked, in Fedora LDFLAGS are the same for aarch64 and armv7hl.

maybe finding the exact linker error could help? I suspect L6200E(edit5) is not what is happening?

[gombosg]

The error I got is the same that you described in the first post.

[gombosg]

After some googling/SO'ing around, I tried to fix this from the code side, despite having no clue about C++ 😆
Basically the point is that template functions/classes are tricky in C++, and in this case, somehow the .cpp file was included from the .h file and not set to compile in the CMakeList. This generated some linker errors on some arches. I fixed that. See also here:

• https://stackoverflow.com/a/115735
• https://isocpp.org/wiki/faq/templates#separate-template-fn-defn-from-decl

@AriaMoradi
Can you try this fix on your Raspberry Pi? https://github.com/AntiMicroX/antimicrox/tree/fix/armv7hl

It builds for me: https://koji.fedoraproject.org/koji/taskinfo?taskID=55178896