Re: [gpsd-dev] libgps?

[Bernd Zeimetz]

On 03/24/2015 09:44 PM, Eric S. Raymond wrote:
> Bernd Zeimetz <address@hidden>:
>> As mentioned before, if libgps is being statically linked, I'll
>> remove gpsd from Debian. I can live with a statically linked
>> libgpsd, doing so is just a waste of memory, but nothing
>> problematic. Having a static libgps only means, that for every gpsd
>> upload I need to get kde and all other dependencies rebuilt. That is
>> nothing I will accept nor (I can't speak for them, but I'm sure
>> about that fact) will the release and security teams accept such a
>> broken library usage.
> 
> I think you misunderstand. The plan is *not* for there to be only
> a statically-linked libgps. The shared libgps will still be exported
> and third-party programs will still see it.

So you have gpsd and tools linked statically and you have a shared library which
is not used by them because the build system is a mess? Sorry, but that is the
very most insane and stupid idea I've ever seen since I'm using open source
software.

There are a lot of upstreams fighting with getting shared library handling done
properly. Some succeed because they know how it works, some fail to understand
what sonames are for. But so far I've not seen a single project which is too
stupid to use its own shared libraries. I even have a project which uses a hand
written and optimized make file as build system - and even that is able to do a
more sane handling of its libraries.


> No, the change is to link (only) GPSD's *own* binaries with a local
> static copy of libgps.  In practice this would be very low overhead,
> as only about 4 libgps modules are used at the lower level for a total
> code volume of about 21K.

So at the end a proper function of libgps  (the shared one) is never ever being
tested?
Also you are wasting a lot of memory, libgps21 is 119k. There are fore sure
platforms where you want to avoid that.

> In return, we get to deep-six the shared and chrpath build options, 
> toss out all screwing around with RPATH/RUNPATH/LID_LIBRARY_PATH, 
> and remove chrpath as a build requirement.

Again, the only proper way to fix this mess is to fix the build system.
Everything else will end in putting even more pieces of duct tape on messed up
piece of shit.

The only option I see is to take autotools or cmake, both systems which are
known to handle cross-building and 99,99% of distribution issues very well, READ
THE F*CKING DOCUMENTATION, re-structure the project according to the
documentation and rewrite the build stuff from scratch.

How much more time do you want to waste?
Even writing this and other mails and people replying to them is an insane
amount of wasted time which would be better spend in fixing gpsd issues instead
of trying to work around problems you would never ever have if you would use
SANE buildsystems in a way how they were intended to be used.


-- 
 Bernd Zeimetz                            Debian GNU/Linux Developer
 http://bzed.de                                http://www.debian.org
 GPG Fingerprint: ECA1 E3F2 8E11 2432 D485  DD95 EB36 171A 6FF9 435F