Tag Archives: redhat

From a diary of AArch porter –- testsuites

More and more software come with testsuites. But not every distribution runs them for each package (nevermind is it Debian, Fedora or Ubuntu). Why it matters? Let me give example from yesterday: HDF 4.2.10.

There is a bug reported against libhdf with information that it built fine for Ubuntu. As I had issues with hdf in Fedora I decided to look and found even simpler patch than one I wrote. Tried it and got package built. But that’s all…

Running testsuite is easy: “make check”. But result was awesome:

!!! 31294 Error(s) were detected !!!

It does not look good, right? So yesterday I spent some time yesterday on searching for architecture related check and found main reason for so big amount of errors — unknown systems are treated as big endian… Simple switch there and from 31294 it dropped to just 278 ones.

Took me a while to find all 27 places where miscellaneous variations of “#if defined(__aarch64__)” were needed and finally got to point where “make check” simply worked as it should.

So if you port software do not assume it is fine once it builds. Run testsuite to be sure that it runs properly.

AArch64 is in the house

Today FedEx courier delivered me a package. Inside was APM Mustang in 19″ rack case.

I unpacked, grabbed all required cables from my cable boxes (power, Ethernet, serial), connected it and booted. It arrived at very good moment as we are in a middle of Fedora 21 mass rebuild so I do not have to use remote machines anymore.

Will not write about technical details cause those are already known (8 cores, 16GB ram, SATA storage, 1GbE networking). Do not expect benchmarks as I am not allowed to publish results. If you want to compare build speed then go to Launchpad and check how long it takes to build Ubuntu packages for arm64 target.

My plans for machine? Run Fedora rawhide, fix building issues. I also plan to play with virtualization to check how Ubuntu and Debian work.

From a diary of AArch porter – part II

In previous part I wrote about code managing issues. Today I want to write more about packaging and other ugly things.

Each time I see block with check for 32/64 architecture I want to scream. Funny part is in RPM packaging. For example:

%ifarch x86_64 ppc64 s390x sparc64
%define bitsize 64
%else
%define bitsize 32
%endif

Can be replaced with simple “%define bitsize %__isa_bits” so we would not have to patch yet another spec file.

But developers are smart — always can create some nice way of fsck such thing up…

if test $ax_arch = x86_64 -o $ax_arch = ppc64 -o $ax_arch = s390x -o $ax_arch = sparc64; then
    libsubdirs="lib64 lib lib64"
fi

This is from configure of one of libraries which failed to find boost version (as it did it by scanning library paths).

Such issues are fun. Especially when component builds fine with wrong value and then all packages which depend on it fail in some weird way.

But sometimes they fail in a way that it is cleanly visible what was wrong. ORBit2 is good example:

DEBUG: /usr/include/orbit-2.0/orbit/orbit-config.h:9:30: fatal error:
orbit-config-64.h: No such file or directory

Everyone see that something is fishy with ORBit2 here. One small patch (similar to %ifarch example) and then all it’s dependencies build just fine.

So if you are software developer and have such 32/64 checks in your software please consider doing it in a way that another 64bit architecture will not have to patch your code again.

My own company started 8th year today

Seven years ago I created my one person company. And it was one of best things I did in my life.

All started in 2006 when I started doing some small paid jobs around OpenEmbedded. Small things: solving build problems, updating recipes, adding new ones. But companies prefer to get invoice for such stuff instead of just giving money…

So one day I went to city hall and created what was then called “HaeRWu Marcin Juszkiewicz”. I changed name 2 years later and got rid of that ‘impossible to pronouce’ part.

There were many different clients for my consulting work. CELF was my first one, later I dropped my daily work and started remote work for OpenedHand. When they were acquired by Intel I got quite nice offer but preferred not to move to UK so went own way. From time perspective I do not know was it right decision ;)

So I looked at market around OpenEmbedded and started working with Bug Labs and few smaller jobs for other clients (some knew me from OpenedHand times). Also had job proposal from Canonical for their newly created ARM team but nothing came from it.

Time passed. One and half-year later Canonical made another attempt and this time I though “why not?”. So I went there just to be moved outside to a team which did not have any official name (other than NewCo or New Core which you may heard somewhere). And that team became Linaro some days later.

At Linaro I did lot of cleanup in Debian/Ubuntu toolchain components, added bootstrapable cross toolchain and fixed several packages (also created some new ones). But then, just when I was supposed to move to Canonical, new things came and AArch64 took my whole time.

ARMv8 work was great time. Learnt new things about OpenEmbedded, saw how project moved during those two years when I did not follow it’s development. Och it was good time.

But good things have to end one day. And so did my time at Linaro. But at around same time I started talking with several companies around Linaro to find a new place for me.

And I found it at Red Hat. Took a bit of time to get everything set up but I think that it was worth it. But due to the fact that I am employee not contractor I will suspend and in few months shutdown my consulting company.

It served me well. I came from being person not recognizable to someone who is known by people who I see for first time. It is good feeling ;)

RedHat and real AArch64 hardware today

In around 3 hours from now Jon Masters from RedHat will have first live multi-node cluster 64-bit ARM silicon demo running Fedora. On real hardware…

It amazing how it went from new architecture announcement though simulators, boostrapping distributions to running those on real hardware. When I was working on AArch64 we were said that it will take one more year before we see devices not emulators or FPGAs (which I heard were slower than simulator).

I hope to work on AArch64 support again — one day in a future.

BTW — there will be no live streaming but Jon wrote that there will be video posted in short time after.