Re: [gpsd-dev] [PATCH] Various fixes to build for android

[Eric S. Raymond]

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).
-- 
                <a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>

signature.asc
Description: Digital signature