The recently-released x11vnc v0.9.2 adds a --with-system-libvncserver build time option that allows it to be built against a system copy of libvncserver instead of its own copy. As libvncserver is already in the Portage tree and code duplication is generally a bad idea for security and maintenance reasons, I'd like to see the x11vnc ebuild changed to depend and build against net-libs/libvncserver. Note that KDE's desktop sharing component, kde-base/krfb, presently uses an ancient copy of libvncserver distributed with KDE, but will be changed to depend on an external, system copy of libvncserver as well. Reproducible: Always
Hi Eike, sorry for not having responded to your email until now. We have enabled support for building x11vnc against the system libvncserver in the past, but had problems with it. Advice from upstream was to use the included libnvserver, because it is often more recent than the official distribution tarball and contains feature x11vnc relies on. But when upstream now includes an option for it, I guess it's safe to give it another try.
I'll admit to not being well-informed about how the x11vnc/libvncserver project relationship is set up, but the shared 0.9.x version numbers and the fact that they can both be downloaded from the same SourceForge project page would seem to suggest that some kind of synchronization has been achieved by now. I'll drop a note to x11vnc upstream with a pointer to this thread.
Hi, I am the x11vnc maintainer and I also work on libvncserver with bugfixes and feature additions. I was asked to comment on this topic by Eike. I'm not exactly sure what to say. x11vnc is still often a driving force for features added to libvncserver. There is not a sharp, versioned wall set up between them like there is for the libraries outside of my control. Coupling this with the fact that libvncserver was not designed or implemented with ABI compatibility in mind (most interfaces are just bare members of structs instead of function interfaces, and there appears to be no discipline in place to maintain compability WRT these structs for previously compiled apps) suggests to me separating the two components will lead to some hiccups. But I don't think these hiccups will be the end of the world nor will they be frequent. So you are welcome to try it. This is the primary reason I added --with-system-libvncserver so we could at least experiment with what this would be like. However for the safest approach I suggest building non-x11vnc apps, e.g. xen, krfb, directfb to use a single system libvncserver.so. I believe these apps use libvncserver so trivially there is little risk to breakage (once one gets them working, e.g. the case of krfb). But for x11vnc the safest approach is to build it with its co-bundled libvncserver. In practice, this will hardly affect resource use at all (libvncserver is only 200K) and if there is a security hole found in libvncserver, a x11vnc release will be the first place it is fixed. If I had more time and energy I could work to develop and maintain a sharp versioned wall between the two components and that would make distro maintainers happy. But unfortunately I don't.
I'm going to include a local USE flag for the x11vnc package, so that we can conditionally enable building against a system libvncserver.
Sounds good.
Commit as x11-misc/x11vnc-0.9.2-r1
