> > This looks like a timezone problem I fixed in psitrext back in Oct of 03 > > but it might be needed the 'FREEZE_TIME' fix I applied in April of 04. > > Hmm, would that have escaped 1.2.4 somehow?
Hmmm. Should be there. Let's knock these down a few at a time. > > (Apparently this system doesn't have libusb installed) It claims to be: [EMAIL PROTECTED]:~/src$ uname -a Linux usf-cf-alpha-linux-1 2.2.20 #2 Wed Mar 20 19:57:28 EST 2002 alpha unknown [EMAIL PROTECTED]:~/src$ cat /etc/issue Debian GNU/\s 3.0 \n \l > Hmm, the main Makefile I'm using already lists: > > INHIBIT_USB=-DNO_USB > > However, we do have libusb on Debian so I could enable USB for all > archs. (No USB deps were specified in our Debian build system, which > could be why inconsistent results are being produced wrt USB.) Well, since I'm guessing you aren't attaching a Garmin GPS via USB (i.e. a 60, a 76, a VistaC, a Quest, etc.) that's not factoring into the actual functioning tests. And I didn't add the libusb code until after 1.2.4 anyway, so unless you update beyond that, the INHIBIT_USB should probably just stay turned on. > > With access to an alpha, I see that problem and have a preliminary fix > > in hand. Give me a day or two for an Official Fix. > > Super! I just committed the fix for that one to the development trunk. The problem with IGC (which, honestly, is a really esoteric format) boils down to every OTHER platform returning this ./gpsbabel -i gpx -f reference/igc1.gpx -o igc -F - | grep 23EA B0421143040678S15036423EA0000000000 B0422453040722S15036423EA0000000000 while Alpha returns this: ./gpsbabel -i gpx -f reference/igc1.gpx -o igc -F - | grep 23EA B0421143040679S15036423EA0000000000 B0422453040722S15036423EA0000000000 the difference is in the first line and is "678" vs "679". The difference comes from latlon2str() in igc.c and the difference seems to be the result of this line: unsigned int lon_min = (fabs(wpt->longitude) - lon_deg) * 60000.0 + 0.5; That failure is the only thing remaining before t'testo' on the top of tree runs to completion on Alpha. > > For discussions sake, is <stdint.h> (yes, I know it's technically a > > C99-ism) considered fair game in the world of portability now? > > Looks like it's been part of GCC since 1997, so it should be quite > portable to Unix/Linux platforms. I spot-checked the platforms I cared about, it's there and I have really simple needs of it. If it causes me problems somewhere, I'll revisit it then. > I know that arm is weird in some respect wrt floating-point, but I don't > know a whole lot about it. I think though that sizeof(whatever) there Depending on the flavor of that weirdness, that could be a problem ranging between big and small. A lot of these formats need to read and writes numbers in IEEE format and then do math on them so that could be bad if any given float or double has a different bit representation on these systems. RJL -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
