NetBSD Problem Report #53921

From www@NetBSD.org  Tue Jan 29 05:16:10 2019
Return-Path: <www@NetBSD.org>
Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client CN "mail.NetBSD.org", Issuer "mail.NetBSD.org CA" (not verified))
	by mollari.NetBSD.org (Postfix) with ESMTPS id 52F2F7A1A9
	for <gnats-bugs@gnats.NetBSD.org>; Tue, 29 Jan 2019 05:16:10 +0000 (UTC)
Message-Id: <20190129051609.5F8567A1DA@mollari.NetBSD.org>
Date: Tue, 29 Jan 2019 05:16:09 +0000 (UTC)
From: bapabooiee@gmail.com
Reply-To: bapabooiee@gmail.com
To: gnats-bugs@NetBSD.org
Subject: graphics/ImageMagic [macOS]: fails with JPEG library version mismatch errors due to using print/ghotscript-gpl's `jpeg_CreateDecompress` function
X-Send-Pr-Version: www-1.0

>Number:         53921
>Category:       pkg
>Synopsis:       graphics/ImageMagic [macOS]: fails with JPEG library version mismatch errors due to using print/ghotscript-gpl's `jpeg_CreateDecompress` function
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    macos-pkg-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Tue Jan 29 05:20:00 +0000 2019
>Closed-Date:    
>Last-Modified:  Wed Jan 30 15:10:01 +0000 2019
>Originator:     Dean Matzkov
>Release:        pkgsrc-2018Q4
>Organization:
>Environment:
>Description:
On macOS, graphics/ImageMagick's ``convert`` command fails like so when attempting to convert a JPEG file:

---SNIP---
$ convert meow.jpg woof.png

convert: Wrong JPEG library version: library is 80, caller expects 90 `meow.jpg' @ error/jpeg.c/JPEGErrorHandler/333.
convert: no images defined `woof.png' @ error/convert.c/ConvertImageCommand/3300.
---/SNIP---



Upon inspection in a debugger, it seems that it's because it's using the older, incompatible ``jpeg_CreateDecompress`` function exported by libgs.dylib (print/ghostscript-gpl), rather than the one from libjpeg.dylib (graphics/jpeg):

Here's a backtrace of a stop-point set at jpeg_CreateDecompress, which demonstrates it using libgs.9.dylib's rather than libjpeg's:

---SNIP---
(lldb) bt

* thread #1, queue = 'com.apple.main-thread', stop reason = breakpoint 3.1
  * frame #0: 0x0000000100a98c60 libgs.9.dylib`jpeg_CreateDecompress
    frame #1: 0x00000001004a6977 libMagickCore-7.Q16HDRI.6.dylib`ReadJPEGImage(image_info=0x0000000103826a00, exception=0x0000000102500800) at jpeg.c:1160
    frame #2: 0x0000000100146d37 libMagickCore-7.Q16HDRI.6.dylib`ReadImage(image_info=0x0000000103823600, exception=0x0000000102500800) at constitute.c:547
    frame #3: 0x0000000100148649 libMagickCore-7.Q16HDRI.6.dylib`ReadImages(image_info=0x0000000103820200, filename="meow.jpg", exception=0x0000000102500800) at constitute.c:919
    frame #4: 0x00000001007798fd libMagickWand-7.Q16HDRI.6.dylib`ConvertImageCommand(image_info=0x0000000103820200, argc=3, argv=0x00000001025001f0, metadata=0x00007ffeefbfd1d8, exception=0x0000000102500800) at convert.c:644
    frame #5: 0x00000001008535ad libMagickWand-7.Q16HDRI.6.dylib`MagickCommandGenesis(image_info=0x0000000103802000, command=(libMagickWand-7.Q16HDRI.6.dylib`ConvertImageCommand at convert.c:518), argc=3, argv=0x00007ffeefbff368, metadata=0x0000000000000000, exception=0x0000000102500800) at mogrify.c:184
    frame #6: 0x0000000100001cf5 convert`MagickMain(argc=3, argv=0x00007ffeefbff368) at magick.c:149
    frame #7: 0x0000000100001a12 convert`main(argc=3, argv=0x00007ffeefbff368) at magick.c:180
    frame #8: 0x00007fff6df27085 libdyld.dylib`start + 1
    frame #9: 0x00007fff6df27085 libdyld.dylib`start + 1
