Re: [Notion-devel] Shared vs. Static

[Dima K. <no...@di...>]

jef...@gm... writes:

> Hi Dima,
>
>
> On 01/18/2014 05:27 PM, Dima Kogan wrote:
>> Hi Jeff. I looked at the (debian) packages, and those libraries are 
>> linked into more than just the notion executable. There're a few more 
>> executables (ion-statusd, ion-completefile, etc). So yes, those 
>> libraries should be shared. Otherwise (with static linking), there's 
>> no reason to ship the libraries in the package, so static linking 
>> shouldn't be a huge problem for Fedora. I suspect they strongly oppose 
>> shipping static-only libraries, which the packages need not contain 
>> anyway. The resulting duplicated code is less than ideal, but this 
>> shouldn't be a deal breaker. Am I missing something? dima 
>
> Ack, sorry I should have clarified. This is with regard to a devel 
> package. The normal notion package doesn't raise any eyebrows, but the 
> devel package does. I could probably make everything go much more 
> smoothly by dropping the devel package. I figured a devel package was 
> necessary in case users wanted to compile 3rd party modules, etc. I 
> guess I should ask - has this been an issue elsewhere?

Ah. It all makes sense now. For some reason the debian -dev package
doesn't contain libraries at all; just headers. This could be a mistake.

As for shared/dynamic, just making the libraries dynamic won't solve
your problem. Libraries with names like "libmainloop" pollute the
namespace too much for something that has a very narrow purpose (it's
only for notion, not likely to be used by anything else in the system).
So what one SHOULD do is to ship the DSOs in /usr/lib/notion, and do
some sort of RPATH thing to let their users find these. Debian is OK
with RPATHs for this purpose. Fedora like is too.

If I were you, I'd punt on libnotion-dev for now, to let upstream handle
this more nicely first.

dima