[gentoo-user] should everything compile?

[gentoo-user] should everything compile?

[lee]

Hi,

there are some things that refuse to compile.  One of them is
openimageio.

Is this a bug, or am I missing something?  Do I need to update something
else first?


,---- [ emerge -a -k @preserved-rebuild ]
| [...]
| >>> Emerging (27 of 35) media-libs/openimageio-1.6.13::gentoo                                                                                                                                                                     [1450/94379]
|  * openimageio-1.6.13.tar.gz SHA256 SHA512 WHIRLPOOL size ;-) ...                                                                                                                                                                      [ ok ]
| >>> Unpacking source...
| >>> Source unpacked in /var/tmp/portage/media-libs/openimageio-1.6.13/work
| >>> Preparing source in /var/tmp/portage/media-libs/openimageio-1.6.13/work/openimageio-1.6.13 ...
| >>> Source prepared.
| >>> Configuring source in /var/tmp/portage/media-libs/openimageio-1.6.13/work/openimageio-1.6.13 ...
| >>> Working in BUILD_DIR: "/var/tmp/portage/media-libs/openimageio-1.6.13/work/openimageio-1.6.13_build"
| cmake -C /var/tmp/portage/media-libs/openimageio-1.6.13/work/openimageio-1.6.13_build/gentoo_common_config.cmake -G Unix Makefiles -DCMAKE_INSTALL_PREFIX=/usr -DLIB_INSTALL_DIR=/usr/lib64 -DBUILDSTATIC=OFF -DLINKSTATIC=OFF -DINSTALL_DOCS=
| OFF -DOIIO_BUILD_TESTS=OFF -DSTOP_ON_WARNING=OFF -DUSE_EXTERNAL_PUGIXML=ON -DUSE_FIELD3D=OFF -DUSE_FREETYPE=yes -DUSE_FFMPEG=no -DUSE_GIF=yes -DUSE_OCIO=no -DUSE_OPENCV=no -DUSE_OPENGL=yes -DUSE_OPENJPEG=yes -DUSE_OPENSSL=yes -DUSE_PYTHON
| =no -DUSE_LIBRAW=no -DUSE_QT=no -DUSE_PYTHON3=OFF -DCMAKE_BUILD_TYPE=Gentoo -DCMAKE_USER_MAKE_RULES_OVERRIDE=/var/tmp/portage/media-libs/openimageio-1.6.13/work/openimageio-1.6.13_build/gentoo_rules.cmake -DCMAKE_TOOLCHAIN_FILE=/var/tmp/p
| ortage/media-libs/openimageio-1.6.13/work/openimageio-1.6.13_build/gentoo_toolchain.cmake  /var/tmp/portage/media-libs/openimageio-1.6.13/work/openimageio-1.6.13
| loading initial cache file /var/tmp/portage/media-libs/openimageio-1.6.13/work/openimageio-1.6.13_build/gentoo_common_config.cmake
| -- The C compiler identification is GNU 5.3.0
| -- The CXX compiler identification is GNU 5.3.0
| -- Check for working C compiler: /usr/bin/x86_64-pc-linux-gnu-gcc
| -- Check for working C compiler: /usr/bin/x86_64-pc-linux-gnu-gcc -- works
| -- Detecting C compiler ABI info
| -- Detecting C compiler ABI info - done
| -- Detecting C compile features
| -- Detecting C compile features - done
| -- Check for working CXX compiler: /usr/bin/x86_64-pc-linux-gnu-g++
| -- Check for working CXX compiler: /usr/bin/x86_64-pc-linux-gnu-g++ -- works
| -- Detecting CXX compiler ABI info
| -- Detecting CXX compiler ABI info - done
| -- Detecting CXX compile features
| -- Detecting CXX compile features - done
| -- Project build dir = /var/tmp/portage/media-libs/openimageio-1.6.13/work/openimageio-1.6.13_build
| -- CMAKE_CXX_COMPILER is /usr/bin/x86_64-pc-linux-gnu-g++
| -- CMAKE_CXX_COMPILER_ID is GNU
| -- Setting Namespace to: OpenImageIO
| -- platform = linux64
| -- Boost python support not found -- will not build python components!
| -- OpenColorIO disabled
| -- No Qt4 -- skipping components that need Qt4.
| -- Field3d will not be used
| -- Not using LibRaw
| -- Found OpenSSL: /usr/lib64/libssl.so;/usr/lib64/libcrypto.so (found version "1.0.2j") 
| -- OpenSSL enabled
| -- OPENSSL_INCLUDES: /usr/include
| -- FFmpeg plugin will not be built
| -- Field3D plugin will not be built
| -- Raw plugin will not be build
| -- PTex plugin will not be built
| -- 
| 
|    WARNING: Qt, OpenGL, or GLEW not found -- 'iv' will not be built!
| 
| -- Could not Find Nuke. Skipping build of Nuke plugins.
| -- 
| 
| Did not find /var/tmp/portage/media-libs/openimageio-1.6.13/work/openimageio-1.6.13/../bmpsuite
| --   -> Will not run tests bmp
| --   -> You can find it at http://entropymine.com/jason/bmpsuite/bmpsuite.zip
| 
| -- 
| 
| Did not find /var/tmp/portage/media-libs/openimageio-1.6.13/work/openimageio-1.6.13/../libtiffpic
| --   -> Will not run tests tiff-suite;tiff-depths;tiff-misc
| --   -> You can find it at http://www.remotesensing.org/libtiff/images.html
| 
| -- 
| 
| Did not find /var/tmp/portage/media-libs/openimageio-1.6.13/work/openimageio-1.6.13/../openexr-images
| --   -> Will not run tests openexr-suite;openexr-multires;openexr-chroma;openexr-v2;perchannel
| --   -> You can find it at http://www.openexr.com/downloads.html
| 
| -- 
| 
| Did not find /var/tmp/portage/media-libs/openimageio-1.6.13/work/openimageio-1.6.13/../oiio-images
| --   -> Will not run tests gif
| --   -> You can find it at Recent checkout of oiio-images
| 
| -- 
| 
| Did not find /var/tmp/portage/media-libs/openimageio-1.6.13/work/openimageio-1.6.13/../j2kp4files_v1_5
| --   -> Will not run tests jpeg2000
| --   -> You can find it at http://www.itu.int/net/ITU-T/sigdb/speimage/ImageForm-s.aspx?val=10100803
| 
| -- 
| 
| Did not find /var/tmp/portage/media-libs/openimageio-1.6.13/work/openimageio-1.6.13/../oiio-images/pnm
| --   -> Will not run tests pnm
| --   -> You can find it at Recent checkout of oiio-images
| 
| -- 
| 
| Did not find /var/tmp/portage/media-libs/openimageio-1.6.13/work/openimageio-1.6.13/../TGAUTILS
| --   -> Will not run tests targa-tgautils
| --   -> You can find it at http://tgautils.inequation.org/
| 
| -- 
| 
| Did not find /var/tmp/portage/media-libs/openimageio-1.6.13/work/openimageio-1.6.13/../fits-images
| --   -> Will not run tests fits
| --   -> You can find it at http://www.cv.nrao.edu/fits/data/tests/
| 
| -- 
| 
| Did not find /var/tmp/portage/media-libs/openimageio-1.6.13/work/openimageio-1.6.13/../webp-images
| --   -> Will not run tests webp
| --   -> You can find it at http://code.google.com/speed/webp/gallery.html
| 
| -- Configuring done
| -- Generating done
| -- Build files have been written to: /var/tmp/portage/media-libs/openimageio-1.6.13/work/openimageio-1.6.13_build
| >>> Source configured.
| >>> Compiling source in /var/tmp/portage/media-libs/openimageio-1.6.13/work/openimageio-1.6.13 ...
| >>> Working in BUILD_DIR: "/var/tmp/portage/media-libs/openimageio-1.6.13/work/openimageio-1.6.13_build"
| make -j16 VERBOSE=1 
| [...]
| [100%] Linking CXX executable oiiotool
| cd /var/tmp/portage/media-libs/openimageio-1.6.13/work/openimageio-1.6.13_build/src/oiiotool && /usr/bin/cmake -E cmake_link_script CMakeFiles/oiiotool.dir/link.txt --verbose=1
| ccache /usr/bin/x86_64-pc-linux-gnu-g++   -O2 -pipe -march=westmere -mmmx -msse -msse2 -msse3 -mssse3 -mcx16 -msahf -maes -mpclmul -mpopcnt -msse4.2 -msse4.1 -mfxsr --param l1-cache-size=32 --param l1-cache-line-size=64 --param l2-cache-s
| ize=12288 -mtune=westmere -fomit-frame-pointer -fno-stack-protector    -Wl,-O1 -Wl,--as-needed CMakeFiles/oiiotool.dir/oiiotool.cpp.o CMakeFiles/oiiotool.dir/diff.cpp.o CMakeFiles/oiiotool.dir/imagerec.cpp.o CMakeFiles/oiiotool.dir/printi
| nfo.cpp.o  -o oiiotool -rdynamic ../libOpenImageIO/libOpenImageIO.so.1.6.13 -lboost_filesystem-mt -lboost_regex-mt -lboost_system-mt -lboost_thread-mt -lboost_chrono-mt -lboost_date_time-mt -lboost_atomic-mt -lrt -ldl -lssl -lcrypto -lfre
| etype -lpng -lz -ltiff -ljpeg -lIlmImf -lImath -lIex -lHalf -lIlmThread -lpthread -lopenjpeg -lwebp -lgif -lz -ltiff -ljpeg -lIlmImf -lImath -lIex -lHalf -lIlmThread -lpthread -lopenjpeg -lwebp -lgif -lpugixml -Wl,-rpath,/var/tmp/portage/
| media-libs/openimageio-1.6.13/work/openimageio-1.6.13_build/src/libOpenImageIO: 
| ../libOpenImageIO/libOpenImageIO.so.1.6.13: undefined reference to `Imf_2_1::TypedAttribute<std::vector<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::__cxx11::basic_string<char, std::
| char_traits<char>, std::allocator<char> > > > >::writeValueTo(Imf_2_1::OStream&, int) const'
| ../libOpenImageIO/libOpenImageIO.so.1.6.13: undefined reference to `Imf_2_1::TypedAttribute<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >::readValueFrom(Imf_2_1::IStream&, int, int)'
| ../libOpenImageIO/libOpenImageIO.so.1.6.13: undefined reference to `Imf_2_1::Header::type[abi:cxx11]() const'
| ../libOpenImageIO/libOpenImageIO.so.1.6.13: undefined reference to `Imf_2_1::TypedAttribute<std::vector<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::__cxx11::basic_string<char, std::
| char_traits<char>, std::allocator<char> > > > >::readValueFrom(Imf_2_1::IStream&, int, int)'
| ../libOpenImageIO/libOpenImageIO.so.1.6.13: undefined reference to `Imf_2_1::TypedAttribute<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >::staticTypeName()'
| ../libOpenImageIO/libOpenImageIO.so.1.6.13: undefined reference to `Imf_2_1::TypedAttribute<std::vector<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::__cxx11::basic_string<char, std::
| char_traits<char>, std::allocator<char> > > > >::staticTypeName()'
| ../libOpenImageIO/libOpenImageIO.so.1.6.13: undefined reference to `Imf_2_1::Header::name[abi:cxx11]() const'
| ../libOpenImageIO/libOpenImageIO.so.1.6.13: undefined reference to `Imf_2_1::Header::setType(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)'
| ../libOpenImageIO/libOpenImageIO.so.1.6.13: undefined reference to `Imf_2_1::TypedAttribute<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >::writeValueTo(Imf_2_1::OStream&, int) const'
| collect2: error: ld returned 1 exit status
| src/oiiotool/CMakeFiles/oiiotool.dir/build.make:207: recipe for target 'src/oiiotool/oiiotool' failed
| make[2]: *** [src/oiiotool/oiiotool] Error 1
| make[2]: Leaving directory '/var/tmp/portage/media-libs/openimageio-1.6.13/work/openimageio-1.6.13_build'
| CMakeFiles/Makefile2:1366: recipe for target 'src/oiiotool/CMakeFiles/oiiotool.dir/all' failed
| make[1]: *** [src/oiiotool/CMakeFiles/oiiotool.dir/all] Error 2
| make[1]: Leaving directory '/var/tmp/portage/media-libs/openimageio-1.6.13/work/openimageio-1.6.13_build'
| Makefile:160: recipe for target 'all' failed
| make: *** [all] Error 2
|  * ERROR: media-libs/openimageio-1.6.13::gentoo failed (compile phase):
|  *   emake failed
`----

