add libunity to LD_LIBRARY_PATH

[paroj]

No description provided.

[didrocks]

Thanks for this patch! However I'm not in favor of merging it: those 2 subdirectories are private libraries protocol. They are not supposed to be available to clients. Real libunity library, supposed to be consumed by client is /usr/lib/<ARCH>/libunity.so.9. Gsettings is simply glib.

On a classic system, those are even not exported to the client. The only exceptions (which are also in the launcher) are mesa and mesa-egl.
/etc/ld.so.conf.d/*-linux-gnu_*GL.conf contains on my machine:

/usr/lib/x86_64-linux-gnu/mesa-egl
/usr/lib/x86_64-linux-gnu/mesa

There are such, considered public library and should be exported.

[paroj]

I must admit that private, shared libraries sounds conceptually wrong to me.
Anyway they must be available to the client as some public library (transitively) depends on them.

This is what happens in the linked launchpad bug.
Unity-7.0.typelib -> libunity-protocol-private.so.0 -> libunity.so.9
with the latter not being on the LD_LIBRARY_PATH.

I also do not understand your concern as normally snapcraft would set the LD_LIBRARY_PATH in this exact way inside its .wrapper script.

[didrocks]

Yeah, but it does it in a public path (as the launcher do)! Not inside a private one.
However, the transitivity needs to be looked at indeed. I need to look again at the linker code to understand how it finds the private libs from the public ones (it doesn't seem to use relative paths or it would have find it).

I'm going to dig into this next week.

[didrocks]

Ok, I just added pulseaudio after the runtime refactoring. Do you mind redoing the same with libunity and we integrate it? Thanks!

[didrocks]

Mind removing this blank line now that you merged with master?

[paroj]

was using github GUI for merging. now that I had to checkout i rebased on master removing that blankline

[didrocks]

Perfect! Let's merge it, thanks :) 👍