[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Samuel CUELLA
Subject: Re: [gpsd-dev] [PATCH] Various fixes to build for android
Date: Tue, 26 Aug 2014 16:36:53 +0200
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:24.0) Gecko/20100101 Thunderbird/24.1.1

On 8/26/14 11:06 AM, Eric S. Raymond wrote:
Samuel CUELLA <address@hidden>:
fd_set was needed in gpsd.h for gpsd_await_data. Including <unistd.h>
fixes the problem. In fact the bug is still present but shadowed by
another part of the patch you've merged: In SConstruct, HAVE_GETSID not
defined adds "#include <unistd.h>" along with getsid prototype in gpsd.h.

I'll add a fix for that in the next round.

I think you'll find I've already fixed this.
ok, found it.

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.

It seems that I just didn't got the intent.You're using symbols in the
library that the "client" executable *must* provide and you rely on the
linker to do the library used -> executable defined linking.

Is that documented somewhere? Would you agree on using a different
approach, like defining function pointers to be filled-in by the client
code if needed (and maybe a default implementation)?

P.S: I've seen comments and a patch from Matt about that too. I'll try
it on Android to see if that works (guess it will). Do you agree with
that direction ?

The patch doesn't seem wrong to me, but I don't see any advantage from it
either.  We can't make the dependency go away, the best we can do is get cute
about how it's expressed.  Where's the gain?  What problem is Matt's patch

I see three problems here:

1°) There is non-obvious requirement on the client code which wants to link against libgpsd: define the missing symbols.

2°) The way it's currently implemented makes a strong assumption on the linker being able to "reverse link" the executable and the library.

3°) The library has UND symbols, and these symbols are not defined in a another shared library that first library is linked to.

Using explicit function pointers will make the requirement/feature more obvious to the client code, will not make any assumption on the linker and will not let UND symbols on the so.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]