[gentoo-user] Re: should everything compile?

[Holger Hoffstätte]

On Mon, 26 Dec 2016 21:09:08 +0100, lee wrote:

> Hi,
> 
> there are some things that refuse to compile.  One of them is
> openimageio.
> 
> Is this a bug, or am I missing something?  Do I need to update something
> else first?

The latter, sort of. The error in question..

[..]
> | [100%] Linking CXX executable oiiotool
> | cd /var/tmp/portage/media-libs/openimageio-1.6.13/work/openimageio-1.6.13_build/src/oiiotool && /usr/bin/cmake -E cmake_link_script CMakeFiles/oiiotool.dir/link.txt --verbose=1
> | ccache /usr/bin/x86_64-pc-linux-gnu-g++   -O2 -pipe -march=westmere -mmmx -msse -msse2 -msse3 -mssse3 -mcx16 -msahf -maes -mpclmul -mpopcnt -msse4.2 -msse4.1 -mfxsr --param l1-cache-size=32 --param l1-cache-line-size=64 --param l2-cache-s
> | ize=12288 -mtune=westmere -fomit-frame-pointer -fno-stack-protector    -Wl,-O1 -Wl,--as-needed CMakeFiles/oiiotool.dir/oiiotool.cpp.o CMakeFiles/oiiotool.dir/diff.cpp.o CMakeFiles/oiiotool.dir/imagerec.cpp.o CMakeFiles/oiiotool.dir/printi
> | nfo.cpp.o  -o oiiotool -rdynamic ../libOpenImageIO/libOpenImageIO.so.1.6.13 -lboost_filesystem-mt -lboost_regex-mt -lboost_system-mt -lboost_thread-mt -lboost_chrono-mt -lboost_date_time-mt -lboost_atomic-mt -lrt -ldl -lssl -lcrypto -lfre
> | etype -lpng -lz -ltiff -ljpeg -lIlmImf -lImath -lIex -lHalf -lIlmThread -lpthread -lopenjpeg -lwebp -lgif -lz -ltiff -ljpeg -lIlmImf -lImath -lIex -lHalf -lIlmThread -lpthread -lopenjpeg -lwebp -lgif -lpugixml -Wl,-rpath,/var/tmp/portage/
> | media-libs/openimageio-1.6.13/work/openimageio-1.6.13_build/src/libOpenImageIO: 
> | ../libOpenImageIO/libOpenImageIO.so.1.6.13: undefined reference to `Imf_2_1::TypedAttribute<std::vector<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::__cxx11::basic_string<char, std::
> | char_traits<char>, std::allocator<char> > > > >::writeValueTo(Imf_2_1::OStream&, int) const'
> | ../libOpenImageIO/libOpenImageIO.so.1.6.13: undefined reference to `Imf_2_1::TypedAttribute<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >::readValueFrom(Imf_2_1::IStream&, int, int)'
> | ../libOpenImageIO/libOpenImageIO.so.1.6.13: undefined reference to `Imf_2_1::Header::type[abi:cxx11]() const'
> | ../libOpenImageIO/libOpenImageIO.so.1.6.13: undefined reference to `Imf_2_1::TypedAttribute<std::vector<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::__cxx11::basic_string<char, std::
> | char_traits<char>, std::allocator<char> > > > >::readValueFrom(Imf_2_1::IStream&, int, int)'
> | ../libOpenImageIO/libOpenImageIO.so.1.6.13: undefined reference to `Imf_2_1::TypedAttribute<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >::staticTypeName()'
> | ../libOpenImageIO/libOpenImageIO.so.1.6.13: undefined reference to `Imf_2_1::TypedAttribute<std::vector<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::__cxx11::basic_string<char, std::
> | char_traits<char>, std::allocator<char> > > > >::staticTypeName()'
> | ../libOpenImageIO/libOpenImageIO.so.1.6.13: undefined reference to `Imf_2_1::Header::name[abi:cxx11]() const'
> | ../libOpenImageIO/libOpenImageIO.so.1.6.13: undefined reference to `Imf_2_1::Header::setType(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)'
> | ../libOpenImageIO/libOpenImageIO.so.1.6.13: undefined reference to `Imf_2_1::TypedAttribute<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >::writeValueTo(Imf_2_1::OStream&, int) const'
> | collect2: error: ld returned 1 exit status
[..]

..indicates a mismatch in C++11 ABI which changed in gcc5. What happens is that one the
dependencies of openimageio was built against the old C++11 std::string ABI (hence the
link errors), and needs to be rebuilt. It looks to be "Imf" aka libIlmImf,
whatever that is. Try to rebuild it with --oneshot and it should work.
If a similar error pops up for a different dependency, repeat. :)

-h

Re: [gentoo-user] Re: should everything compile?

[lee]

Holger Hoffstätte <holger@applied-asynchrony.com> writes:

> On Mon, 26 Dec 2016 21:09:08 +0100, lee wrote:
>
>> Hi,
>> 
>> there are some things that refuse to compile.  One of them is
>> openimageio.
>> 
>> Is this a bug, or am I missing something?  Do I need to update something
>> else first?
>
> The latter, sort of. The error in question..
>

> [...]
>> | ../libOpenImageIO/libOpenImageIO.so.1.6.13: undefined reference to `Imf_2_1::Header::name[abi:cxx11]() const'
>> | ../libOpenImageIO/libOpenImageIO.so.1.6.13: undefined reference to `Imf_2_1::Header::setType(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)'
>> | ../libOpenImageIO/libOpenImageIO.so.1.6.13: undefined reference to
>> | `Imf_2_1::TypedAttribute<std::__cxx11::basic_string<char,
>> | std::char_traits<char>, std::allocator<char> >
>> | >::writeValueTo(Imf_2_1::OStream&, int) const'
>> | collect2: error: ld returned 1 exit status
> [..]
>
> ..indicates a mismatch in C++11 ABI which changed in gcc5. What happens is that one the
> dependencies of openimageio was built against the old C++11 std::string ABI (hence the
> link errors), and needs to be rebuilt. It looks to be "Imf" aka libIlmImf,
> whatever that is. Try to rebuild it with --oneshot and it should work.
> If a similar error pops up for a different dependency, repeat. :)

