Re: Bug#503144: FTBFS on armel: gsf-scan, ** ERROR **: Compilation trouble with endianess.

[Riku Voipio <riku.voipio@iki.fi>]

On Thu, Oct 23, 2008 at 10:29:54AM +0300, Riku Voipio wrote:
> The error is coming from gsf-init. Reassigning accordingly.

Thanks for fixing this promptly.

> gsf thinks only vfp enabled arm uses natural endian doubles. However,
> eabi does that as well. As anyone using vfp is also using eabi,
> the correct change is to switch the define.
> 
> I believe libgsf is actually broken on armel on older versions too,
> it just that someone added runtime float detection to gsf-init that
> exposes this br0kenness.

If you (and upstream) agree with my analysis, then the current
lenny/armel version is broken too? In that case, we need to
prepare a upload to testing-proposed-updates (or convince release
team that the upstream release between 1.14.8 .. 1.14.10 consist
only of carefully done bugfixes)

Is there some way to test libgsf double loading? I notice there
is a testsuite in sources, but isn't getting built/run during
build time, and I didn't find a quick way to run it..

> diff -ur old/libgsf-1.14.10/gsf/gsf-utils.c libgsf-1.14.10/gsf/gsf-utils.c
> --- old/libgsf-1.14.10/gsf/gsf-utils.c  2008-07-01 12:56:53.000000000 +0000
> +++ libgsf-1.14.10/gsf/gsf-utils.c      2008-10-23 07:03:25.000000000 +0000
> @@ -73,7 +73,7 @@
>   * mixture.
>   */
>  #define G_ARMFLOAT_ENDIAN 56781234
> -#if defined(__arm__) && !defined(__vfp__) && (G_BYTE_ORDER == G_LITTLE_ENDIAN)
> +#if defined(__arm__) && !defined(__ARM_EABI__) && (G_BYTE_ORDER == G_LITTLE_ENDIAN)
>  #define G_FLOAT_BYTE_ORDER G_ARMFLOAT_ENDIAN
>  #else
>  #define G_FLOAT_BYTE_ORDER G_BYTE_ORDER
> 
> 
> -- 
> "rm -rf" only sounds scary if you don't have backups

-- 
"rm -rf" only sounds scary if you don't have backups