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
%define bitsize 32

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"

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.

3 thoughts on “From a diary of AArch porter – part II”

  1. Thanks for the hint.

    You might want to talk about that with the Fedora Packaging Committee, they might decide to improve the packaging guidelines, so that this sort of things doesn’t happen any more in the future (or at least, less often).

    Also, just a nitpick: don’t use %define, use %global

    The difference between the two is very subtle, they do almost the same thing, until your build starts failing in weird ways. ;-)

    Comments are closed.