CEC 3.0.1 has a serious segmentation fault error (debian bug #798190) on platforms without /sys/class/drm . This is, I believe, affecting cec on the Pi2 November update, as the Pi2 does not have /sys/class/drm. It appears a bugfix has made it into libcec, but it also appears that this has not made it into osmc? At least I am getting a CEC segmentation fault under very similar circumstances, (after hackfixing for the fact that libcec.so is in the wrong place).
We don’t use the debian version of libcec - we compile our own and distribute it as rbp2-libcec-osmc and so on. We always have done.
The library is not in the “wrong place”, we now ship osmc libraries in /usr/osmc/lib precisely so that they don’t conflict with debian libraries. Kodi is compiled with an rpath to search /usr/osmc/lib before the usual library locations.
We are aware that this has currently broken the cec-client app but that is a different issue to what you are seeing and we are working on resolving that.
If your CEC did not work at all without changing the location of the cec libraries it means you are not running an up to date Kodi build therefore Kodi does not have a compiled in rpath.
Yes this is a different issue from the library location. (Sorry I used the term “wrong place” not to imply an error, but to indicate that I had circumvented the issues that the libcec.so is not in the location expected by the linker. Kodi may be compiled to /usr/osmc/lib, but osmc does not currently have this as a standard library location.) I am using libcec independent of kodi, and hence this is nothing to do with kodi.
The error is a segmentation fault on libcec when Open(port.c_str()) is called in LibCeCInitialise. This code worked fine on 3.0.0, but does not with 3.0.1 As this fault was described in
I thought this related. It is not particularly a debian issue but a libcec issue, but was first noticed on a debian environment as linked above. OSMC is pulling the libcec source from the libcec 3.0.1 archive
https://github.com/Pulse-Eight/libcec/archive/libcec-3.0.1.tar.gz
which does not appear to have the above fix (#133) in it, AFAICS in src/libcec/platform/drm/drm-edid.cpp. That said, this does not appear to be causing any trouble in kodi, so that is confusing.
Yes this is by design, and is not an oversight. The whole point of /usr/osmc/lib is so that certain specific applications (only Kodi at the moment AFAIK) can be compiled to search this additional library path first for custom builds of those libraries.
This means we can ship a custom build of, for example, libsqlite3 that is optimised for Kodi performance, independent of any Debian version that the user may have installed for other software, and without our custom build conflicting with or affecting that other software relying on libsqlite3 in any way.
If we were to add /usr/osmc/lib to the system linker search path we would be back to square one again where our custom version of certain libs is picked up by other software that may be expecting the standard debian version of those libs.
I’ll let Sam reply to your other points because he’s far more expert than me on the subject.
Thanks. That clarifies. Although my custom software was expecting to pick up the standard osmc version of libcec as previously, and broke because it couldn’t :). You can’t win :).
For cases like libsqlite3 we definitely do not want any other applications using our custom build of the library - because we want to make build time optimisations that may be dangerous for other use cases than Kodi. There are some other libraries we potentially want to do the same with.
The separate library path that only applications specifically compiled to use is a clean solution to this - we put this library in our own package, only Kodi will use our version of libsqlite3, all other programs will use the normal Debian provided version of the library in the normal path in the normal package, and the user (or other packages by dependency) are free to install and use the standard version of the library.
Libcec is a bit of a different problem though - cec-client is broken due to an oversight with the library paths and we will fix that soon, however you also have the issue you pointed out where you might want to build other software against libcec, and that is a more thorny issue. There are only really two choices I can see: (but I’m no expert on this)
- We move our custom libcec package back to the standard library paths. This would fix cec-client (although this is not the only way to fix it) and would allow other programs to build against the libs again.
This also brings back a problem we had before - we once again conflict with the standard debian libcec package, and some other 3rd party software will try to pull that package in as a dependency. We can put a “Provides” in our package to say that we provide the same “service” as the libcec package, but unfortunately due to a limitation in apt/dpkg you cannot satisfy a versioned dependency using provides. 
What this means is if some third party package specified Depends: libcec it would work fine, but if it specified Depends: libcec (>= 3.0.0) it would fail even if our library was the correct version as the Provides can’t specify what version of the package we emulate. This would prevent installation of that 3rd party software, at least via apt/dpkg. (You could still manually compile it)
- We could fix our build of cec-client to use /usr/osmc/lib path for itself, and just allow the user (or any 3rd party package) to install and use the standard Debian libcec. The drawback here is any custom fixes/patches that we implement in our libcec would not be available to software linked against the standard libcec libraries.
I’m not sure what approach Sam is thinking of to solve these issues but it’s certainly something that needs solving. Both approaches have drawbacks as far as I can see.
We need to know where we are here. Some decision needs to be made as we are currently in limbo and have been for a little while now:
Is the osmc version of libcec only for kodi, or supported for osmc? If the latter, there appears to be a critical bug update that needs implementing (as above), but besides that and the relevant linking we would be all good to go.
If osmc libcec is just for kodi, then what is the accepted install for all other parts of the OS? Is there an osmc supported package for this? If not what is the expected mechanism people should use for all other (non-kodi) packages that need libcec?
I guess I would prefer libcec to be patched with the recent patch and considered supported for now. If a split is made later, then fine but at the moment it has just broken things and is preventing software releases as we are all in limbo.
There is an OSMC package for libCEC called libcec-osmc. It’s your choice whether you want to link against it. I’d recommend you do.
The segfault (due to lack of /sys/class/drm) issue will be resolved in the next OSMC monthly update.
Thanks. libcec-osmc is not listed in the cache. rbp2-libcec-osmc is the currently installed /usr/osmc/lib version. There is libcec2 and libcec-dev, but those are back at v2.
Anyhow thanks for the update. It is clearer what the plan is now.
Amos
The segmentation fault has now been addressed and will be in the next update.
Sam