Bug#795102: libgraphicsmagick1-dev: undefined reference to `Magick::Color::Color(unsigned short, unsigned short, unsigned short)'
A quick grep through the sources of rev-deps shows that these packages use the PixelPacket structure: gnudatalanguage octave pdf2djvu python-pgmagick witty xastir I expect them all to be affected by this ABI breakage. So please don't paper over the problem with Breaks, but either revert the QuantumDepth change, or change the SONAME. Thanks. :) In either case, please talk to the release team first, because they'll need to schedule binNMUs. -- Jakub Wilk
Bug#795102: libgraphicsmagick1-dev: undefined reference to `Magick::Color::Color(unsigned short, unsigned short, unsigned short)'
On Mon, Aug 10, 2015 at 10:55 PM, Jakub Wilk jw...@debian.org wrote: $ pdf2djvu /usr/share/doc/quilt/quilt.pdf --fg-colors 42 -p1 -d72 -o tmp.djvu /usr/share/doc/quilt/quilt.pdf: - page #1 - #1 pdf2djvu: malloc.c:3695: _int_malloc: Assertion `(unsigned long) (size) = (unsigned long) (nb)' failed. Magick: abort due to signal 6 (SIGABRT) Abort... Aborted (I think pdf2djvu doesn't work correctly with high quantum depths anyway, but that's another story... I'll get it fixed upstream.) So there will be a new pdf2djvu release? Currently I've fixed all the bugs you are reported, thanks for them! Added a breaks for pdf2djvu v0.7.21-2 and earlier; the binNMU (+b1) solved this issue for me (the generation works). If you would like to have a look before I upload it, you can do that[1]. Regards, Laszlo/GCS [1] dget -x http://www.barcikacomp.hu/gcs/graphicsmagick_1.3.21-3.dsc -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#795102: libgraphicsmagick1-dev: undefined reference to `Magick::Color::Color(unsigned short, unsigned short, unsigned short)'
Package: libgraphicsmagick1-dev Version: 1.3.21-2 Severity: serious I upgraded libgraphicsmagick1-dev to 1.3.21, but not libgraphicsmagick++1-dev: $ dpkg-query -W | grep '^libgraphicsmagick.*-dev' libgraphicsmagick++1-dev1.3.20-3+deb8u1 libgraphicsmagick1-dev 1.3.21-2 Now I can't link stuff: $ g++ -I/usr/include/GraphicsMagick test.cc -lGraphicsMagick++ /tmp/ccrGwLtD.o: In function `main': test.cc:(.text+0x1c): undefined reference to `Magick::Color::Color(unsigned short, unsigned short, unsigned short)' collect2: error: ld returned 1 exit status Upgrading libgraphicsmagick++1-dev fixes this... It looks like libgraphicsmagick1-dev needs versioned breaks against libgraphicsmagick++1-dev. -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (990, 'unstable'), (500, 'experimental') Architecture: i386 (x86_64) Foreign Architectures: amd64 Kernel: Linux 4.1.0-1-amd64 (SMP w/2 CPU cores) Locale: LANG=C, LC_CTYPE=pl_PL.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages libgraphicsmagick1-dev depends on: ii libbz2-dev 1.0.6-8 ii libc6-dev 2.19-19 ii libexif-dev0.6.21-2 ii libfreetype6-dev 2.5.2-4 ii libgraphicsmagick3 1.3.21-2 ii libice-dev 2:1.0.9-1+b1 ii libjasper-dev 1.900.1-debian1-2.4 ii libjbig-dev2.1-3.1 ii libjpeg-dev1:1.4.1-1 ii libjpeg62-turbo-dev [libjpeg-dev] 1:1.4.1-1 ii liblcms2-dev 2.6-3+b3 ii libltdl-dev2.4.2-1.11 ii libpng12-dev [libpng-dev] 1.2.50-2+b2 ii libsm-dev 2:1.2.2-1+b1 ii libtiff5-dev [libtiff-dev] 4.0.3-13 ii libwmf-dev 0.2.8.4-10.4 ii libx11-dev 2:1.6.3-1 ii libxext-dev2:1.3.3-1 ii libxml2-dev2.9.2+dfsg1-3 ii x11proto-core-dev 7.0.27-1 ii zlib1g-dev [libz-dev] 1:1.2.8.dfsg-2+b1 -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#795102: libgraphicsmagick1-dev: undefined reference to `Magick::Color::Color(unsigned short, unsigned short, unsigned short)'
* Bob Friesenhahn bfrie...@simple.dallas.tx.us, 2015-08-10, 12:53: $ g++ -I/usr/include/GraphicsMagick test.cc -lGraphicsMagick++ /tmp/ccrGwLtD.o: In function `main': test.cc:(.text+0x1c): undefined reference to `Magick::Color::Color(unsigned short, unsigned short, unsigned short)' collect2: error: ld returned 1 exit status Upgrading libgraphicsmagick++1-dev fixes this... It looks like libgraphicsmagick1-dev needs versioned breaks against libgraphicsmagick++1-dev. Perhaps this issue is due to g++ defaulting to a newer version of the C++ standard and thus it requires a new C++ ABI? I don't think so. I'd rather blame: * Test build with QuantumDepth 16 (closes: #557879). But wait, isn't change of QuantumDepth an ABI breakage? SONAME of the non-C++ library didn't change; it's still /usr/lib/libGraphicsMagick.so.3. -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#795102: libgraphicsmagick1-dev: undefined reference to `Magick::Color::Color(unsigned short, unsigned short, unsigned short)'
On Mon, 10 Aug 2015, Jakub Wilk wrote: Perhaps this issue is due to g++ defaulting to a newer version of the C++ standard and thus it requires a new C++ ABI? I don't think so. I'd rather blame: * Test build with QuantumDepth 16 (closes: #557879). But wait, isn't change of QuantumDepth an ABI breakage? SONAME of the non-C++ library didn't change; it's still /usr/lib/libGraphicsMagick.so.3. If --enable-quantum-library-names was used as an option to the configure script, then the shared library name would become like libGraphicsMagick-Q16.so so the whole run-time library name is different. If the QuantumDepth 8 build did not use this option, then it would be named as before and existing apps (compiled with QuantumDepth 8) should work with it. This allows the libraries to co-exist. The package used for development needs to specify if it is for Q8 or Q16 since (barring other factors), it is only possible to develop for one at a time. Regardless, if GCC 5.X is now being used (is this the case?), I would suspect that the C++ default ABI (and libraries) have changed (to C++ 11) and this results in different name mangling. Note that the linker did find the library but not the method. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#795102: libgraphicsmagick1-dev: undefined reference to `Magick::Color::Color(unsigned short, unsigned short, unsigned short)'
On Mon, 10 Aug 2015, Jakub Wilk wrote: Package: libgraphicsmagick1-dev Version: 1.3.21-2 Severity: serious I upgraded libgraphicsmagick1-dev to 1.3.21, but not libgraphicsmagick++1-dev: $ dpkg-query -W | grep '^libgraphicsmagick.*-dev' libgraphicsmagick++1-dev1.3.20-3+deb8u1 libgraphicsmagick1-dev 1.3.21-2 Now I can't link stuff: $ g++ -I/usr/include/GraphicsMagick test.cc -lGraphicsMagick++ /tmp/ccrGwLtD.o: In function `main': test.cc:(.text+0x1c): undefined reference to `Magick::Color::Color(unsigned short, unsigned short, unsigned short)' collect2: error: ld returned 1 exit status Upgrading libgraphicsmagick++1-dev fixes this... It looks like libgraphicsmagick1-dev needs versioned breaks against libgraphicsmagick++1-dev. Perhaps this issue is due to g++ defaulting to a newer version of the C++ standard and thus it requires a new C++ ABI? If this is the case, then requesting an older C++ standard may allow linking with the previous libgraphicsmagick++1-dev. Existing apps (not-recompiled) should still be able to use the previous library. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#795102: libgraphicsmagick1-dev: undefined reference to `Magick::Color::Color(unsigned short, unsigned short, unsigned short)'
On Mon, Aug 10, 2015 at 8:27 PM, Bob Friesenhahn bfrie...@simple.dallas.tx.us wrote: On Mon, 10 Aug 2015, Jakub Wilk wrote: Perhaps this issue is due to g++ defaulting to a newer version of the C++ standard and thus it requires a new C++ ABI? I don't think so. I'd rather blame: * Test build with QuantumDepth 16 (closes: #557879). But wait, isn't change of QuantumDepth an ABI breakage? SONAME of the non-C++ library didn't change; it's still /usr/lib/libGraphicsMagick.so.3. As I know it's only an internal precision change, but doesn't affect any method or function. If --enable-quantum-library-names was used as an option to the configure script, then the shared library name would become like libGraphicsMagick-Q16.so so the whole run-time library name is different. It was not used. Should I add this? It seems it would cause more trouble than win. If the QuantumDepth 8 build did not use this option, then it would be named as before and existing apps (compiled with QuantumDepth 8) should work with it. This allows the libraries to co-exist. It seems you also write that the quantum depth change shouldn't be a problem for applications. The package used for development needs to specify if it is for Q8 or Q16 since (barring other factors), it is only possible to develop for one at a time. As I know, GraphicsMagick will use roughly double the memory during image processing with the latter, but that's what the user can see (and that the output quality is better). Am I right? Regardless, if GCC 5.X is now being used (is this the case?), I would suspect that the C++ default ABI (and libraries) have changed (to C++ 11) and this results in different name mangling. Note that the linker did find the library but not the method. Yes, it's now compiled with GCC 5.2.x and the name mangling is changed for the C++ library. There are known regressions[1] between v4.9 and v5 , but I don't know too much details. While you are right in #795099 that the two libgraphicsmagick++ libraries are co-installable, but I fear that the two C++ ABIs would cause more problems. The reverse dependencies list is small, those can be re-compiled with the new library version. But to answer your question, the API for 1.3.21/QuantumDepth16 should be the same as previously. I attach the symbols change between 1.3.20 and 1.3.21 ; the additions are for WebP image support and two symbols (RegisterAVIImage, UnregisterAVIImage) are removed. As I see, a versioned breaks is the only thing I need to add. Regards, Laszlo/GCS [1] https://wiki.debian.org/GCC5#libstdc.2B-.2B-_c.2B-.2B-11_incompatibilities_.284.9_and_5.29 --- 1.3.20/debian/libgraphicsmagick3.symbols2015-02-12 20:08:51.0 +0100 +++ 1.3.21/debian/libgraphicsmagick3.symbols2015-08-08 17:48:44.521870457 +0200 @@ -75,6 +75,7 @@ ChannelThresholdImage@Base 1.3.5 ChannelTypeToString@Base 1.3.5 CharcoalImage@Base 1.3.5 + CheckImagePixelLimits@Base 1.3.21 ChopImage@Base 1.3.5 ClassTypeToString@Base 1.3.5 ClipImage@Base 1.3.5 @@ -504,6 +505,7 @@ LockSemaphoreInfo@Base 1.3.5 LogMagickEvent@Base 1.3.5 LogMagickEventList@Base 1.3.5 + LogPALMHeader@Base 1.3.21 MSBOrderLong@Base 1.3.5 MSBOrderShort@Base 1.3.5 MagickAllocFunctions@Base 1.3.5 @@ -570,6 +572,7 @@ MagickSetFileSystemBlockSize@Base 1.3.8 MagickSizeStrToInt64@Base 1.3.5 MagickSpawnVP@Base 1.3.5 + MagickStripSpacesFromString@Base 1.3.21 MagickStrlCat@Base 1.3.5 MagickStrlCpy@Base 1.3.5 MagickStrlCpyTrunc@Base 1.3.5 @@ -704,6 +707,7 @@ PSPageGeometry@Base 1.3.5 PackbitsEncode2Image@Base 1.3.5 PackbitsEncodeImage@Base 1.3.5 + PanicDestroyMagick@Base 1.3.21 PersistCache@Base 1.3.5 PingBlob@Base 1.3.5 PingImage@Base 1.3.5 @@ -719,6 +723,7 @@ PrependImageToList@Base 1.3.5 ProfileImage@Base 1.3.5 PurgeTemporaryFiles@Base 1.3.15 + PurgeTemporaryFilesAsyncSafe@Base 1.3.21 PushImagePixels@Base 1.3.5 QuantizeImage@Base 1.3.5 QuantizeImages@Base 1.3.5 @@ -764,7 +769,6 @@ ReferenceCache@Base 1.3.5 ReferenceImage@Base 1.3.5 RegisterARTImage@Base 1.3.5 - RegisterAVIImage@Base 1.3.5 RegisterAVSImage@Base 1.3.5 RegisterBMPImage@Base 1.3.5 RegisterCALSImage@Base 1.3.8 @@ -852,6 +856,7 @@ RegisterVIDImage@Base 1.3.5 RegisterVIFFImage@Base 1.3.5 RegisterWBMPImage@Base 1.3.5 + RegisterWEBPImage@Base 1.3.21 RegisterWMFImage@Base 1.3.5 RegisterWPGImage@Base 1.3.5 RegisterXBMImage@Base 1.3.5 @@ -899,6 +904,7 @@ SetImageColor@Base 1.3.15 SetImageColorRegion@Base 1.3.15 SetImageDepth@Base 1.3.5 + SetImageEx@Base 1.3.21 SetImageInfo@Base 1.3.5 SetImageOpacity@Base 1.3.5 SetImagePixels@Base 1.3.5 @@ -982,7 +988,6 @@ UnlockSemaphoreInfo@Base 1.3.5 UnmapBlob@Base 1.3.5 UnregisterARTImage@Base 1.3.5 - UnregisterAVIImage@Base 1.3.5 UnregisterAVSImage@Base 1.3.5 UnregisterBMPImage@Base 1.3.5 UnregisterCALSImage@Base 1.3.8 @@ -1070,6 +1075,7 @@ UnregisterVIDImage@Base 1.3.5 UnregisterVIFFImage@Base 1.3.5
Bug#795102: libgraphicsmagick1-dev: undefined reference to `Magick::Color::Color(unsigned short, unsigned short, unsigned short)'
* László Böszörményi (GCS) g...@debian.org, 2015-08-10, 21:53: * Test build with QuantumDepth 16 (closes: #557879). But wait, isn't change of QuantumDepth an ABI breakage? SONAME of the non-C++ library didn't change; it's still /usr/lib/libGraphicsMagick.so.3. As I know it's only an internal precision change, but doesn't affect any method or function. At least the PixelPacket struct has changed, which is rather fundamental part of the ABI, and not internal at all. And practically, this is what happens in stretch, with libgraphicsmagick3 upgraded to 1.3.21-2: $ pdf2djvu /usr/share/doc/quilt/quilt.pdf --fg-colors 42 -p1 -d72 -o tmp.djvu /usr/share/doc/quilt/quilt.pdf: - page #1 - #1 pdf2djvu: malloc.c:3695: _int_malloc: Assertion `(unsigned long) (size) = (unsigned long) (nb)' failed. Magick: abort due to signal 6 (SIGABRT) Abort... Aborted (I think pdf2djvu doesn't work correctly with high quantum depths anyway, but that's another story... I'll get it fixed upstream.) -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#795102: libgraphicsmagick1-dev: undefined reference to `Magick::Color::Color(unsigned short, unsigned short, unsigned short)'
Duh, I forgot the attachment.
* Bob Friesenhahn bfrie...@simple.dallas.tx.us, 2015-08-10, 13:27:
Regardless, if GCC 5.X is now being used (is this the case?),
I get the same error both with GCC 4.9 and GCC 5.
I would suspect that the C++ default ABI (and libraries) have changed
(to C++ 11) and this results in different name mangling.
This is true in general, but I don't believe anything that would affect
this particular constructor have changed.
--
Jakub Wilk
#include Magick++.h
int main(int argc, char **argv)
{
Magick::Color(0, 0, 0);
}
Bug#795102: libgraphicsmagick1-dev: undefined reference to `Magick::Color::Color(unsigned short, unsigned short, unsigned short)'
On Mon, 10 Aug 2015, László Böszörményi wrote: On Mon, Aug 10, 2015 at 8:27 PM, Bob Friesenhahn bfrie...@simple.dallas.tx.us wrote: On Mon, 10 Aug 2015, Jakub Wilk wrote: Perhaps this issue is due to g++ defaulting to a newer version of the C++ standard and thus it requires a new C++ ABI? I don't think so. I'd rather blame: * Test build with QuantumDepth 16 (closes: #557879). But wait, isn't change of QuantumDepth an ABI breakage? SONAME of the non-C++ library didn't change; it's still /usr/lib/libGraphicsMagick.so.3. As I know it's only an internal precision change, but doesn't affect any method or function. It changes the size of Quantum and IndexPacket (types), as well as the value of MaxRGB, MaxMap, and TransparentOpacity (constants), so unfortunately it is very much exposed to the API user. If --enable-quantum-library-names was used as an option to the configure script, then the shared library name would become like libGraphicsMagick-Q16.so so the whole run-time library name is different. It was not used. Should I add this? It seems it would cause more trouble than win. It should not cause much trouble. The link library name exposed to developers is the normal name. The main value is to allow two run-time libraries to be installed side-by-side. If the QuantumDepth 8 build did not use this option, then it would be named as before and existing apps (compiled with QuantumDepth 8) should work with it. This allows the libraries to co-exist. It seems you also write that the quantum depth change shouldn't be a problem for applications. It depends on the application. The package used for development needs to specify if it is for Q8 or Q16 since (barring other factors), it is only possible to develop for one at a time. As I know, GraphicsMagick will use roughly double the memory during image processing with the latter, but that's what the user can see (and that the output quality is better). Am I right? The output quality is sometimes better, but often identical. The main value is with preserving original quality for deeper images. But to answer your question, the API for 1.3.21/QuantumDepth16 should be the same as previously. I attach the symbols change between 1.3.20 and 1.3.21 ; the additions are for WebP image support and two symbols (RegisterAVIImage, UnregisterAVIImage) are removed. As I see, a versioned breaks is the only thing I need to add. With Q16, the API has changed (from Q8) since the sizes of things change. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
