Building LO --with-system-jpeg and jpeg-9c fails

Dilyan Palauzov Dilyan.Palauzov at
Tue Jan 22 20:56:46 UTC 2019

Hello Caolán,

what is the usefulness of a test, that behaves differently with different jpeg libraries, but none of the test-outcomes is clearly wrong?

Provided nobody states, that this test has an added value, I propose removing it completely.

Playing with build options costs just too much time and there are other issues (see my other mails) that forces one to try different --with(out)- combinations.  So removing this tests makes life simpler and causes no side effects.


On January 22, 2019 5:31:39 PM GMT+01:00, "Caolán McNamara" <caolanm at> wrote:
>On Tue, 2019-01-22 at 13:58 +0000, Дилян Палаузов wrote:
>> Hello,
>> can originate from 
>> libjpeg-turbo,
>> mozjpeg, or
>> (jpeg-9c)
>> With ./configure --with-system-jpeg, having installed jpeg-9c as
>> /usr/local/lib/, make fails with
>> I tried with or without --with-system-jpeg and it fails only in the
>> latter case.
>> What exactly is the problem?
>Well, its simply that the test expects
>vcl/qa/cppunit/graphicfilter/data/jpg/fail/crash-1.jpg to fail to load
>and it unexpectedly succeeded in loading.
>All those --with-system-foo options aren't guaranteed to work in all
>combinations. The bundled case is supposed to work, and the others are
>at your own risk, with the major distros typically keeping their own
>working, and libjpeg9 is unpopular as a default distro libjpeg
>Someone who wants to use a system libjpeg-9 would have to investigate
>if it succeeds for a good reason or if its pure luck, e.g. via
>uninitialized data. Running it under valgrind like the trailing debug
>text mentions would probably be good enough to rule out a "bad" success
>You can move it from the "fail" dir to the "indeterminate" if you just
>want to "get on with it"
>LibreOffice mailing list
>LibreOffice at

More information about the LibreOffice mailing list