---/SNIP---



And if I force libjpeg.dylib to be preloaded (the macOS equivalent of LD_PRELOAD), as follows, then I can get JPEG conversion to work correctly:

---SNIP---
$ export DYLD_FORCE_FLAT_NAMESPACE=1
$ export DYLD_INSERT_LIBRARIES=${PKG}/lib/libjpeg.9.dylib
$ convert meow.jpg woof.png
---/SNIP---


I'm not sure how to go about fixing this in pkgsrc, but I just thought I'd report it anyway.

Thanks!
>How-To-Repeat:
1. cd $pkgsrc/graphics/ImageMagick
2. convert meow.jpg woof.png
>Fix:

>Release-Note:

>Audit-Trail:

State-Changed-From-To: open->feedback
State-Changed-By: leot@NetBSD.org
State-Changed-When: Tue, 29 Jan 2019 09:55:37 +0000
State-Changed-Why:
Dean, can you please try with graphics/ImageMagick in
pkgsrc-current? (just locally `cvs up' graphics/ImageMagick
directory to pkgsrc-current should do the trick)

mk/jpeg.buildlink3.mk was not included but, at least on NetBSD,
it was indirectly picked up.

I am not sure if this will address that problem but it is
surely worth to try!


Thank you!


From: "Leonardo Taccari" <leot@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc: 
Subject: PR/53921 CVS commit: pkgsrc/graphics/ImageMagick
Date: Tue, 29 Jan 2019 09:52:27 +0000

 Module Name:	pkgsrc
 Committed By:	leot
 Date:		Tue Jan 29 09:52:27 UTC 2019

 Modified Files:
 	pkgsrc/graphics/ImageMagick: Makefile Makefile.common PLIST
 	    buildlink3.mk distinfo

 Log Message:
 ImageMagick: Update to 7.0.8.25

 pkgsrc changes:
  - jpeg is checked by configure and was indirectly picked up.
    Pass `--with-jpeg' and include mk/jpeg.buildlink3.mk accordingly
    (related to PR pkg/53921)

 Changes:
 2019-01-27  7.0.8-25 Cristy  <quetzlzacatenango@image...>
   * Release ImageMagick version 7.0.8-25, GIT revision 15279:7da783a5b:20190127

 2019-01-19  7.0.8-25 Cristy  <quetzlzacatenango@image...>
   * Eliminate spurious font warning (reference
     https://github.com/ImageMagick/ImageMagick/issues/1458).
   * Support HEIC EXIF & XMP profiles.

 2019-01-12  7.0.8-24 Cristy  <quetzlzacatenango@image...>
   * Release ImageMagick version 7.0.8-24, GIT revision 15233:db129ba64:20190112

 2019-01-08  7.0.8-24 Cristy  <quetzlzacatenango@image...>
   * Support -clahe option real clip limit (reference
     https://imagemagick.org/discourse-server/viewtopic.php?f=2&t=35292).
   * ShadeImage() kernels can return negative pixels, clamp to range (reference
     https://github.com/ImageMagick/ImageMagick/issues/1319).
   * Annotate with negative offsets no longer renders slanted text.

 2019-01-01  7.0.8-23 Cristy  <quetzlzacatenango@image...>
   * Release ImageMagick version 7.0.8-23, GIT revision 15199:ba07f7d07:20190101

 2019-01-01  7.0.8-23 Cristy  <quetzlzacatenango@image...>
   * CacheInfo destructor must be aligned in DestroyPixelStream().

 2018-12-30  7.0.8-22 Cristy  <quetzlzacatenango@image...>
   * Release ImageMagick version 7.0.8-22, GIT revision 15189:842164090:20181230

 2018-12-29  7.0.8-22 Cristy  <quetzlzacatenango@image...>
   * Support negative rotations in a geometry (e.g. -10x-10+10+10).
   * Return expected canvas offset after a crop with gravity.

 2018-12-27  7.0.8-21 Cristy  <quetzlzacatenango@image...>
   * Release ImageMagick version 7.0.8-21, GIT revision 15179:114be1716:20181227

 2018-12-27  7.0.8-21 Cristy  <quetzlzacatenango@image...>
   * Check to ensure SeekBlob() offset can be represented in an off_t.

 2018-12-23  7.0.8-20 Cristy  <quetzlzacatenango@image...>
   * Release ImageMagick version 7.0.8-20, GIT revision 15170:8e8222e87:20181223

 2018-12-23  7.0.8-20 Cristy  <quetzlzacatenango@image...>
   * Cube image format returns a HALD image.
   * CLAHE tiles overlapped are now centered relative to the image.

 2018-12-19  7.0.8-19 Cristy  <quetzlzacatenango@image...>
   * Release ImageMagick version 7.0.8-19, GIT revision 15153:e74ed77f5:20181219

 2018-12-18  7.0.8-18 Cristy  <quetzlzacatenango@image...>
   * Release ImageMagick version 7.0.8-18, GIT revision 15146:b5eccd295:20181218

 2018-12-18  7.0.8-18 Cristy  <quetzlzacatenango@image...>
   * Fixed Magick++ compile error on Mac OS X.

 2018-12-17  7.0.8-17 Cristy  <quetzlzacatenango@image...>
   * Release ImageMagick version 7.0.8-17, GIT revision 15142:32f2d195e:20181217


 To generate a diff of this commit:
 cvs rdiff -u -r1.254 -r1.255 pkgsrc/graphics/ImageMagick/Makefile
 cvs rdiff -u -r1.179 -r1.180 pkgsrc/graphics/ImageMagick/Makefile.common
 cvs rdiff -u -r1.104 -r1.105 pkgsrc/graphics/ImageMagick/PLIST
 cvs rdiff -u -r1.68 -r1.69 pkgsrc/graphics/ImageMagick/buildlink3.mk
 cvs rdiff -u -r1.196 -r1.197 pkgsrc/graphics/ImageMagick/distinfo

 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.

From: "Dean M." <bapabooiee@gmail.com>
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: pkg/53921 (graphics/ImageMagic [macOS]: fails with JPEG library
 version mismatch errors due to using print/ghotscript-gpl's
 `jpeg_CreateDecompress` function)
Date: Tue, 29 Jan 2019 15:01:17 -0700

 Tried ImageMagick from pkgsrc trunk, and it still tries to use the
 function from libgs.dylib, unfortunately.

 I also do believe that even without libjpeg's buildlink3.mk and
 --with-jpeg, ImageMagick had still picked up the libjpeg and had it
 dynamically linked into ``libMagickCore-7.Q16HDRI.6.dylib``
 regardless.

 If it helps, here's some of the output from ``jtool -l`` that shows
 what shared libraries my installed copy of
 libMagickCore-7.Q16HDRI.6.dylib from pkgsrc trunk requires. I'm pretty
 sure it's identical to what I saw in pkgsrc-2018Q4 last night, in that
 it still had libjpeg linked:

 ---SNIP---
 jtool -l ${PKG/}lib/libMagickCore-7.Q16HDRI.6.dylib:

 /Users/bapa/pkg/lib/liblcms2.2.dylib
 /Users/bapa/pkg/lib/libtiff.5.dylib
 /Users/bapa/pkg/lib/libjbig.2.dylib
 /Users/bapa/pkg/lib/libgs.9.dylib
 /Users/bapa/pkg/lib/liblqr-1.0.dylib
 /Users/bapa/pkg/lib/libglib-2.0.0.dylib
 /Users/bapa/pkg/lib/libpcre.1.dylib
 /Users/bapa/pkg/lib/libintl.8.dylib
 /usr/lib/libSystem.B.dylib
 /Users/bapa/pkg/lib/libpng16.16.dylib
 /Users/bapa/pkg/lib/libdjvulibre.21.dylib
 /Users/bapa/pkg/lib/libjpeg.9.dylib
 /Users/bapa/pkg/lib/libfftw3.3.dylib
 /opt/X11/lib/libfontconfig.1.dylib
 /opt/X11/lib/libfreetype.6.dylib
 /Users/bapa/pkg/lib/libwebpmux.3.dylib
 /Users/bapa/pkg/lib/libwebp.7.dylib
 /opt/X11/lib/libXext.6.dylib
 /opt/X11/lib/libXt.6.dylib
 /opt/X11/lib/libSM.6.dylib
 /opt/X11/lib/libICE.6.dylib
 /opt/X11/lib/libX11.6.dylib
 /usr/lib/libbz2.1.0.dylib
 /Users/bapa/pkg/lib/libopenjp2.7.dylib
 /Users/bapa/pkg/lib/libxml2.2.dylib
 /Users/bapa/pkg/lib/liblzma.5.dylib
 /usr/lib/libiconv.2.dylib
 /usr/lib/libz.1.dylib
 /Users/bapa/pkg/lib/libltdl.7.dylib
 /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation
 ---/SNIP---

 And in a bid of desperation, I've also tried switching the order libgs
 and libjpeg are linked in (AKA, the MAGICK_LIBS variable) to see if I
 could get libMagickCore-7.Q16HDRI.6.dylib to load libjpeg before libgs
 does, but no luck there either.

 Hope this helps. Thanks.

Responsible-Changed-From-To: pkg-manager->macos-pkg-people
Responsible-Changed-By: leot@NetBSD.org
Responsible-Changed-When: Tue, 29 Jan 2019 22:37:58 +0000
Responsible-Changed-Why:
macOS (and linking) problem


State-Changed-From-To: feedback->open
State-Changed-By: leot@NetBSD.org
State-Changed-When: Tue, 29 Jan 2019 22:37:58 +0000
State-Changed-Why:
Feedback provided (also with mk/jpeg.buildlink3.mk included
it is problematic).


From: "Dean M." <bapabooiee@gmail.com>
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: pkg/53921 (graphics/ImageMagic [macOS]: fails with JPEG library
 version mismatch errors due to using print/ghotscript-gpl's
 `jpeg_CreateDecompress` function)
Date: Tue, 29 Jan 2019 17:19:43 -0700

 So after some sleuthing, it turns out using the more up-to-date AGPL
 Ghostscript (as opposed to the GPL one) in pkgsrc fixes this issue.

 Here's `nm` on the GPL version (ghostscript-gpl, v9.05), showing
 function is exported:

 0000000000056870 T _jpeg_CreateCompress

 And for the AGPL one (ghostscript-agpl, 9.26), it is -- as it should
 be -- an undefined reference:

 U _jpeg_CreateCompress


 It's also worth nothing that ghostscript-gpl-9.05 has its internal
 libjpeg JPEG_LIB_VERSION defined as 80, but ghostscript-agpl-9.26 is
 at 90 (the same version that graphics/jpeg is currently at).

From: David Holland <dholland-pbugs@netbsd.org>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: pkg/53921 (graphics/ImageMagic [macOS]: fails with JPEG library
 version mismatch errors due to using print/ghotscript-gpl's
 `jpeg_CreateDecompress` function)
Date: Wed, 30 Jan 2019 15:07:50 +0000

 On Wed, Jan 30, 2019 at 12:25:01AM +0000, Dean M. wrote:
  >  It's also worth nothing that ghostscript-gpl-9.05 has its internal
  >  libjpeg

 grr. Why does it have its own libjpeg, and why haven't we forcibly
 made it use pkgsrc jpeg?

 -- 
 David A. Holland
 dholland@netbsd.org

>Unformatted:

Home	PR Database Search