https://bugs.kde.org/show_bug.cgi?id=320107--- Comment #42 from Gilles Caulier <
[hidden email]> ---
I don't understand well your comment #40.
digiKam can deal with libjpeg +6.x, 7.x, 8.x and 9.x. Look into
core/libs/jpegutils/ :
[gilles@localhost jpegutils]$ pwd
/mnt/devel/GIT/5.x/core/libs/jpegutils
[gilles@localhost jpegutils]$ tree
.
├── CMakeLists.txt
├── iccjpeg.c
├── iccjpeg.h
├── jpegutils.cpp
├── jpegutils.h
├── jpegwin.cpp
├── jpegwin.h
├── libjpeg-62
│ ├── jinclude.h
│ ├── jpegint.h
│ ├── README
│ ├── transupp.c
│ └── transupp.h
├── libjpeg-70
│ ├── jinclude.h
│ ├── jpegint.h
│ ├── README
│ ├── transupp.c
│ └── transupp.h
├── libjpeg-84
│ ├── jinclude.h
│ ├── jpegint.h
│ ├── README
│ ├── transupp.c
│ └── transupp.h
└── libjpeg-91
├── jinclude.h
├── jpegint.h
├── README
├── transupp.c
└── transupp.h
4 directories, 27 files
For each major libjpeg version, we have backported jpegtrans implementation
from libjpeg as well, as this implementation is not shared by the library (this
is a main problem from libjpeg).
About libjpeg-turbo, the backward compatibility is repsected with offcial
libjpeg event if version ID is not the same. In fact libjpeg-turbo version ID
will be (must be) detected as the offcial libjpeg version ID.
The code to wrap right core jpegtrans implementation with system libjpeg is
done with cmake :
https://projects.kde.org/projects/extragear/graphics/digikam/repository/revisions/master/entry/cmake/modules/MacroJPEG.cmakeperhaps something has changed in libjpeg-turbo which is not wrapped properlly
with this cmake script...
Gilles Caulier
--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel