SDK build engine does not support netlink sockets

[takimata]

REPRODUCIBILITY : 100%
BUILD ID = OS VERSION: 4.3.0.12-aarch64
HARDWARE (XA2, X10, X10 II, …): SDK Build engine
REGRESSION: ?

DESCRIPTION:

> sfdk build-shell
$ ip
Cannot open netlink socket: Protocol not supported

Netlink sockets are not supported in the SDK build engine. This breaks ip and, more importantly, test cases of other software I’d like to package (e.g. https://github.com/zeromq/libzmq). Of course netlink is not strictly required for building stuff with the SDK or in Chum/OBS - but I don’t think that disabling test cases is a good idea either (especially because they would work fine otherwise).

STEPS TO REPRODUCE:

1. enter build engine: sfdk build-shell
2. install ip
3. run ip

EXPECTED RESULT:

ip shows normal output

ACTUAL RESULT:

see above

ADDITIONAL INFORMATION:

I don’t know the kernel sources from which the build engine image is built, so I’m reporting that here.

[martyone]

First of all, are you certain the tests in question are meant to be run under build environment? Despite the fact that a unit test framework is used for implementation, the tests may be actually doing system testing, in which case they should be naturally run only after deployment under a true target environment.

Sailfish SDK is a crosscompilation development environment. As such it provides just a limited runtime environment for target-compatible executables, mostly intended for running well-behaving build tools. Running arbitrary software under the build environment is not trivial to achieve.

[takimata]

@martyone

First of all, are you certain the tests in question are meant to be run under build environment?

They are launched via make check, so yes.

Let’s take a simple test as an example: https://github.com/zeromq/libzmq/blob/master/tests/test_system.cpp (For this example I had to statically link everything because the test suite doesn’t use readily usable executables - but the errors stay the same)

Running it on the phone works fine:

$ /tmp/a.out             
test_system.cpp:114:test_localhost:PASS
test_system.cpp:115:test_max_sockets:PASS

-----------------------
2 Tests 0 Failures 0 Ignored  
OK

Build engine yields a crash (with make check and this example):

$ ./a.out 
Protocol not supported (src/ip_resolver.cpp:542)
qemu: uncaught target signal 6 (Aborted) - core dumped
Aborted (core dumped)

which can be traced to https://github.com/zeromq/libzmq/blob/master/src/ip_resolver.cpp#L531-L542

getifaddrs() isn’t too mis-behaving, isn’t it?

The example from the getifaddrs(3) man page fails for the same reason in the build engine, too: Missing netlink support (which the real phone has).

@martyone

Sailfish SDK is a crosscompilation development environment. As such it provides just a limited runtime environment for target-compatible executables, mostly intended for running well-behaving build tools. Running arbitrary software under the build environment is not trivial to achieve.

Well, apparently it depends on the definition of well-behaving whether stuff is suitable for the SDK

53 of 113 test cases seem to fail due to this. I’ll disable them for now, but I’d still love to see more networking support (and maybe other stuff like a working strace) in the build env.

[vige]

@takimata

They are launched via make check , so yes.

That hardly means that the tests are meant to be run on the build environment, unless the build enviroment is also the target environment. What would running them on the build environment even prove? The self-tests are there for verifying that the library works as expected - how can you do that anywhere else than on the target environment?

[martyone]

@takimata

Well, apparently it depends on the definition of well-behaving whether stuff is suitable for the SDK

Apparently? Naturally! I attribute it to a lack of experience with cross compilation environments, that you do not appreciate the versatility of Sailfish SDK in this area.

It is not uncommon that cross compilation environments do not allow running target-compatible binaries at all. It is not uncommon that cross compilation environments require special treatment (and even access to physical target-compatible hardware) for running target-compatible binaries. Here Sailfish SDK excels with its capability to truly cross compile most of the existing software with no changes required to their original (non-cross) build process, even if execution of target-compatible binaries is required at build time. And that all happens with minimal performance hit when compared to native compilation.

[poetaster]

Here, here. Anyone with some experience ‘doing it by hand’ will appreciate how well it does work. And that the build env is not the target does have some downsides (compare a build in the SDK to obs and you will see differences) but it works REALLY well.

Try building something like MODEP – MOD DUO Emulator for Raspberry Pi on linux from scratch. I’ve done this kind of thing a fair bit (also cross compiling sclang for a supercollider on pi project) and it can get really messy, fast.

I test on arm 32 and 64 (3.4/4.3) bit in parallel and am always amazed by how uniform the behaviour is.

Back to work.

[takimata]

@vige

The self-tests are there for verifying that the library works as expected - how can you do that anywhere else than on the target environment?

True, but if I could make them work without much effort I would have taken these low-hanging fruit along the way, since there is no infrastructure running (automated) tests on the target environment. Would have been at least some test which happens before running in prod.

@martyone

Apparently? Naturally! I attribute it to a lack of experience with cross compilation environments, that you do not appreciate the versatility of Sailfish SDK in this area.

Sure, it’s hard to appreciate something which has been around for so long that you take it for granted

@poetaster

compare a build in the SDK to obs and you will see differences

I have to admit I never looked very closely at Build Status Monitor - SailfishOS Open Build Service , but it seems that there aren’t no native workers?

[poetaster]

I wasn’t referring to build time testing (which I think you are?) but a myriad of small ‘gotchas’ … @rinigus recently clarified how to get translations being built: BuildRequires: qt5-qttools-linguist in the spec. This is ‘not obvious’, but it’s automatically there in the SDK but missing in obs.

When you say native workers, what are you thinking of?

[takimata]

Ah, I just thought you’ve meant that there would be native build hosts in OBS, e.g. aarch64 machines compiling for their respective architecture (just like other Linux distributions which support different architectures by using dedicated build machines for each arch).

[poetaster]

I believe all of these build systems use cross compilers. We (back in the day) used to build ‘build farms’ consisting of clusters of one type (sparcs, decs, etc) of machine to build NetBSD natively. Those were ‘native build hosts’.

But obs and co. do cross compiling as far as I know. obs builds x86, arm32 and arm64 bit. I don’t know what more one could want. For me, it’s great to have so many versions built without extra effort: Show sailfishos:chum:testing / harbour-tidings - SailfishOS Open Build Service

[takimata]

At least Debian still seems to use such a traditional build farm with, e.g., this machine. Don’t know about SUSE’s OBS, though…

[poetaster]

That is so nice. ARM Ltd (hosting) Thanks for the link!

Just snooping around on the suse it seems like they have arm and aarch64 dedicated hosts but I couldn’t find and overview on the quick. EDIT: silly me: Build Status Monitor - openSUSE Build Service the backend workers are hardware, after all.

This is where I first had exposure to ports Platforms supported by NetBSD and, at the time, there was no other way to build but with the hardware.