[Top][All Lists]
[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>