openimageio: fallback version build fails for some macOS releases: link failure, or redefinition of 'get_file'

[mascguy (Christopher Nielsen)]

While the fallback version does build successfully for some older releases, it fails on 10.8 with a link error:

Undefined symbols for architecture x86_64:
  "std::__1::__get_sp_mut(void const*)", referenced from:
      __ZNSt3__111atomic_loadB7v160003IN16OpenImageIO_v2_110ImageInputEEENS_10shared_ptrIT_EEPKS5_ in imagecache.cpp.o
      __ZNSt3__115atomic_exchangeB7v160003IN16OpenImageIO_v2_110ImageInputEEENS_10shared_ptrIT_EEPS5_S5_ in imagecache.cpp.o
  "std::__1::__sp_mut::lock()", referenced from:
      __ZNSt3__111atomic_loadB7v160003IN16OpenImageIO_v2_110ImageInputEEENS_10shared_ptrIT_EEPKS5_ in imagecache.cpp.o
      __ZNSt3__115atomic_exchangeB7v160003IN16OpenImageIO_v2_110ImageInputEEENS_10shared_ptrIT_EEPS5_S5_ in imagecache.cpp.o
  "std::__1::__sp_mut::unlock()", referenced from:
      __ZNSt3__111atomic_loadB7v160003IN16OpenImageIO_v2_110ImageInputEEENS_10shared_ptrIT_EEPKS5_ in imagecache.cpp.o
      __ZNSt3__115atomic_exchangeB7v160003IN16OpenImageIO_v2_110ImageInputEEENS_10shared_ptrIT_EEPS5_S5_ in imagecache.cpp.o

While for 10.11 and others, get_file is being redefined by dependency libfmt9:

In file included from openimageio/work/oiio-2.1.20.0/src/include/OpenImageIO/strutil.h:48:
/opt/local/include/libfmt9/fmt/ostream.h:78:16: error: redefinition of 'get_file'
  friend FILE* get_file(filebuf_type& buf) { return buf.*file; }
               ^
/opt/local/include/libfmt9/fmt/ostream.h:80:16: note: in instantiation of template class 'fmt::v9::detail::filebuf_access<fmt::v9::detail::(anonymous namespace)::filebuf_access_tag, decltype(&filebuf_type::_Myfile), &filebuf_type::_Myfile>' requested here
template class filebuf_access<filebuf_access_tag,
               ^
/opt/local/include/libfmt9/fmt/ostream.h:78:16: note: previous definition is here
  friend FILE* get_file(filebuf_type& buf) { return buf.*file; }
               ^

The latter is likely related to the header directory search order, since we have to tweak that to ensure that openexr2 is picked up - via it's segregated location - rather than openexr. So perhaps it's a matter of ensuring that libfmt9 - also segregated - is added to the end of the search path. (Or earlier, depending on what the order is.)

[Christopher Nielsen <mascguy@…>]

In 19d2e6f3e82fd4f43c0277bf37aa3bc5cb3dc110/macports-ports (master):

openimageio: fallback: prepend libfmt9, to include before openexr2
See: #67439

[mascguy (Christopher Nielsen)]

Replying to Christopher Nielsen <mascguy@…>:

In 19d2e6f3e82fd4f43c0277bf37aa3bc5cb3dc110/macports-ports (master):

openimageio: fallback: prepend libfmt9, to include before openexr2
See: #67439

Testing locally on every older macOS release from 10.9 thru 10.15, the redefinition of get_file does not occur. But it is still occurring for our buildbots, so more investigation needed. (10.7 and 10.8 are good too, apart from that pesky link error.)

Marcus/Anyone, thoughts or suggestions...?

[MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)]

I do not have access to my older systems right now.
Until I get back from my trip, I am afraid I will not be able to investigate this issue.

[mascguy (Christopher Nielsen)]

Replying to MarcusCalhoun-Lopez:

I do not have access to my older systems right now.
Until I get back from my trip, I am afraid I will not be able to investigate this issue.

No worries, I'll keep digging.

[mascguy (Christopher Nielsen)]

Update: Apparently I spoke too soon: The issue related to get_file redefinition, was indeed resolved with my earlier fix. So things look good for 10.9 and later. Pfew!

However, now the builds are failing due to a subsequent upstream patch, via ​PR 18704 - openexr: improved fix for older systems:

In file included from .../work/openexr-3.1.7/src/lib/IlmThread/IlmThreadSemaphorePosixCompat.cpp:25:
.../work/openexr-3.1.7/src/lib/IlmThread/IlmThreadSemaphore.h:65:10: error: unknown type name 'dispatch_semaphore_t'
        mutable dispatch_semaphore_t _semaphore;
                ^
1 error generated.

I'll take a look when I get a chance, as hopefully we just need some minor patch changes.

As for the link errors for 10.8 and earlier, it appears that the symbols are related to std::mutex. We might need to use legacysupport/macports-libcxx, but need to do more digging first.

Making progress though!

[mascguy (Christopher Nielsen)]

With Sergey's latest patch - committed via the following PR - the port now builds successfully across-the-board:

​https://github.com/macports/macports-ports/pull/18711