ImageMagick update to 6.9.0-9. So-name bump: libMagick++-6.Q16.so.3 -> libMagick++-6.Q16.so.6

[Tomáš Smetana]

On Fri, 6 Mar 2015 14:11:03 +0100
Michael Schwendt <mschwendt at gmail.com> wrote:

> On Fri, 06 Mar 2015 12:49:12 +0300, Pavel Alexeev wrote:
> 
> > Hello.
> > 
> > ImageMagick itself built in rawhide.
> 
> > >   just go ahead an rebuild pfstools, please.  I'll intervene only in
> > > the case something goes wrong.
> > First attempt fails [1] with:
> > 
> > pfsinimgmagick.opfsoutimgmagick.o: : InIn  functionfunction
> > ``writeFrames(readFramesint(,int ,char* *char)**)': /builddir/'build:/
> > BUILD/builddir/build/BUILD//pfstools-1.8.5/src/fileformatpfstools/-pfsinimgmagick.cpp1.8.5/:src112/:fileformat/
> > pfsoutimgmagick.cppundefined: 194:reference  undefined toreference  `to
> > Magick`:Magick:::ImageImage::::Image(Imageunsigned( intstd,: :unsigned
> > __cxx11int:,: stdbasic_string:<:__cxx11char:,:
> > basic_string<stdchar:, :std:char_traits:<char_traitschar<>char,> ,
> > stdstd::::allocatorallocator<<charchar> >>  >const &,const
> > &MagickCore):': StorageType, void
> > const*)' /builddir/build/BUILD/pfstools-1.8.5/src/fileformat/pfsoutimgmagick.cpp:198:
> > undefined reference to
> > `Magick::Image::write(std::__cxx11::basic_string<char,
> > std::char_traits<char>, std::allocator<char> > const&)' collect2: error:
> > ld returned 1 exit status
> > 
> > 
> > But I think it is not ImageMagick issue, but GCC5 instead[2]. I had try
> > add -D_GLIBCXX_USE_CXX11_ABI=0, and error gone, but now it is:
> > /usr/include/OpenEXR/ImfAttribute.h:295: undefined reference to
> > `Imf_2_2::TypedAttribute<std::string>::staticTypeName()'
> > pfsoutexr.o:(.data.rel.ro._ZTVN7Imf_2_214TypedAttributeISsEE[_ZTVN7Imf_2_214TypedAttributeISsEE]+0x30):
> > undefined reference to
> > `Imf_2_2::TypedAttribute<std::string>::writeValueTo(Imf_2_2::OStream&,
> > int) const'
> > pfsoutexr.o:(.data.rel.ro._ZTVN7Imf_2_214TypedAttributeISsEE[_ZTVN7Imf_2_214TypedAttributeISsEE]+0x38):
> > undefined reference to
> > `Imf_2_2::TypedAttribute<std::string>::readValueFrom(Imf_2_2::IStream&,
> > int, int)'
> > 
> > Right now unsure how to handle it. But I continue digging.
> > 
> > 
> > [1] https://kojipkgs.fedoraproject.org//work/tasks/6035/9146035/build.log
> > [2] http://developerblog.redhat.com/2015/02/05/gcc5-and-the-c11-abi/
> 
> It wasn't build with your upgrade, but an older one:
> 
> https://kojipkgs.fedoraproject.org//work/tasks/6035/9146035/root.log
> 
> DEBUG util.py:388:   ImageMagick             i686
> 6.8.8.10-7.fc22                     build 159 k DEBUG util.py:388:
> ImageMagick-c++         i686   6.8.8.10-7.fc22                     build
> 167 k DEBUG util.py:388:   ImageMagick-libs        i686
> 6.8.8.10-7.fc22                     build 2.0 M
> 
> You may need to look into using "koji wait-repo …" to give koji some
> time to recreate the buildroot repo metadata after including a new
> build. It may take roughly up to 20 minutes for a build to be included.
> 
> Meanwhile, the buildroot should be up-to-date, so give it another try.

Thanks. You were faster...

I'm also afraid the example above shows building only the ImageMagick direct
dependencies might not be sufficient. Seems that right now there are some
packages that have been rebuilt with gcc-5 and some not yet.  This may lead
to more linker failures when one binary wants to link with several libraries
with incompatible ABIs...

Regards,
-- 
Tomáš Smetana
Platform Engineering, Red Hat