gpx export and location

[Olly Betts]

On Wed, May 06, 2020 at 10:18:32AM +0200, Lojze Blatnik wrote:
> I think, that you didn't understand the point, or I didn't express myself
> correctly. I get incorrect output if I use package from 20.04 (without any
> hacks). Ubuntu 18.04 doesn't ship with survexport command, that's why I did
> this hack and it works! I know about ABI compatibility, but it doesn't work
> with missing library (printed by ldd), and it works with linking the
> available one.

My point is that is may "work" but not actually work correctly.  For
example if a function in the API changed from some_func(int) to
some_func(long long) then the ABI likely isn't compatible (whether it is
or not depends on details of the calling convention for the platform
in use), but with a hack like yours the program will run because C ABIs
don't encode the parameter types (unlike C++, where you'd probably get
a "symbol not found" error for this case).

Depending what the changes which resulted in the ABI bump are, and
whether Survex uses anything affected, it's possible it might actually
work, but you can't know for sure without a detailed analysis of the
ABI differences, so avoiding this hack seems a better plan, especially
as there's a survex package for Ubuntu 18.04 with the survexport command
available from the same place you got the survex package for 20.04 which
you're hacking to work on 18.04.  There's no good reason to be hacking
the 20.04 version to work on 18.04, and good reasons to avoid doing that.  

I'd missed that the problem was the other way around though.

> So if I conclude, this hacky solution works (discovered by accident), but I
> was wondering what would cause that the default 20.04 setup outputs
> incorrect .3d or .gpx. Is it possible that some system settings or
> environment variables make the difference?
> 
> Attachment: https://we.tl/t-x951P5xzvb

That site requires agreeing to their ToS just to download, but Matic has
sent me the files by email - I'll take a look.

Cheers,
    Olly