On 22/11/2011, at 9:55 PM, Thiago Macieira wrote: > On Tuesday, 22 de November de 2011 09.58.02, lars.kn...@nokia.com wrote: >> A IMO better solution would be to have a repository called e.g. qtsupport >> (KDE had something similar for quite a while) that contains copies to >> these 3rd party libraries for convenience. > > I'd prefer that too.
I like this approach too. > > And to keep Craig happy for LSB support, if PCRE isn't on it, we should > ensure > that the qtsupport always builds the libraries it needs as static and > privately installs them for Qt only. We'll need then to tweak Qt's build > system -- I'm not volunteering! -- to do a whole-archive linkage. I don't think you need to install these static libraries (although it won't do any harm if you do). The main need is for Qt to use it internally, not to expose anything from it through its API. That makes the use of PCRE (or any of the other support libraries being used in a similar way) an internal implementation detail. I'm probably having a pre-coffee moment, but you lost me on the "whole archive linkage" bit. ;) > > That is when you link a static library into a dynamic library by importing > all > the .o files into it. The static library must have been built with -fPIC and > is > then known as "convenience library". Yes, this would be essential. If you don't do this, 64-bit platforms run into trouble (we've seen that plenty of times with other software). > > Once "conveniently linked", the .a files can be removed. They should not get > deployed on devices. -- Dr Craig Scott Computational Software Engineering Team Leader, CSIRO (CMIS) Melbourne, Australia _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
