Both of these work for me on Centos 6, Qt 4.6.2, r4645.  Is this a windows only issue?  Specific to some version of Qt?
[tsteven4@boobear native]$ cat reference/basecamp.gpx | ./gpsbabel -i gpx -f - -o gpx -F /tmp/basecamp~gpx_si.gpx
[tsteven4@boobear native]$ view /tmp/basecamp~gpx_si.gpx
[tsteven4@boobear native]$ ./gpsbabel -i gpx -f - -o gpx -F /tmp/basecamp~gpx_si.gpx 0<reference/basecamp.gpx
[tsteven4@boobear native]$ view /tmp/basecamp~gpx_si.gpx

On 11/10/2013 5:11 AM, Gerhard Olsson wrote:
> * Problems with testo gpx with standard input is due to the test syntax. Normal stdin works fine.

Providing a patch that fixes the problem
I do not suggest that the patch is merged, it is a hack and will only make Robert depressed. But maybe someone finds this on the mailing list.
What I find in the Qt documentation is that atEnd() should be set if hasError() is true, this does not occur here.

So this does not work, reader->readNext(); constantly returns "".
debug/GPSBabel.exe -i gpx -f - -o gpx -F f:/Temp/gpsbabel.10752/basecamp~gpx_si.gpx 0< reference/basecamp.gpx

cat reference/basecamp.gpx| debug/GPSBabel.exe -i gpx -f - -o gpx -F f:/Temp/gpsbabel.10752/basecamp~gpx_si.gpx

On Sun, Nov 10, 2013 at 12:11 AM, Gerhard Olsson <> wrote:
More MS Visual Studio:

* #ifdef for #include in xmlstreamwriter. MS uses include from the directory where the compiled file is located, not where compile is started from. (this for once a syntax I prefer)

* Some weird #ifdef limitation (related to NEW_STRING) in csv_util.
No dramatic change

* Slightly updated README.msvc file. I suggest the file is put in the gpsbabel directory and that the msvc directory is removed. (As that project file is not maintained)

* Problems with testo gpx with standard input is due to the test syntax. Normal stdin works fine.
And to comparing dates: strftime behaves differently in MSVS and other (I compare with Cygwin, where tests mostly passes).
Where Cygwin gives Thu Jan  1 00:00:00 1970, MSVS gives  01/01/70 00:00:00.
It does not matter that default locale is "C" and that locale is normally written "en-US" (instead of en_US) using setlocale() when the result will not match anyway.
Of course, GPSBABEL_FREEZE_TIME can be used (with _MSC_VER) to handle this, but this affects a lot of code (degrading other code).
I currently suggests that MSVS is kept as "development" only, not for production/tests. It is probably me that primarily uses MSVS anyway (a patched version with garmin.c lap_read_as_track() active as my GF305 has some HW problem).
Obviously, no further investigation if rounding handling can be improved.


On Fri, Oct 4, 2013 at 12:51 AM, Gerhard Olsson <> wrote:

>> below

On Wed, Oct 2, 2013 at 10:50 PM, Robert Lipe <> wrote:
Rounding is just a mess.  I don't have a great solution to that. Chasing sub centimeter location differences across OSes is pretty silly.  Maybe we need a better way to test this stuff.  Ideas welcome.
>> The reasonable for non binary is to round output. For binary formats there is no solution except keeping separate result files... Phew....

You can't imagine how badly I don't want to do that.
>> I believe I can, but that is probably not

Maybe we just say that Cygwin is the only reasonable way to get results that match with testo on Windows.   After all, you need Cygwin to run the shell script anyway, right?
>> For sure, I test with the Cygwin build. I just wanted to give the status for MSVS, what works and what dont.

I know this is what results in that alien look I get when I ask the contributor of a new format (that has ^M's at the end of all the lines) for a test case we can slam into testo, but in nearly every case, given a sample file we can round trip it through GPX and get coverage that's usually "good enough".
Didn't we force testo to run in US.UTF-8 pretty much for you in r4525?  Did this not help?
>> Helps for Cygwin, not honored in native Win apps.  I have not looked for a substitute.

Is there a 'setlocale' in Win32?  Maybe we do 
if getenv("GPSBABEL_FREEZE_TIME) setlocale(...
That's kind of an unfortunate way to communicate this to the executable, but that's the hammer we have.
>> Something like that, yes. I plan to look at it

November Webinars for C, C++, Fortran Developers
Accelerate application performance with scalable programming models. Explore
techniques for threading, error checking, porting, and tuning. Get the most 
from the latest Intel processors and coprocessors. See abstracts and register

Gpsbabel-code mailing list