ukyg9e5r6k7gubiekd6 <address@hidden>:
-Library symbols and linking --By default, gpsd doesn't
explicitly links libgps (Tried imloads with no luck as well).
This results in unix_to_iso8601 being UND. Android Linker fails
to link gpsd binary because of this. Patched SContruct to
explicitly link libgpsd against libgps.
This makes me nervous. I want to look for a less intrusive way to
fix the problem you're seeing.
I too saw this under mingw. I came up with some fix but I forget what
I did now. I'll have a look at my diffs.
I'd like to see another patch from you, improving the Android port,
that addresses this issue.
Note, I believe I've fixed your sys/select.h issue in the masters. It
looks to me like the library you're using has a sys/time.h that is not
SuS-compliant; if it were, this wouldn't be an issue.
--Moved gpsd_write and gpsd_report from gpsd.c to libgpsd_core.c.
The library libgpsd uses these symbols from gpsd whereas it
should be the other way around if libgpsd was to be used by
another binary. These symbols are marked UND which makes the
android linker to fail loading gpsd binary.
Alas, this patch is flat wrong; it violates the way the code is
layered. These functions are callouts from the library that are
*intentionally* defined different ways by different binaries. We
need to find a way to beat your linker into doing the right thing
here.
I wouldn't really call it layering since it's a bi-directional
dependency. More like an unhealthy co-dependency of the sort that
psychiatrists warn against :-)
Eh? There's nothing odd or co-dependent about hook functions being used
in a library. The intent is to allow applications to specify their
own reporting functions for errors encountered by the library.
The approach I took in the mingw port, and which I think is superior
to attempting to make the linker do what you consider to be the Right
Thing on all platforms and all weird linkers, was to add some function
pointers with sensible default values into libgpsd_core.c, then add
some entry points into libgpsd that let the calling binary set those
function pointers to those it supplies, if and when it wants to.
This is probably buried in a whole lot of other unmergable/confused
crud in my mingw fork, but I can dig it out into a separate diff if
someone wants.
I'd like to see this patch.
I second the motion to have a header which does nothing but define
HAVE_* constants - does not include any other headers, nor do any
typedefs nor macro definitions nor declarations nor anything else.
Call it gpsd_config.h or anything else. My preference would be for
'config.h', but what's in a name?
I believe there exists a legitimate need to find out what the
underlying system does and doesn't have (ie what Sconstruct found),
without also pulling in random other headers that could cause trouble
or even merely slow compilation.
As a specific example, on mingw, anything that pulls in windows.h
incurs large parse overhead and lots of namespace pollution; and
almost all Windoze headers of interest pull in windows.h sooner or later.
Gotcha. It's a good idea. Might not happen before 3.11; I'm trying to get
that out quickly, in time for the next Debian freeze, and am thus avoiding
code changes that can easily be deferred (that is, other than bug and port
fixes).
factor-out-library-upcalls.patch