I need some help. opencascade 7.5.2 fails to link due to /usr/bin/x86_64-pc-linux-gnu-g++ -std=c++0x -march=native -O3 -maes -mavx -mavx2 -mf16c -mfma -mmmx -mpclmul -mpopcnt -msse -msse2 -msse3 -msse4.1 -msse4.2 -msse4a -mssse3 -pipe -fexceptions -fPIC -Wall -Wextra -Wl,-O1 -Wl,--as-needed -rdynamic src/DRAWEXE/CMakeFiles/DRAWEXE.dir/DRAWEXE.cxx.o -o lin64/gcc/bin/DRAWEXE-7.5.2 -Wl,-rpath,/var/tmp/Big_Tmp/portage/sci-libs/opencascade-7.5.2/work/opencascade-7.5.2_build/lin64/gcc/lib: lin64/gcc/lib/libTKDraw.so.7.5.2 lin64/gcc/lib/libTKMesh.so.7.5.2 lin64/gcc/lib/libTKShHealing.so.7.5.2 lin64/gcc/lib/libTKHLR.so.7.5.2 lin64/gcc/lib/libTKService.so.7.5.2 lin64/gcc/lib/libTKTopAlgo.so.7.5.2 lin64/gcc/lib/libTKGeomAlgo.so.7.5.2 lin64/gcc/lib/libTKBRep.so.7.5.2 lin64/gcc/lib/libTKGeomBase.so.7.5.2 lin64/gcc/lib/libTKG3d.so.7.5.2 lin64/gcc/lib/libTKG2d.so.7.5.2 lin64/gcc/lib/libTKMath.so.7.5.2 lin64/gcc/lib/libTKernel.so.7.5.2 -lpthread -lrt -lstdc++ -ldl -lGL -lfontconfig -lfreeimage -lfreetype -lavcodec -lavformat -lswscale -lavutil -ltcl -ltk -lX11 -lXext -lXmu -lXi -ltbb -ltbbmalloc && : /usr/lib/gcc/x86_64-pc-linux-gnu/9.4.0/../../../../x86_64-pc-linux-gnu/bin/ld: /usr/lib/gcc/x86_64-pc-linux-gnu/9.4.0/../../../../lib64/libfreeimage.so: undefined reference to `TIFFSetSubDirectory' I have the use flags doc examples ffmpeg freeimage tbb vtk and I have freeimage-3.18.0-r2 installed here, which needs libtiff Is there a patch for some CMakefiles to link to libtiff? Many thanks for a hint, Helmut
Could you attach the full build.log and emerge —-info please?
Created attachment 723865 [details] build log xz-compressed
Created attachment 723868 [details] emerge --info
Thanks for the report. Do you have freeimage build with or without USE=tiff? Could you please post output of emerge -pqv freeimage?
I second wanting to see what comment #4 requested. May want to try rebuilding freeimage too (emerge -1 freeimage). I can't reproduce with either freeimage[tiff] or [-tiff], but I'm inclined to believe this is a freeimage issue rather than opencascade, perhaps a specific USE combination caused it to use tiff symbols without linking with it. freeimage in Gentoo is using a bit dodgy patch for unbundling so I wouldn't be surprised there's something.
(In reply to Ionen Wolkens from comment #5) > I can't reproduce with either freeimage[tiff] or [-tiff], but I'm inclined > to believe this is a freeimage issue rather than opencascade, perhaps a > specific USE combination caused it to use tiff symbols without linking with > it. That's what I was thinking too. On a test yesterday, I noticed that the package linked against openexr libraries, even though, the corresponding use flag wasn't set. Eventually there are situations, when this happens for tiff as well.
(In reply to Bernd from comment #6) > That's what I was thinking too. On a test yesterday, I noticed that the > package linked against openexr libraries, even though, the corresponding use > flag wasn't set. Eventually there are situations, when this happens for tiff > as well. Unsure how well it'll go but I'll have a closer look at freeimage, it been breaking some other thing I maintain too. My hope is for debian's patches to be better than ours, then I could make them the upstream if no better option.
Still unable to reproduce unfortunately, I don't see how the symbols could be missing unless your freeimage is broken. It's not impossible freeimage build errors weren't detected (such as from pkg-config) given the build system doesn't really check. So could use outputs of: emerge -pqv freeimage scanelf -n /usr/lib64/libfreeimage{,plus}.so and pkg-config --libs libtiff-4 If first is showing USE=tiff enabled, but 2nd isn't showing libtiff on both -- then there's something strange and I'd further like the build.log from freeimage. Third command should be showing "-ltiff", if not then the problem could be with your libtiff. Do check that you have nothing strange in /usr/local (another copy of freeimage, or tiff) (In reply to Bernd from comment #6) > [...] openexr libraries [...] Oh right, if you meant ilmbase that's "normal", it needs it with USE=tiff as strange as that sounds. I'm getting the impression this may not be as broken as I originally thought, beside an unrelated symbol visibility issue.
emerge -pqv freeimage [ebuild R ] media-libs/freeimage-3.18.0-r2 USE="jpeg jpeg2k mng openexr png raw tiff -static-libs -webp" scanelf -n /usr/lib64/libfreeimage{,plus}.so TYPE NEEDED FILE ET_DYN libz.so.1,libOpenEXR-3_0.so.27,libIex-3_0.so.27,libImath-3_0.so.27,libjpeg.so.62,libopenjp2.so.7, libpng16.so.16,libraw.so.20,libstdc++.so.6,libm.so.6,libgcc_s.so.1,libpthread.so.0,libc.so.6 /usr/lib64/libfreeimage.so ET_DYN libz.so.1,libOpenEXR-3_0.so.27,libIex-3_0.so.27,libImath-3_0.so.27,libjpeg.so.62,libopenjp2.so.7, libpng16.so.16,libraw.so.20,libstdc++.so.6,libm.so.6,libgcc_s.so.1,libpthread.so.0,libc.so.6 /usr/lib64/libfreeimageplus.so pkg-config --libs libtiff-4 -ltiff
Sorry, it's probably my fault. I'm trying to get rid of media-libs/ilmbase since it clashes with dev-libs/imath . I have modified the ebuild for freeimage by replacing the dependency media-libs/ilmbase by dev-libs/imath With the patch --- a/Source/FreeImage/PluginEXR.cpp.ORIG 2021-05-05 12:54:20.033004638 +0200 +++ b/Source/FreeImage/PluginEXR.cpp 2021-05-05 13:05:34.227029779 +0200 @@ -22,6 +22,8 @@ #include "FreeImage.h" #include "Utilities.h" +#include <Imath/ImathInt64.h> +#include <Imath/ImathBox.h> #ifdef _MSC_VER // OpenEXR has many problems with MSVC warnings (why not just correct them ?), just ignore one of them it builds just fine - without media-libs/ilmbase being installed, but /usr/lib64/libfreeimage.so needs libtiff.so If at all possible, I'd like to get along without ilmbase. Are there any hints on how to do that? Many thanks, and sorry again, Helmut
(In reply to Helmut Jarausch from comment #10) > If at all possible, I'd like to get along without ilmbase. > Are there any hints on how to do that? If you don't need tiff support on freeimage, then your current issues would be solved by USE=-tiff until a better solution. freeimage uses ilmbase for 16bit<->float conversions with the tiff plugin
(In reply to Ionen Wolkens from comment #8) > (In reply to Bernd from comment #6) > > [...] openexr libraries [...] > Oh right, if you meant ilmbase that's "normal", it needs it with USE=tiff as > strange as that sounds. Yes, IIRC it was the imath library from ilmbase. (In reply to Helmut Jarausch from comment #9) > emerge -pqv freeimage > [ebuild R ] media-libs/freeimage-3.18.0-r2 USE="jpeg jpeg2k mng openexr > png raw tiff -static-libs -webp" > > scanelf -n /usr/lib64/libfreeimage{,plus}.so > TYPE NEEDED FILE > ET_DYN > libz.so.1,libOpenEXR-3_0.so.27,libIex-3_0.so.27,libImath-3_0.so.27,libjpeg. > so.62,libopenjp2.so.7, > > libpng16.so.16,libraw.so.20,libstdc++.so.6,libm.so.6,libgcc_s.so.1, > libpthread.so.0,libc.so.6 /usr/lib64/libfreeimage.so > ET_DYN > libz.so.1,libOpenEXR-3_0.so.27,libIex-3_0.so.27,libImath-3_0.so.27,libjpeg. > so.62,libopenjp2.so.7, > > libpng16.so.16,libraw.so.20,libstdc++.so.6,libm.so.6,libgcc_s.so.1, > libpthread.so.0,libc.so.6 /usr/lib64/libfreeimageplus.so > > pkg-config --libs libtiff-4 > -ltiff This shows, this issue is with freeimage, not opencascade. (In reply to Helmut Jarausch from comment #10) > Sorry, it's probably my fault. > > I'm trying to get rid of media-libs/ilmbase since it clashes with > dev-libs/imath . > If at all possible, I'd like to get along without ilmbase. > Are there any hints on how to do that? IMO there's more to patch than the lines from your comment. The Makefiles used by the build still contain IlmBase as a dependency for TIFF $(shell $(PKG_CONFIG) --libs libtiff-4 IlmBase). You probably need to change these too to use the Imath pkg-config definitions and proper linking. Also check the PluginTIFF.cpp file, if it needs to be patched in addition to the PluginEXR.cpp file to use Imath instead of IlmBase. There's a big PR at https://github.com/gentoo/gentoo/pull/20930, which introduces slots for the OpenEXR suite of packages, but the freeimage ebuild from this patchset still uses <openexr-3, and thus ilmbase instead of imath.
