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

Pavel Alexeev forum at hubbitus.com.ru
Fri Mar 6 16:04:42 UTC 2015


Hello.
06.03.2015 16:51, Tomáš Smetana wrote:
> 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.
> 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...
And how we should deal with it?
According to https://fedoraproject.org/wiki/Changes/GCC5 there no
planned mass-rebuild for GCC5.
I could try rebuild dependencies, but should I use
-D_GLIBCXX_USE_CXX11_ABI=0? Do we have some policy about it?
>
> Regards,



More information about the devel mailing list