Hm, this is really bad because it's difficult to figure out what needs
to be rebuilt.  Is there a way to rebuild everything in some order that
works?

Here's the next one already, and what would I need to rebuild for that?
I can remove the package, though there will probably many more that
don't compile.


,----
| >>> Emerging (19 of 109) dev-ml/camlp4-4.02.1_p3::gentoo
|  * camlp4-4.02.1_p3.tar.gz SHA256 SHA512 WHIRLPOOL size ;-) ...                                                                                                                                                                        [ ok ]
| >>> Unpacking source...
| >>> Unpacking camlp4-4.02.1_p3.tar.gz to /var/tmp/portage/dev-ml/camlp4-4.02.1_p3/work
| >>> Source unpacked in /var/tmp/portage/dev-ml/camlp4-4.02.1_p3/work
| >>> Preparing source in /var/tmp/portage/dev-ml/camlp4-4.02.1_p3/work/camlp4-4.02.1-3 ...
| >>> Source prepared.
| >>> Configuring source in /var/tmp/portage/dev-ml/camlp4-4.02.1_p3/work/camlp4-4.02.1-3 ...
| >>> Source configured.
| >>> Compiling source in /var/tmp/portage/dev-ml/camlp4-4.02.1_p3/work/camlp4-4.02.1-3 ...
| make -j16 byte 
| ocamlbuild -classic-display -no-ocamlfind  `./build/camlp4-byte-only.sh`
| + echo camlp4/Camlp4.cmo camlp4/Camlp4Top.cmo camlp4/camlp4prof.byte camlp4/mkcamlp4.byte camlp4/camlp4.byte camlp4/camlp4fulllib.cma camlp4/camlp4boot.byte camlp4/camlp4boot.cma camlp4/camlp4r.byte camlp4/camlp4r.cma camlp4/camlp4rf.byte
|  camlp4/camlp4rf.cma camlp4/camlp4o.byte camlp4/camlp4o.cma camlp4/camlp4of.byte camlp4/camlp4of.cma camlp4/camlp4oof.byte camlp4/camlp4oof.cma camlp4/camlp4orf.byte camlp4/camlp4orf.cma camlp4/Camlp4Parsers/Camlp4AstLoader.cmo camlp4/Cam
| lp4Parsers/Camlp4DebugParser.cmo camlp4/Camlp4Parsers/Camlp4GrammarParser.cmo camlp4/Camlp4Parsers/Camlp4ListComprehension.cmo camlp4/Camlp4Parsers/Camlp4MacroParser.cmo camlp4/Camlp4Parsers/Camlp4OCamlOriginalQuotationExpander.cmo camlp4
| /Camlp4Parsers/Camlp4OCamlParser.cmo camlp4/Camlp4Parsers/Camlp4OCamlParserParser.cmo camlp4/Camlp4Parsers/Camlp4OCamlReloadedParser.cmo camlp4/Camlp4Parsers/Camlp4OCamlRevisedParser.cmo camlp4/Camlp4Parsers/Camlp4OCamlRevisedParserParser
| .cmo camlp4/Camlp4Parsers/Camlp4OCamlRevisedQuotationExpander.cmo camlp4/Camlp4Parsers/Camlp4QuotationCommon.cmo camlp4/Camlp4Parsers/Camlp4QuotationExpander.cmo camlp4/Camlp4Printers/Camlp4AstDumper.cmo camlp4/Camlp4Printers/Camlp4AutoPr
| inter.cmo camlp4/Camlp4Printers/Camlp4NullDumper.cmo camlp4/Camlp4Printers/Camlp4OCamlAstDumper.cmo camlp4/Camlp4Printers/Camlp4OCamlPrinter.cmo camlp4/Camlp4Printers/Camlp4OCamlRevisedPrinter.cmo camlp4/Camlp4Filters/Camlp4AstLifter.cmo 
| camlp4/Camlp4Filters/Camlp4ExceptionTracer.cmo camlp4/Camlp4Filters/Camlp4FoldGenerator.cmo camlp4/Camlp4Filters/Camlp4LocationStripper.cmo camlp4/Camlp4Filters/Camlp4MapGenerator.cmo camlp4/Camlp4Filters/Camlp4MetaGenerator.cmo camlp4/Ca
| mlp4Filters/Camlp4Profiler.cmo camlp4/Camlp4Filters/Camlp4TrashRemover.cmo
| /usr/bin/ocamlopt.opt unix.cmxa -I /usr/lib64/ocaml/ocamlbuild /usr/lib64/ocaml/ocamlbuild/ocamlbuildlib.cmxa myocamlbuild_config.ml myocamlbuild.ml /usr/lib64/ocaml/ocamlbuild/ocamlbuild.cmx -o myocamlbuild
| /usr/bin/ocamldep.opt -modules camlp4/boot/camlp4boot.ml > camlp4/boot/camlp4boot.ml.depends
| /usr/bin/ocamldep.opt -modules camlp4/boot/Camlp4.ml > camlp4/boot/Camlp4.ml.depends
| /usr/bin/ocamldep.opt -modules camlp4/config/Camlp4_config.mli > camlp4/config/Camlp4_config.mli.depends
| cp /usr/lib64/ocaml/compiler-libs/warnings.cmi camlp4/import/warnings.cmi
| cp /usr/lib64/ocaml/compiler-libs/location.cmi camlp4/import/location.cmi
| cp /usr/lib64/ocaml/compiler-libs/longident.cmi camlp4/import/longident.cmi
| cp /usr/lib64/ocaml/compiler-libs/asttypes.cmi camlp4/import/asttypes.cmi
| cp /usr/lib64/ocaml/compiler-libs/parsetree.cmi camlp4/import/parsetree.cmi
| cp /usr/lib64/ocaml/compiler-libs/outcometree.cmi camlp4/import/outcometree.cmi
| cp /usr/lib64/ocaml/compiler-libs/oprint.cmi camlp4/import/oprint.cmi
| cp /usr/lib64/ocaml/compiler-libs/toploop.cmi camlp4/import/toploop.cmi
| /usr/bin/ocamlc.opt -c -g -w Z -I camlp4/import -warn-error A-3 -I camlp4/config -I camlp4 -o camlp4/config/Camlp4_config.cmi camlp4/config/Camlp4_config.mli
| /usr/bin/ocamlc.opt -c -g -w a -I camlp4/import -warn-error A-3 -I camlp4/config -I camlp4/boot -o camlp4/boot/Camlp4.cmo camlp4/boot/Camlp4.ml
| + /usr/bin/ocamlc.opt -c -g -w a -I camlp4/import -warn-error A-3 -I camlp4/config -I camlp4/boot -o camlp4/boot/Camlp4.cmo camlp4/boot/Camlp4.ml
| File "camlp4/boot/Camlp4.ml", line 14866, characters 41-44:
| Error: This expression has type string but an expression was expected of type
|          Asttypes.arg_label
| Command exited with code 2.
| Makefile:13: recipe for target 'byte' failed
| make: *** [byte] Error 10
|  * ERROR: dev-ml/camlp4-4.02.1_p3::gentoo failed (compile phase):
|  *   emake failed
`----

[gentoo-user] Re: should everything compile?

[Holger Hoffstätte]

On Mon, 26 Dec 2016 22:25:59 +0100, lee wrote:

> Holger Hoffstätte <holger@applied-asynchrony.com> writes:
> 
>> On Mon, 26 Dec 2016 21:09:08 +0100, lee wrote:
>>
>>> Hi,
>>> 
>>> there are some things that refuse to compile.  One of them is
>>> openimageio.
>>> 
>>> Is this a bug, or am I missing something?  Do I need to update something
>>> else first?
>>
>> The latter, sort of. The error in question..
>>
> 
>> [...]
>>> | ../libOpenImageIO/libOpenImageIO.so.1.6.13: undefined reference to `Imf_2_1::Header::name[abi:cxx11]() const'
>>> | ../libOpenImageIO/libOpenImageIO.so.1.6.13: undefined reference to `Imf_2_1::Header::setType(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)'
>>> | ../libOpenImageIO/libOpenImageIO.so.1.6.13: undefined reference to
>>> | `Imf_2_1::TypedAttribute<std::__cxx11::basic_string<char,
>>> | std::char_traits<char>, std::allocator<char> >
>>> | >::writeValueTo(Imf_2_1::OStream&, int) const'
>>> | collect2: error: ld returned 1 exit status
>> [..]
>>
>> ..indicates a mismatch in C++11 ABI which changed in gcc5. What happens is that one the
>> dependencies of openimageio was built against the old C++11 std::string ABI (hence the
>> link errors), and needs to be rebuilt. It looks to be "Imf" aka libIlmImf,
>> whatever that is. Try to rebuild it with --oneshot and it should work.
>> If a similar error pops up for a different dependency, repeat. :)
> 
> Hm, this is really bad because it's difficult to figure out what needs
> to be rebuilt.  Is there a way to rebuild everything in some order that
> works?

