gpsd-dev
[Top][All Lists]
Advanced

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

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


From: Matt
Subject: Re: [gpsd-dev] [PATCH] Various fixes to build for android
Date: Fri, 29 Aug 2014 23:00:00 +1000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.5.0

Eric, your approach to removal of the "reverse linkage" is much cleaner than my addition of file-static function pointers. FYI I am also not a fan of file-static data; I was merely attempting a minimally-invasive patch. A good outcome in any case.

There still remains issue 3 below: there are many symbols in libgps which are needed by libgpsd, but libgpsd isn't linked against libgps.

One consequence: if you want to dlopen() libgpsd for some reason, you need to dlopen() libgps first; whereas if libgpsd were linked against libgps, the runtime linker would load libgps automatically for you when you dlopen()'ed libgpsd.

Attached is a program that does this, to show the hoops such a program has to jump through. I'm not claiming the program is inherently useful in any way at all, nor even a good idea :-)

Why is it drastic and/or incorrect to simply link libgpsd against libgps?

The only valid reason I can think of *not* to do this would be if some app wanted to use libgpsd, but didn't want libgpsd's undefined symbols to be satisfied from libgps. For example, maybe it wanted to supply its own definition of every one of those symbols.

Problem is, I can't imagine why an app using libgpsd would validly want to do this. For example, why would it want to have its own private implementation of gpsd_hexdump, and what's more, to have libgpsd use this private implementation rather than the version in libgps? If the app's implementation of hexdump were really that hot-to-trot, it should replace the version in libgps.

I think I'm missing something fundamental about how these libraries are intended to be consumed by applications.

On 27/08/14 03:21, Eric S. Raymond wrote:
Samuel CUELLA <address@hidden>:
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.
Careful. "Client" doesn't mean "GPS client" here; this is strictly
an internals issue for gpsd/gpsmon/gpctl.
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.
Simplifying the requirements for the linker is the kind of benefit I
was looking for.  OK, I'll merge it and document it on that basis.

Attachment: test_dlopen.c
Description: Text Data


reply via email to

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