Created attachment 685005 [details] backtrace + emerge --info.txt Been experiencing segfaults opening TIFF images with media-gfx/imv and, if I'm not wrong, the issue traces back to the unbundling patch used by Gentoo on freeimage. freeimage[-tiff] with imv[tiff]: works freeimage[tiff] with imv[-tiff]: segfault freeimage[tiff] with imv[tiff]: imv's libtiff backend fails because it uses freeimage's TIFFOpen (which does nothing but return 0) rather than linked libtiff's, then tries freeimage backend and segfaults. Linking against vanilla freeimage works in every situations. No difference between freeimage-3.18.0-r1 and -r2, so this isn't caused by the tiff security patch. Was experiencing this issue while testing imv-4.2.0 (bump PR pending), but reproducible with in-tree 4.1.0 as well. If no easy solution then masking tiff on freeimage "would" work for me but games-util/slade currently depends on it. The entire tiff handling seem like a bad hack. Happening in backend_libtiff.c which is trying to call TIFFOpen from libtiff: Thread 1 "imv" hit Breakpoint 1, TIFFOpen (name=0x5555555b7ce0 "/tmp/test.tif", mode=0x5555555695b0 "r") at Source/FreeImage/PluginTIFF.cpp:207 207 return 0; And then tries gentoo's freeimage: Thread 3 "imv" received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7ffff1e0f640 (LWP 17606)] 0x00007ffff793dc95 in TIFFFieldTag (fip=0x100000000) at /tmp/portage/media-libs/tiff-4.2.0/work/tiff-4.2.0/libtiff/tif_dirinfo.c:758 758 return fip->field_tag;
I don't think it's entirely the patch's fault. FreeImage redefines a bunch of the standard libtiff functions, including this one. I'm not sure what happens with the vanilla build but when patched, it exports symbols like TIFFOpen. If these symbols were hidden then perhaps the issue would go away. This isn't an area I'm very familiar with though. Do you want to have a go?
Not something I'm particularly familiar with either, merely made observations. I'd be very thankful if someone else could have a look, but if it comes down to it I'll see what I can do. There seem to be possibly two issues here, but as long as imv[tiff]'s backend can work (with right TIFFOpen) then it at least won't reach freeimage's to fail there affect very few users.
Hm, unsure why but this issue seem to have went went away with freeimage-3.18.0-r8 and the >=tiff-4.4.0 dependency, all 3 of the mentioned cases work now (still segfaults/fail if go back to -r7). I imagine it may not be truly fixed, but it's not causing issues for imv's use case anymore.