equery b <file> or epm -qif tells you which package a file belongs to.
Purely by searching vie emerge -s it looks like libIlmImf could be
media-libs/ilmbase.

A full-system approach (probably better in your case) is explained here:
https://wiki.gentoo.org/wiki/Upgrading_from_gcc-4.x_to_gcc-5.x

> Here's the next one already, and what would I need to rebuild for that?

That looks like a completely different problem (hard to tell from the error)
but in any case _fix one problem at a time_.

-h

Re: [gentoo-user] Re: should everything compile?

[lee]

Holger Hoffstätte <holger@applied-asynchrony.com> writes:

> On Mon, 26 Dec 2016 22:25:59 +0100, lee wrote:
>
>> Holger Hoffstätte <holger@applied-asynchrony.com> writes:
>> 
>>> On Mon, 26 Dec 2016 21:09:08 +0100, lee wrote:
>>>
>>>> Hi,
>>>> 
>>>> there are some things that refuse to compile.  One of them is
>>>> openimageio.
>>>> 
>>>> Is this a bug, or am I missing something?  Do I need to update something
>>>> else first?
>>>
>>> The latter, sort of. The error in question..
>>>
>> 
>>> [...]
>>>> | ../libOpenImageIO/libOpenImageIO.so.1.6.13: undefined reference to `Imf_2_1::Header::name[abi:cxx11]() const'
>>>> | ../libOpenImageIO/libOpenImageIO.so.1.6.13: undefined reference to `Imf_2_1::Header::setType(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)'
>>>> | ../libOpenImageIO/libOpenImageIO.so.1.6.13: undefined reference to
>>>> | `Imf_2_1::TypedAttribute<std::__cxx11::basic_string<char,
>>>> | std::char_traits<char>, std::allocator<char> >
>>>> | >::writeValueTo(Imf_2_1::OStream&, int) const'
>>>> | collect2: error: ld returned 1 exit status
>>> [..]
>>>
>>> ..indicates a mismatch in C++11 ABI which changed in gcc5. What happens is that one the
>>> dependencies of openimageio was built against the old C++11 std::string ABI (hence the
>>> link errors), and needs to be rebuilt. It looks to be "Imf" aka libIlmImf,
>>> whatever that is. Try to rebuild it with --oneshot and it should work.
>>> If a similar error pops up for a different dependency, repeat. :)
>> 
>> Hm, this is really bad because it's difficult to figure out what needs
>> to be rebuilt.  Is there a way to rebuild everything in some order that
>> works?
>
> equery b <file> or epm -qif tells you which package a file belongs to.
> Purely by searching vie emerge -s it looks like libIlmImf could be
> media-libs/ilmbase.

Yes, I have rebuilt those, and others, using trial and error to figure
out what needs to be rebuilt.

> A full-system approach (probably better in your case) is explained here:
> https://wiki.gentoo.org/wiki/Upgrading_from_gcc-4.x_to_gcc-5.x

Thanks!  Seems all I need to do is the 'revdep-rebuild', which is now
running.

I hope I don't end up with an unbootable system ...

>> Here's the next one already, and what would I need to rebuild for that?
>
> That looks like a completely different problem (hard to tell from the error)
> but in any case _fix one problem at a time_.

That was some more packages that needed to be rebuilt.

The only thing that doesn't compile yet is cinelerra, which I don't
need for now.  Maybe it works once all the libraries are rebuilt.

Re: [gentoo-user] Re: should everything compile?

[Alan Grimes]

Holger Hoffstätte wrote:
> ..indicates a mismatch in C++11 ABI which changed in gcc5. What happens is that one the
> dependencies of openimageio was built against the old C++11 std::string ABI (hence the
> link errors), and needs to be rebuilt. It looks to be "Imf" aka libIlmImf,
> whatever that is. Try to rebuild it with --oneshot and it should work.
> If a similar error pops up for a different dependency, repeat. :)
>
> -h

Yeah, I emptytree world my system after each Y in X.Y.Z compiler version
bump. Since I sad it, everyone will tell you it's bad advice but really
not. The binary distros will compile everything with the same compiler
so crap doesn't happen. Now it's not super important but then you have
no idea how many other abi link errors are hiding out there.


-- 
Strange Game.
The only winning move is not to play. 

Powers are not rights.

Re: [gentoo-user] Re: should everything compile?

[Dale]

Alan Grimes wrote:
> Holger Hoffstätte wrote:
>> ..indicates a mismatch in C++11 ABI which changed in gcc5. What happens is that one the
>> dependencies of openimageio was built against the old C++11 std::string ABI (hence the
>> link errors), and needs to be rebuilt. It looks to be "Imf" aka libIlmImf,
>> whatever that is. Try to rebuild it with --oneshot and it should work.
>> If a similar error pops up for a different dependency, repeat. :)
>>
>> -h
> Yeah, I emptytree world my system after each Y in X.Y.Z compiler version
> bump. Since I sad it, everyone will tell you it's bad advice but really
> not. The binary distros will compile everything with the same compiler
> so crap doesn't happen. Now it's not super important but then you have
> no idea how many other abi link errors are hiding out there.
>
>

I do the same here.  When I switch to a new version of gcc, I do a
emerge -e world.  If I've read that it really changes some things, like
this one appears to do, I do it twice.  The second time may be overkill
but I'd rather have overkill than some weird problem that is difficult
to figure out the solution.  I don't think anyone would say doing that
is bad.  A ounce of prevention is always better than a pound of cure.  ;-) 

There's another upgrade that I do that after too.  I can't recall the
name right now but maybe it is glibc or something???? 

Dale

:-)  :-)

Re: [gentoo-user] Re: should everything compile?

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 412 bytes --]

On Tue, 27 Dec 2016 10:25:14 -0500, Alan Grimes wrote:

> Yeah, I emptytree world my system after each Y in X.Y.Z compiler version
> bump. Since I sad it, everyone will tell you it's bad advice but really
> not.

It's not bad advice unless CPU cycles, heat or energy consumption are an
issue. It's generally unnecessary but harmless IMO.


-- 
Neil Bothwick

Who messed with my anti-paranoia shot?

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [gentoo-user] Re: should everything compile?

[J. Roeleveld]

On December 27, 2016 6:55:31 PM GMT+01:00, Dale <rdalek1967@gmail.com> wrote:
>Alan Grimes wrote:
>> Holger Hoffstätte wrote:
>>> ..indicates a mismatch in C++11 ABI which changed in gcc5. What
>happens is that one the
>>> dependencies of openimageio was built against the old C++11
>std::string ABI (hence the
>>> link errors), and needs to be rebuilt. It looks to be "Imf" aka
>libIlmImf,
>>> whatever that is. Try to rebuild it with --oneshot and it should
>work.
>>> If a similar error pops up for a different dependency, repeat. :)
>>>
>>> -h
>> Yeah, I emptytree world my system after each Y in X.Y.Z compiler
>version
>> bump. Since I sad it, everyone will tell you it's bad advice but
>really
>> not. The binary distros will compile everything with the same
>compiler
>> so crap doesn't happen. Now it's not super important but then you
>have
>> no idea how many other abi link errors are hiding out there.
>>
>>
>
>I do the same here.  When I switch to a new version of gcc, I do a
>emerge -e world.  If I've read that it really changes some things, like
>this one appears to do, I do it twice.  The second time may be overkill
>but I'd rather have overkill than some weird problem that is difficult
>to figure out the solution.  I don't think anyone would say doing that
>is bad.  A ounce of prevention is always better than a pound of cure. 
>;-) 
>
>There's another upgrade that I do that after too.  I can't recall the
>name right now but maybe it is glibc or something???? 
>
>Dale
>
>:-)  :-)

I usually do (if encountering weird issues):
# emerge -1 gcc
# emerge -1 glibc
# emerge -e @system
# emerge -e @world

If there is a better method requiring less time, please let me know.

A full rebuild like this into binary packages using a chroot is a good way to prepare for a toolchain update. That way all the packages are already prepared and the downtime will be minimized.

--
Joost


-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: [gentoo-user] Re: should everything compile?

[Dale]

J. Roeleveld wrote:
> On December 27, 2016 6:55:31 PM GMT+01:00, Dale <rdalek1967@gmail.com> wrote:
>> Alan Grimes wrote:
>>> Holger Hoffstätte wrote:
>>>> ..indicates a mismatch in C++11 ABI which changed in gcc5. What
>> happens is that one the
>>>> dependencies of openimageio was built against the old C++11
>> std::string ABI (hence the
>>>> link errors), and needs to be rebuilt. It looks to be "Imf" aka
>> libIlmImf,
>>>> whatever that is. Try to rebuild it with --oneshot and it should
>> work.
>>>> If a similar error pops up for a different dependency, repeat. :)
>>>>
>>>> -h
>>> Yeah, I emptytree world my system after each Y in X.Y.Z compiler
>> version
>>> bump. Since I sad it, everyone will tell you it's bad advice but
>> really
>>> not. The binary distros will compile everything with the same
>> compiler
>>> so crap doesn't happen. Now it's not super important but then you
>> have
>>> no idea how many other abi link errors are hiding out there.
>>>
>>>
>> I do the same here.  When I switch to a new version of gcc, I do a
>> emerge -e world.  If I've read that it really changes some things, like
>> this one appears to do, I do it twice.  The second time may be overkill
>> but I'd rather have overkill than some weird problem that is difficult
>> to figure out the solution.  I don't think anyone would say doing that
>> is bad.  A ounce of prevention is always better than a pound of cure. 
>> ;-) 
>>
>> There's another upgrade that I do that after too.  I can't recall the
>> name right now but maybe it is glibc or something???? 
>>
>> Dale
>>
>> :-)  :-)
> I usually do (if encountering weird issues):
> # emerge -1 gcc
> # emerge -1 glibc
> # emerge -e @system
> # emerge -e @world
>
> If there is a better method requiring less time, please let me know.
>
> A full rebuild like this into binary packages using a chroot is a good way to prepare for a toolchain update. That way all the packages are already prepared and the downtime will be minimized.
>
> --
> Joost
>
>

Giving it some thought, I would think your way would be the fastest. 
When you emerge -e system, that should rebuild everything toolchain
wise.  Then when you go back and do world, that should rebuild
everything with the new toolchain.  I have ran emerge -e world twice in
the past but that requires more time than your way.  Your way should
guarantee success and be the quickest.

I might add, in the past when I run into something weird, even with no
gcc or glibc changes, I would do a emerge -e world.  Sometimes there can
be a change that doesn't get picked up on by emerge or even the devs. 
Even the logs from a build failure may not give any real clue.  That
said, it has been a while since I've had that sort of problem.  I run a
mix of unstable and stable and still have a pretty sane system.  I think
that says a lot about how portage/emerge/etc does its job now.  The devs
have really worked out some serious kinks. 

Now that I said that, something will come along pretty soon and just
bork everything up.  LOL 

Dale

:-)  :-) 

Re: [gentoo-user] Re: should everything compile?

[J. Roeleveld]

On Tuesday, December 27, 2016 02:20:20 PM Dale wrote:
> J. Roeleveld wrote:
> > On December 27, 2016 6:55:31 PM GMT+01:00, Dale <rdalek1967@gmail.com> 
wrote:
> >> Alan Grimes wrote:
> >>> Holger Hoffstätte wrote:
> >>>> ..indicates a mismatch in C++11 ABI which changed in gcc5. What
> >> 
> >> happens is that one the
> >> 
> >>>> dependencies of openimageio was built against the old C++11
> >> 
> >> std::string ABI (hence the
> >> 
> >>>> link errors), and needs to be rebuilt. It looks to be "Imf" aka
> >> 
> >> libIlmImf,
> >> 
> >>>> whatever that is. Try to rebuild it with --oneshot and it should
> >> 
> >> work.
> >> 
> >>>> If a similar error pops up for a different dependency, repeat. :)
> >>>> 
> >>>> -h
> >>> 
> >>> Yeah, I emptytree world my system after each Y in X.Y.Z compiler
> >> 
> >> version
> >> 
> >>> bump. Since I sad it, everyone will tell you it's bad advice but
> >> 
> >> really
> >> 
> >>> not. The binary distros will compile everything with the same
> >> 
> >> compiler
> >> 
> >>> so crap doesn't happen. Now it's not super important but then you
> >> 
> >> have
> >> 
> >>> no idea how many other abi link errors are hiding out there.
> >> 
> >> I do the same here.  When I switch to a new version of gcc, I do a
> >> emerge -e world.  If I've read that it really changes some things, like
> >> this one appears to do, I do it twice.  The second time may be overkill
> >> but I'd rather have overkill than some weird problem that is difficult
> >> to figure out the solution.  I don't think anyone would say doing that
> >> is bad.  A ounce of prevention is always better than a pound of cure.
> >> ;-)
> >> 
> >> There's another upgrade that I do that after too.  I can't recall the
> >> name right now but maybe it is glibc or something????
> >> 
> >> Dale
> >> 
> >> :-)  :-)
> > 
> > I usually do (if encountering weird issues):
> > # emerge -1 gcc
> > # emerge -1 glibc
> > # emerge -e @system
> > # emerge -e @world
> > 
> > If there is a better method requiring less time, please let me know.
> > 
> > A full rebuild like this into binary packages using a chroot is a good way
> > to prepare for a toolchain update. That way all the packages are already
> > prepared and the downtime will be minimized.
> > 
> > --
> > Joost
> 
> Giving it some thought, I would think your way would be the fastest.
> When you emerge -e system, that should rebuild everything toolchain
> wise.  Then when you go back and do world, that should rebuild
> everything with the new toolchain.  I have ran emerge -e world twice in
> the past but that requires more time than your way.  Your way should
> guarantee success and be the quickest.

There is a way that might even be quicker:
- Temporarily switch to the most basic profile (desktop-profiles have a lot of 
additional USE-flags causing extra stuff in the @system set)
- Temporarily move all "package.use" entries out of the way

After "emerge -e @system" reset the correct profile and move all your 
package.use flags back.

> I might add, in the past when I run into something weird, even with no
> gcc or glibc changes, I would do a emerge -e world.  Sometimes there can
> be a change that doesn't get picked up on by emerge or even the devs.
> Even the logs from a build failure may not give any real clue.  That
> said, it has been a while since I've had that sort of problem.  I run a
> mix of unstable and stable and still have a pretty sane system.  I think
> that says a lot about how portage/emerge/etc does its job now.  The devs
> have really worked out some serious kinks.

I don't often have to do an "emerge -e" either. Only when something 
"important" changes. Like a profile, kde -> plasma, major gcc/glibc-version or 
similar.
Can't really remember the last time, apart from when I updated my parents 
laptop after nearly 2 years in one go. (binaries compiled on a fast machine 
really helped there)
The laptop functions as a simple media-player.

> Now that I said that, something will come along pretty soon and just
> bork everything up.  LOL

Tempting murphy?

--
Joost