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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
