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.
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
solving?