[Box Backup-dev] tests passing on i386

[Martin Ebourne]

On Tue, 2005-12-20 at 23:05 +0000, Ben Summers wrote:
> Maybe. I suspect endian issues for the raidfile on 64, or perhaps  
> word length. It does some quite complex stuff to store files without  
> using excess blocks on discs, doing stuff like ZORing the length into  
> ends of files and the like. All good fun.

I've just found the issue with raidfile on x86_64 FC4. It started with
the autoconf patch which changed from using the native hton64 (stolen in
an unpleasant manner from the kernel header file) to the box_swap64
function.

Although the function appears to look and work perfectly ok, apparently
there is a compiler bug with the inlining. If I make this change in
Box.h:

-inline uint64_t box_swap64(uint64_t x)
+static uint64_t box_swap64(uint64_t x)

Then it all magically works. This also explains why it has only broken
now - when I wrote that patch and tested it before it was on FC3, which
was gcc 3.4. FC4 is using gcc version 4.0.2 20051125 (Red Hat 4.0.2-8).

I don't intend to do anything directly about that. I do plan to look at
getting configure to find a built in swap64 instead though, which will
hopefully fix it indirectly.

This of course will make no odds to raidfile on PPC because that is big
endian anyway. I can't directly help with those failures because all my
machines are AMD64 only.

> Also, sys/mount.h isn't detected by autoconf, even though it does  
> exist. Editing lib/common/config.h to #define the HAVE_SYS_MOUNT_H  
> does make everything compile OK. I shall attempt to work out why  
> that's happening.

Most likely has a header it is dependent on. From the autoconf manual
describing AC_CHECK_HEADERS:

           Previous versions of Autoconf merely checked whether the
        header was accepted by the preprocessor.  This was changed
        because the old test was inappropriate for typical uses.
        Headers are typically used to compile, not merely to preprocess,
        and the old behavior sometimes accepted headers that clashed at
        compile-time.  If you need to check whether a header is
        preprocessable, you can use `AC_PREPROC_IFELSE' (*note Running
        the Preprocessor::).
        
           This scheme, which improves the robustness of the test, also
        requires that you make sure that headers that must be included
        before the HEADER-FILE be part of the INCLUDES, (*note Default
        Includes::).  If looking for `bar.h', which requires that
        `foo.h' be included before if it exists, we suggest the
        following scheme:
        
        AC_CHECK_HEADERS([foo.h])
        AC_CHECK_HEADERS([bar.h], [], [],
        [#if HAVE_FOO_H
        # include <foo.h>
        # endif
        ])
        
The Linux man page doesn't give a dependency, but maybe OpenBSD has one
where Linux doesn't.

You can get more clues by looking at config.log. Search for 'checking
for sys/mount.h' then see if there is a section immediately following
which starts 'configure: failed program was:'. That gives you the
program it tried to compile, and you should see the error message from
the compiler too.

Cheers,

Martin.