gpsd-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [gpsd-dev] Half the port problems are solved; seeking help with RTCM


From: Eric S. Raymond
Subject: Re: [gpsd-dev] Half the port problems are solved; seeking help with RTCM2 driver
Date: Wed, 25 Apr 2012 03:48:51 -0400
User-agent: Mutt/1.5.21 (2010-09-15)

Bernd Zeimetz <address@hidden>:
> armel: no regressions
> armhf: no regressions
> hurd-i386: no regressions
> i386: no regressions
> ia64: no regressions
> kfreebsd-amd64: no regressions
> kfreebsd-i386: no regressions
> powerpc: no regressions
> ppc64: no regressions
 
Excellent.  That is bit-for-bit identical handling of binary protocols
on quite a range of architectures, endiannesses and word sizes.  Not a
small achievement!

> It would be nice if the regress-driver would just fail if there is a pty issue
> instead of spitting out a  lot of diffs.

I agree.  Can you think of a way to test for this from a shellscript?

> Where ever the issue is, it doesn't seem to be related to endianess issues.
> Sparc, s390 and s390x (the 64bit s390 port) seem to be the only architectures
> with issues so far.

Yes, as I said I'm pretty sure this is down to #pragma pack(1) not being
implemented on those machines.
 
> As you can see on
> http://buildd.debian-ports.org/status/package.php?p=gpsd&suite=sid
> we even have some really exotic unofficial architectures - unfortunately not 
> all
> build-dependencies are available there. If there is an interest in making gpsd
> build on one of the listed architectures, please let me know (I think the main
> issue is QT not being available...).

alpha, hppa, sh4, and m68k would be good checks to have.  Missing Qt is
not a problem for the regression tests; that only affects the client side.
-- 
                <a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>



reply via email to

[Prev in Thread] Current Thread [Next in Thread]