[Xen-devel] [PATCH] tools/configure: generate stubs and long-double 32-bit headers if needed

[Ian Jackson <ian.jackson@xxxxxxxxxx>]

Christopher Clark writes ("[PATCH] tools/configure: generate stubs and 
long-double 32-bit headers if needed"):
> The gnu/stubs-32.h and bits/long-double-32.h headers are required to
> build hvmloader but are not always available in 64-bit build
> environments. To avoid introducing a build requirement on 32-bit
> multilib generate versions of them from the 64-bit equivalent header.
> 
> This patch enables the removal of downstream patching that has been
> carried in the Yocto/OpenEmbedded meta-virtualization layer since 2012.

Thanks for this patch.  However, I'm quite doubtful about the
approach.

> +        echo '#include <gnu/stubs-64.h>' >conf-stubs.c
> +        SIXTY_FOUR_HDR=`$CC -M conf-stubs.c | grep '/stubs-64.h$'`
> +        rm conf-stubs.c
> +        mkdir -p include/gnu
> +        cat "${SIXTY_FOUR_HDR}" | \
> +            grep -v 'stub_bdflush\|stub_getmsg\|stub_putmsg' 
> >include/gnu/stubs-32.h
> +        echo \#define __stub___kernel_cosl >> include/gnu/stubs-32.h
> +        echo \#define __stub___kernel_sinl >> include/gnu/stubs-32.h
> +        echo \#define __stub___kernel_tanl >> include/gnu/stubs-32.h

This code seems to be ad-hoc seddery which depends on the details of
the existing header file.  That seems like it is unprincipled and
fragile, to me.

I don't understand why you wouldn't just make a small package or
tarball or something containing the relevant headers and install
that ?

Also, don't you need a 32-bit libgcc too ?

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel