[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: Matt
Subject: Re: [gpsd-dev] [PATCH] Various fixes to build for android
Date: Tue, 02 Sep 2014 00:14:04 +1000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.5.0

On 30/08/14 17:30, Samuel CUELLA wrote:

On 08/29/14 20:31, Eric S. Raymond wrote:
Matt <address@hidden>:
There still remains issue 3 below: there are many symbols in libgps
which are needed by libgpsd, but libgpsd isn't linked against

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?
I'm twitchy about this because I dimly remember trying it at one point
and having things break spectacularly on one or more of our target
platforms. But I don't remember where or why.  Groveling through the
change comments has not proved enlightening.

Now that I think about it, though, this problem might have been an artifact
of reverse linkage.  I guess it  might be time to try this again, carefully.
Is there a more careful way to do this than just naively linking libgpsd to libgps, and then fixing whatever fallout (if any) that causes? I can't think of one. We either link or we don't; it's boolean. I volunteer to build a dev environment for whatever platform(s) break as a result of this and then fix it. I feel it's an inherently correct change. No sane platform should punish us for exporting symbols from one shlib and then consuming them from another. Let's hope it was just something to do with now-banished reverse linkage, rather than such a hostile platform.
Alternatively, if we can identify the subset of library modules in libgps
that libgpsd uses, perhaps we can simply add them to the list libgpsd
is built from.
I don't think we can move them from libgps to libgpsd, because some of them are things that applications consuming GPS service need, but those client apps shouldn't be linked against libgpsd (only libgps). I don't think they should be linked into both libraries, because that would needlessly duplicate definitions. That would increase storage footprint, something embedded platforms should dislike. I guess they could be factored out into a new library that both libgps and libgpsd and their applications depend on, but that's an invasive change, which personally I'd rather avoid. Did you mean some other other, fourth alternative? I'm not confident I'm understanding.
The latest HEAD now builds flawlessly for Android. The only remaining
problem is the reverse linking of some symbols, such as unix_to_iso8601,
gps_clear_fix, etc.

These symbols are defined in libgps, used in libgpsd, but libgpsd is not
linked to libgps. The gpsd binary is built against both libs, and it
works on Linux because the linker seems to search all binaries for all
symbols. It rely heavily on the linker to be able to do that reverse or
"full search" linking.

Linking the library which needs the symbols (libgpsd) to the library
which define those (libgps) solves the problem, like in the patch I
Yeah, the naive approach is almost certainly the best here. All too often, clever == brittle.

reply via email to

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