Re: Bug#503144: FTBFS on armel: gsf-scan, ** ERROR **: Compilation trouble with endianess.
On Fri, Oct 24, 2008 at 10:48:08 +0300, Riku Voipio wrote:
> On Thu, Oct 23, 2008 at 10:29:54AM +0300, Riku Voipio wrote:
> > 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)
It's probably easiest to go with a fixed 1.14.8; libgsf upstream development
is fairly calm, but there have probably been a few changes which the release
team is likely to view as potentially problematic.
> 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..
After a "debian/rules build", the test programs can be built through "make
-C build/tests check". They're programs to facilitate testing some features,
but they don't constitute an automated test suite.
To test things, you'd need to write test code for the
gsf_le_[gs]et_(float|double) functions in gsf/gsf-utils.c which are the only
functions relying on G_FLOAT_BYTE_ORDER. For sample code using these
functions, check out the gnumeric sources, particularly the Excel plugin.
Ray
--
I love articles that remind you that one of the ingredients it recommends
playing with is a nasty mutagen.
Timothy introducing "Recombinant DNA For The Home Hobbyist"
http://slashdot.org/article.pl?sid=00/06/18/1316258
Reply to: