[Interest] Conflicting libjpeg versions

Etienne Sandré-Chardonnal etienne.sandre at m4x.org
Tue Mar 29 18:57:45 CEST 2016


Thiago, I do not use these, I was just checking the different libjpeg
versions shipped with Qt

Updated status : I have another system where Qt was built with -qt-libjpeg
 - Everything works fine and I can use my own libjpeg library in the
application without any issue.

On the system with -system-libjpeg:
 - qt adds -ljpeg to linker options even if I do not add it in the project
settings
 - calls to the libjpeg API fail with a version mismatch error
 - linking the application fails if my own libjpeg.a is not present
 - if I replace libjpeg.a by libjpeg.dll.a (dynamic link version), the
compilation works, and the application runs fine without the DLL (!)

My conclusion : With -system-libjpeg, Qt is set to link to the system
library, but no symbols from it are effectively linked with the
application. It seems that the linker finds libjpeg symbols exported by Qt
static libraries themselves.

Is this possible, and isn't this a bug?





2016-03-29 18:35 GMT+02:00 Thiago Macieira <thiago.macieira at intel.com>:

> On terça-feira, 29 de março de 2016 18:20:21 PDT Etienne Sandré-Chardonnal
> wrote:
> > I have looked into Qt sources, and three different libjpeg are shipped :
> > one with webkit, one with qtwebengine, and one with qtbase. The first one
> > is libjpeg-turbo 62, the two other are libjpeg 80
>
> webkit and webengine must not be used statically.
>
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
>   Software Architect - Intel Open Source Technology Center
>
> _______________________________________________
> Interest mailing list
> Interest at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20160329/553e5213/attachment.html>


More information about the Interest mailing list