[Interest] Qt5, XCB and X11

[Lachlan.Hetherton at csiro.au]

Hi again all,

Thanks for the comments so far. Before I address questions that have been
asked, it sounds like I need to provide a bit more context. We are
building against the LSB 4.1 SDK because it (supposedly) provides an
interface that is likely to exist on as many linux distributions as
possible. In principle, this is supposed to save us a great deal of time,
as we can build *one version* of our application, and ship it to many
distributions. If it works, this approach can save us a lot of maintenance
overhead.

I acknowledge that XCB is *not* part of LSB4.1, and so no package we
provide will be truly LSB compliant unless we also ship LSB compliant
versions of the XCB libraries. I know I do not need to ship the XCB
libraries for newer distributions, as although XCB is not part of the LSB,
I have confidence that enough newer distributions provide it. However, as
discussed, the oldest distribution we need to support (SLED11) doesn’t
provide up-to-date XCB libraries, hence my question, "is it OK to ship
LSB-compliant versions of the xcb libraries with my application for this
older distribution, noting that shipping an updated libx11-xcb requires
shipping libX11 itself?"

In response to a number of specific questions that have been asked:

1. RE: GTK/xcb - As Thiago stated, the version of GTK shipped in the LSB
(at least the LSB4.1 version) does not depend on XCB.

2. When I say that I can’t build Qt5 on SLED11, I mean it is not possible
to build Qt5 on SLED11 without also building numerous dependencies (some
dependencies exist on the system, but they are very out-of-date). As
stated above, we’re actually building against the LSB4.1 sdk, not the
libraries native to SLED11 anyway.

3. When I say that we have built an “LSB Compliant” version of Qt5 and our
application, I mean that we have:

 - Compiled (with lsbcc and lsbc++) Qt5 as well as any Qt5 dependencies
that either a) don’t exist at all in the LSB v4.1 or b) exist in the LSB
but are not up-to-date enough. This way, we have available LSB compliant
versions of _everything_ we need.
 - Generally, these updated libs are able to be linked in statically (this
is the preference of the LSB compiler), but in the case of XCB, we need to
build dynamic libs (Qt5 looks for libxcb.so and libx11-xcb.so), and so we
make sure to enumerate the libraries explicitly to the LSB compiler by
using the LSBCC_SHAREDLIBS environment variable (docs on that here
http://manpages.ubuntu.com/manpages/hardy/man1/lsbcc2.1.html).
 - Note that in some cases, there are calls to interfaces (in both Qt5 and
some of its dependencies like libXau) not in the LSB, and so we have had
to patch these parts of the code. At the end of this process I will have
patch files for Qt5.3.0 that show exactly where these discrepancies are at
the minute.
 - At the end of this process, we have LSB compliant Qt5 libs, which we
can then build our application against (also using the LSB compiler)

As you say, the “easiest” way to do an LSB build like this is to build on
the oldest distribution needed (SLED11 in our case), as we can then have
the confidence that more up-to-date libraries will be available on newer
systems. For this reason, I’m not necessarily interested in shipping the
xcb libraries, as I know they are more-than-likely to exist on these
distributions. However, my issue at the moment is that the oldest
distribution I need to support (SLED11) does not appear to provide a
version of XCB that works when I *run* my Qt5 application against it
(SLED11 provides v7.4-1.22.5.1 of the xorg-x11-libxcb package - perhaps
someone could indeed confirm that this version is too old).

Regards,

Lachlan Hetherton
Software Engineer (Visualisation)
☎ +613-9545-8041



On 7/11/14, 5:54 PM, "Rutledge Shawn" <Shawn.Rutledge at digia.com> wrote:

>
>On 11 Jul 2014, at 6:14 AM, <Lachlan.Hetherton at csiro.au>
> <Lachlan.Hetherton at csiro.au> wrote:
>
>> Hello there,
>> 
>> We are looking to upgrade our existing application from Qt4 to Qt5.3.0.
>>Our application is deployed to Linux, Windows and Mac systems, which we
>>manage by shipping compiled copies of the Qt libraries. An extremely
>>simplified snapshot of our current process for building a Linux version
>>of our application is as follows:
>>     ? Build the Qt libraries using the LSB compiler (LSB version 4.1),
>>maximizing their portability
>>     ? Build our application against the Qt libraries also using the LSB
>>compiler
>>     ? Bundle the libs and executables up into a single RPM ready for
>>shipping
>> We have gone a long way toward replicating this process for the Qt5
>>version of our application, however, we have encountered a few problems:
>>     ? Qt5 has hard dependencies on libxcb (even with -qt­xcb enabled in
>>the configuration), as well as libX11-xcb, and therefore libX11 (though
>>not direct)
>>     ? The LSB does not contain these libraries
>
>GTK depends on them too, and LSB includes GTK; so I don't understand how
>it could be absent.
>
>>     ? One of the Linux distributions we deploy to (SLED 11) does not
>>provide up-to-date versions of these libraries
>
>How can it be considered compliant with LSB 4.1 then?  If you built Qt in
>an environment that provides nothing more than LSB functionality, then Qt
>should not be able to depend on features that are absent in the LSB
>versions of the libs, right?
>
>Do you know which functions are missing in those libs, which Qt depends
>on?
>
>(Disclaimer: I've never tried to create a portable LSB binary before.
>Often it's enough to build on the oldest distro which you expect to
>support, because newer distros will have libs offering a superset of the
>functionality.)
>