Bug#948862: Experimental jpeg-xl package in Debian
Hi Luca !
On Wed, Nov 24, 2021 at 7:47 PM Luca Versari <veluca@google.com> wrote:
>
>
>
> On Tue, Nov 16, 2021 at 12:42 PM Mathieu Malaterre <malat@debian.org> wrote:
>>
>> Dear Luca,
>
> Hi! Sorry if it took me a while to get back to you.
No worries :)
>>
>>
>> I see you have some interest in jpeg-xl package in Debian. You
>> previously mentioned:
>>
>> > I'm not sure what we could do to expedite that.
>>
>> If you work closely with upstream, the most difficult tasks for me
>> (Debian hat on) were:
>>
>> * Dealing with convenient copies [*], I could not manage to get rid of
>> highway and lodepng. Would be nice if those were not required,
>
> I believe it should be possible to use system highway - the relevant CMake flag is DJPEGXL_FORCE_SYSTEM_HWY.
Right, I see the option now. I believe I need to prepare a package for
highway ... yak shaving again :)
> As for lodepng - that's indeed not possible today, but it being a single, AFAIU-not-packaged-anywhere file might make it possible to make an exception there.
> Note also that lodepng should only be required for tests and tools, and not for the main libjxl library.
True. But for reasons outside my responsibilities CVE can be assigned
to command line tools.
Do you know why upstream is not using the standard libpng directly ?
>> * Use of system lcms2. There is a pending patch that has never been
>> integrated upstream [**],
>
> A similar patch to allow external lcms2 has been submitted and should be integrated in the next release.
Woot \o/
>> * djxl and cjxl are using the static jxl library. This is not a good
>> practice (again Debian hat on), since every time we fix a bug in the
>> shared libjxl, this means recompiling cjxl/djxl for no good reason.
>> Please make it configurable.
>
> AFAIU, the JXL shared library doesn't expose symbols of the (non-public) C++ library, which would make using it from cjxl and djxl at least somewhat problematic;
> we are planning to have cjxl and djxl use the C API, but that's going to take some work still.
OK, at least I understand the issue now.
>>
>> * I also see a minor issue with exported symbols in jxl-threads (but I
>> can live with that).
>
> What kind of issue?
For some reason the symbols for libjxl0.6 are extremely well defined
(kudos to whoever made that possible). Have a peak look at the symbols
file in the Debian file:
libjxl.so.0.6 libjxl0.6 #MINVER#
JXL_0@JXL_0 0.6.1
JxlButteraugliApiCreate@JXL_0 0.6.1
JxlButteraugliApiDestroy@JXL_0 0.6.1
JxlButteraugliApiSetHFAsymmetry@JXL_0 0.6.1
JxlButteraugliApiSetIntensityTarget@JXL_0 0.6.1
...
Compare that with:
libjxl_threads.so.0.6 libjxl0.6 #MINVER#
JxlResizableParallelRunner@Base 0.6.1
[...]
_ZNSt6vectorISt6threadSaIS0_EE17_M_default_appendEm@Base 0.6.1
_ZNSt6vectorISt6threadSaIS0_EE17_M_realloc_insertIJRFvPN6jpegxl20ThreadParallelRunnerEiES6_RjEEEvN9__gnu_cxx17__normal_iteratorIPS0_S2_EEDpOT_@Base
0.6.1
_ZTINSt6thread11_State_implINS_8_InvokerISt5tupleIJPFvPN6jpegxl20ThreadParallelRunnerEiES5_jEEEEEE@Base
0.6.1
_ZTSNSt6thread11_State_implINS_8_InvokerISt5tupleIJPFvPN6jpegxl20ThreadParallelRunnerEiES5_jEEEEEE@Base
0.6.1
_ZTVNSt6thread11_State_implINS_8_InvokerISt5tupleIJPFvPN6jpegxl20ThreadParallelRunnerEiES5_jEEEEEE@Base
0.6.1
So I was simply suprised the same care was not applied to
libjxl_threads.so.0.6, hence my remark. Could you check with upstream
why the same magic to hide c++ stl symbols is not applied.
See upstream file: % cat lib/jxl/jxl.version
>>
>>
>> Thanks for your time,
>
> Thank you!
>>
>>
>> [*] https://wiki.debian.org/EmbeddedCopies
>> [**] https://github.com/libjxl/libjxl/issues/712
>>
>> --
>> To unsubscribe, send mail to 948862-unsubscribe@bugs.debian.org.
Reply to: