On 12/20/2018 10:29 PM, Xi Ruoyao via blfs-dev wrote:
On 2018-12-20 10:45 -0600, Bruce Dubbs via blfs-dev wrote:
On 12/20/2018 06:44 AM, Xi Ruoyao via blfs-dev wrote:
Hi all (esp. Bruce),
I'm upgrading packages of one of my BLFS systems. When I was building
libjpeg-turbo-2.0.1 I found the SONAME of libjpeg.so changed from
libjpeg.so.8 to libjpeg.so.62.
I didn't feel right about that and investigated a little. It turned out
that in r20329 we changed the book to build libjpeg-turbo with cmake and
the option --with-jpeg8 (should be -DWITH_JPEG8=ON with cmake) was
"silently" removed.
Is this a mistake or there is a good reason to remove this option? Note
that Arch Linux is still building libjpeg-turbo with -DWITH_JPEG8=ON.
I don't know for sure. The CMakeLists.txt says
option(WITH_JPEG8 "Emulate libjpeg v8 API/ABI (this makes
${CMAKE_PROJECT_NAME} backward-incompatible with libjpeg v6b)" FALSE)
So upstream says it is false by default. I suppose it is for backward
compatibility. I think for now we should leave it out until we get a
package that complains.
But we *were* using the non-default --with-jpeg8 back in the old autoconf
times (before r20329). Before r10952 BLFS actually used libjpeg v8d. So
I think we should kept using v8 ABI.
I understand we were using it, but where is it being used now?
-- Bruce
--
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
