Hello. 06.03.2015 16:51, Tomáš Smetana wrote: > On Fri, 6 Mar 2015 14:11:03 +0100 > Michael Schwendt <mschwendt@xxxxxxxxx> 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, -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
