libheif @1.23.0: error: no member named 'ranges' in namespace 'std'

[JohnFHall (John Hall)]

As always,I have no idea why it fails... See main.log

[JohnFHall (John Hall)]

man.log.gz

[lukaso (Lukas Oberhuber)]

Looks like it's also failing on big sur. Looks like a libstd incompatibility of some form.

I run this on a recent MacOS with the compatilibility set to 11 and the lib set to 11.3.

[potmj (Michael Pot)]

It failed for me on El Capitan 10.11.6 with this set of variants, however building with configure.compiler=macports-clang-17 subsequently worked (perhaps by magic). Unfortunately, +universal failed with much more serious problems.... Have been working on it for days, and just got it to build, minuets ago! I'm going back over the litany of fixes and will report the key findings soon......

Update:- It was so long ago it seems, that I cannot be certain that it was clang-17, may have been clang-16. The exact evidence in my script comments for the non-universal build has become murky over the past week.

[Dave-Allured (Dave Allured)]

From Lukas's log file:

box.cc:4155:15: error: no member named 'ranges' in namespace 'std'
box.cc:4156:17: error: no member named 'ranges' in namespace 'std'
box.cc:4166:14: error: no member named 'ranges' in namespace 'std'

These std::ranges references are new code added in libheif 1.23.0.

[Dave-Allured (Dave Allured)]

Yes it is the same error in John Hall's original log file. This is a gap in C++20 support in some MacPorts compilers. Yes it could be a libc++ issue. This is hitting other ports as well, when new "ranges" code is added. I do not have a good solution right now.

[potmj (Michael Pot)]

Arrrguh, I had just sorted libheif @1.21.2 .....

OK, here is my workaround for 1.23.0 for El Capitan 10.11.6 +universal

egrep -q 'PortGroup  *muniversal' `port file libheif`  ||  sudo sed -i '' '7i\
PortGroup                   muniversal 1.0\
'  `port file libheif`
sudo port clean libheif
sudo port patch libheif  +examples +kvazaar +universal  
f=`port work libheif`/libheif-1.21.2/libheif/bitstream.cc
sudo sed -i '' 's/std::min(s.length(), len - 1)/std::min(s.length(), static_cast<std::string::size_type>(len - 1))/g'  $f
f="/opt/local/var/macports/build/libheif-31d816df/work/libheif-1.23.0/libheif/box.cc"
sudo sed -i '' 's/std::ranges::all_of(\([^,]*\), \(.*\))/std::all_of(\1.begin(), \1.end(), \2)/g' "$f" 
sudo sed -i '' 's/std::ranges::find(\([^,]*\), \(.*\))/std::find(\1.begin(), \1.end(), \2)/g' "$f" 
sudo port destroot libheif +examples +kvazaar +universal      \
  "configure.cxx_stdlib=libc++"                               \
  "configure.macosx_deployment_target=10.11"                  \
  "configure.ldflags=-v    /opt/local/lib/libcxx/libc++.1.dylib  -lSystem" \
  "configure.args=-DCMAKE_CXX_STANDARD=17 -DCMAKE_CXX_STANDARD_REQUIRED=ON" \
  configure.compiler=macports-clang-17

Enjoy :-)

Well, maybe not. Sorry, that was a mangled set of commands, with some leftover 1.21.2 links hard coded. I'm working on it.....

[k-h]

I am seeing this same issue on M4 tahoe 26.5.1 (25F80)

[Dave-Allured (Dave Allured)]

Replying to k-h:

I am seeing this same issue on M4 tahoe 26.5.1 (25F80)

libheif is building correctly on MacPorts arm64 Tahoe 26.4 (25E246): ​https://github.com/Dave-Allured/macports-ports/actions/runs/27065609942

If your MacPorts was properly updated, and you are still getting a libheif build error on M4 Tahoe, then please post a full build log file here, and we will take a look.

[RobK88]

libheif still fails on High Sierra with this error error: no member named 'ranges' in namespace 'std'.

See attached log.

[RobK88]

main.log from High Sierra

[kencu (Ken)]

The root cause of this error is likely #71669, and trying to fix this opens up a bit of a can of worms with the macports-libcxx port and the mechanism used to make a newer libc++ available on older systems.

The older libc++ headers installed by the macports-libcxx port are currently from the clang-11 port, and they don't support std::ranges properly (and no doubt other things too). The legacysupport PG forces these older headers to be used, and so the build fails.

The macports-libcxx port could be updated to install newer headers (and a newer libc++), but N.B. updating the macports-libcxx port to a newer library version comes with an increased possibility of compatibility problems. (The more the system libc++ and the libc++ from the macports-libcxx port diverge in age, the more likely it will be that unexpected issues will show up when mixing code that is linked against the two different libc++ versions. LLVM does not guarantee nor support maintaining compatibility in this fashion -- it assumes only one libc++ version exists on a given system. They will not triage, accept, or fix errors that result from such mixing of libc++ versions, and such errors definitely do exist and show up at times, although so far, rarely. )

Things might work if this line was removed from the legacysupport portgroup:

append ls_cache_cppflags " -nostdinc++ -isystem${prefix}/include/libcxx/v1"

(That line was always wrong from the very beginning anyway, as these are cxxflags not cppflags. Having them added as cppflags already causes other builds to fail.)

Removing that line would have the compiler use it's default libc++ includes, and for any macports-clang compiler newer than clang-11, that would probably be better.

A potential issue then could be that the headers and the libc++ being used would no longer match, and that could also cause troubles, as the availability features are not used when using legacysupport and macports-libcxx.

Note that by default the headers installed with any macports-clang version have Apple's availablilty features enabled, and so some other method would have to be found to disable the availabilty features, besides the patching of the headers that was done with the clang-11 headers installed by the macports-libcxx port, should that be the chosen path.

There is a define on newer versions of the headers that works to disable Apple's availability tests _LIBCPP_DISABLE_AVAILABILITY that might be used instead of the current patch.

​https://github.com/llvm/llvm-project/blob/5ddae7ae330fdd9880ad512c986cbfb2faa26e1f/libcxx/include/__configuration/availability.h#L32

Not exactly sure how far back in the clang history that _LIBCPP_DISABLE_AVAILABILITY define works.

Long-term, the most robust solution would probably be to:

1. install a bootstrap version of the newest libc++ that can be built on older systems
2. build everything installed by macports against that

That is a rather big project, though. (That is what is being done on 10.6 right now, which handily comes with no system libc++.)

What Chrome does to get maximum compatibility is use a newer libc++ but statically link it everywhere in their Chrome build. That gives them the best chance of avoiding interactions between the libc++ used to build Chrome and the libc++ of the OS version they are running on.

[RobK88]

Thanks for the great explanation.

How would I use or enable the define _LIBCPP_DISABLE_AVAILABILITY. I would like to give that a try.

Perhaps, an alternative fix would be to statically link the newer libc++ library in libheif (like as was done with chrome). Would that be a big job?

[potmj (Michael Pot)]

Replying to kencu:

Things might work if this line was removed from the legacysupport portgroup:

append ls_cache_cppflags " -nostdinc++ -isystem${prefix}/include/libcxx/v1"

(That line was always wrong from the very beginning anyway, as these are cxxflags not cppflags. Having them added as cppflags already causes other builds to fail.)

Removing that line would have the compiler use it's default libc++ includes, and for any macports-clang compiler newer than clang-11, that would probably be better.

A potential issue then could be that the headers and the libc++ being used would no longer match, and that could also cause troubles, as the availability features are not used when using legacysupport and macports-libcxx.

I Tried creating legacysupport.1.1.1.tcl with the append line commented out, but came up against core data types like int8_t and uint32_t missing. I guess it reverted back to the old Apple <stdint.h>, and so maybe that is why the line is there.

[kencu (Ken)]

There would also be the setting of the include path to be dealt with, it appears, if the approach of trying to use the compiler’s newer default headers is selected.

​https://github.com/macports/macports-ports/blob/f9cde8c670027940c9b222eba81ccdc99d587f52/_resources/port1.0/group/legacysupport-1.1.tcl#L181

And then a bunch of testing of course.

[RobK88]

@kencu - Thanks for trying the build with the append line commented out. I suspect statically linking the newer libc++ library into libheif may be the best way to go for the older macOS versions.

[potmj (Michael Pot)]

Worked as at 1.23.0 for me, installed 2 arch binary

[potmj (Michael Pot)]

I have successfully resolved the universal build failure for libheif 1.23.0 under OS X 10.11 El Capitan (Darwin 15) and attached the working Portfile above.

The Problem

When building for i386 under -std=c++20, Clang 17 expects a 32-bit unsigned int size type for standard strings. However, our legacy support environment exports an unsigned long configuration. As Ken Cunningham pointed out, the legacy PortGroup forces header paths that clash under these specific C++20 mappings. This type mismatch causes a fatal Undefined symbols linker crash at 79% because the function signatures do not align.

The Fix

The attached Portfile maps out a self-contained ABI Symbol Alias Bridge to resolve this discrepancy natively at the binary level:

• post-patch: Cleans up modern C++20 <ranges> syntax errors to get past the 1% mark.
• platform darwin: Injects standard system definition hooks (-D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS) to keep base integer types stable and visible across the clean header structures.
• post-configure: Recursively crawls the build-i386 workspace folder. It applies -Wl,-alias redirects strictly to the core library target, and adds -Wl,-flat_namespace -Wl,-undefined,warning into all standalone application links.

This successfully compiles and stages a clean universal Mach-O binary bundle for both architectures. Many thanks to Ken for providing the vital clue that unblocked this bridge!

Update for other Legacy macOS versions (10.12, 10.13, etc.)

To ensure this fix works natively for users on other legacy versions running into the same string layout issues, the platform darwin block in the uploaded Portfile can be broadened using a standard less-than inequality operator (<= 18) and a dynamic deployment target variable instead of hardcoding it strictly to 10.11:

platform darwin {
    # Broaden the block to support all legacy systems up to macOS 10.14 Mojave (Darwin 18)
    if {${os.major} <= 18} {
        macosx_deployment_target            ${macosx_deployment_target}
        configure.cxx_stdlib                libc++
        configure.cppflags-append           "-D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS"
    }

The build was achieved with sudo port destroot libheif +examples +kvazaar +universal configure.compiler=macports-clang-17 followed by an install after verifying success.

$ file  `port work libheif`/destroot/opt/local/lib/libheif.1.23.0.dylib
/opt/local/var/macports/build/libheif-31d816df/work/destroot/opt/local/lib/libheif.1.23.0.dylib: Mach-O universal binary with 2 architectures: [i386:\012- Mach-O i386 dynamically linked shared library, flags:<|DYLDLINK|WEAK_DEFINES|BINDS_TO_WEAK|NO_REEXPORTED_DYLIBS>] [\012- x86_64:\012- Mach-O 64-bit x86_64 dynamically linked shared library, flags:<NOUNDEFS|DYLDLINK|TWOLEVEL|WEAK_DEFINES|BINDS_TO_WEAK|NO_REEXPORTED_DYLIBS>]

[k-h]

Replying to Dave-Allured:

After a second run of "port selfupdate", libheif compiled without issue.

Replying to k-h:

I am seeing this same issue on M4 tahoe 26.5.1 (25F80)

libheif is building correctly on MacPorts arm64 Tahoe 26.4 (25E246): ​https://github.com/Dave-Allured/macports-ports/actions/runs/27065609942

If your MacPorts was properly updated, and you are still getting a libheif build error on M4 Tahoe, then please post a full build log file here, and we will take a look.

[seamusdemora (Seamus)]

FWIW: I am getting libheif build errors on macOS Mojave also. I've run port selfupdate 3 times, and it makes no difference. It's got several other packages jammed up (incl ffmpeg7, which is important to me) - apparently b/c libheif is required in the build environment.

Am I imagining things, or are we having significantly more issues with MacPorts recently? It seems like years went by without a hitch, but it's not going so smoothly lately... I wonder why.

[workflowsguy]

I have just tried to build libheif on macOS 10.13.6 after running

sudo port clean libheif

sudo port selfupdate

and

sudo port upgrade outdated

The build still fails with

:info:build cd /opt/local/var/macports/build/libheif-31d816df/work/build/libheif && /opt/local/bin/clang++-mp-17 -DENABLE_MULTITHREADING_SUPPORT=1 -DENABLE_PARALLEL_TILE_DECODING=1 -DHAVE_AOM_DECODER=1 -DHAVE_AOM_ENCODER=1 -DHAVE_BIT -DHAVE_BROTLI=1 -DHAVE_DAV1D=1 -DHAVE_JPEG_DECODER=1 -DHAVE_JPEG_ENCODER=1 -DHAVE_KVAZAAR=1 -DHAVE_KVAZAAR_ENABLE_LOGGING=1 -DHAVE_KVAZAAR_VERSION_STRING=0 -DHAVE_LIBDE265=1 -DHAVE_LIBSHARPYUV=1 -DHAVE_OPENJPEG_DECODER=1 -DHAVE_OPENJPEG_ENCODER=1 -DHAVE_OpenH264_DECODER=1 -DHAVE_SvtEnc=1 -DHAVE_UNISTD_H -DHAVE_VISIBILITY -DHAVE_X264=1 -DHAVE_X265=1 -DHAVE_ZLIB=1 -DIS_BIG_ENDIAN=0 -DLIBHEIF_EXPORTS -DWITH_UNCOMPRESSED_CODEC=1 -Dheif_EXPORTS -I/opt/local/var/macports/build/libheif-31d816df/work/build -I/opt/local/var/macports/build/libheif-31d816df/work/libheif-1.23.0/libheif -I/opt/local/var/macports/build/libheif-31d816df/work/libheif-1.23.0/libheif/api -I/opt/local/var/macports/build/libheif-31d816df/work/libheif-1.23.0/include/libheif -I/opt/local/var/macports/build/libheif-31d816df/work/libheif-1.23.0/include -I/opt/local/include/webp -isystem /opt/local/include -isystem /opt/local/include/openjpeg-2.5 -pipe -Os -Wno-nonportable-include-path -Wno-error=nonportable-include-path -Wno-unknown-warning-option -Wno-error=unknown-warning-option -DNDEBUG -isystem/opt/local/include/libcxx/v1 -nostdinc++ -isystem/opt/local/include/LegacySupport -I/opt/local/include -stdlib=libc++ -std=c++20 -arch x86_64 -mmacosx-version-min=10.13 -fPIC -fvisibility=hidden -fvisibility-inlines-hidden -Wall -Wsign-compare -Wconversion -Wno-sign-conversion -Wno-error=conversion -Wno-error=unused-parameter -Wno-error=deprecated-declarations -Wno-error=tautological-compare -Wno-error=tautological-constant-out-of-range-compare -Wno-error=potentially-evaluated-expression -MD -MT libheif/CMakeFiles/heif.dir/nclx.cc.o -MF CMakeFiles/heif.dir/nclx.cc.o.d -o CMakeFiles/heif.dir/nclx.cc.o -c /opt/local/var/macports/build/libheif-31d816df/work/libheif-1.23.0/libheif/nclx.cc
:info:build [  6%] Building CXX object libheif/CMakeFiles/heif.dir/security_limits.cc.o
:info:build cd /opt/local/var/macports/build/libheif-31d816df/work/build/libheif && /opt/local/bin/clang++-mp-17 -DENABLE_MULTITHREADING_SUPPORT=1 -DENABLE_PARALLEL_TILE_DECODING=1 -DHAVE_AOM_DECODER=1 -DHAVE_AOM_ENCODER=1 -DHAVE_BIT -DHAVE_BROTLI=1 -DHAVE_DAV1D=1 -DHAVE_JPEG_DECODER=1 -DHAVE_JPEG_ENCODER=1 -DHAVE_KVAZAAR=1 -DHAVE_KVAZAAR_ENABLE_LOGGING=1 -DHAVE_KVAZAAR_VERSION_STRING=0 -DHAVE_LIBDE265=1 -DHAVE_LIBSHARPYUV=1 -DHAVE_OPENJPEG_DECODER=1 -DHAVE_OPENJPEG_ENCODER=1 -DHAVE_OpenH264_DECODER=1 -DHAVE_SvtEnc=1 -DHAVE_UNISTD_H -DHAVE_VISIBILITY -DHAVE_X264=1 -DHAVE_X265=1 -DHAVE_ZLIB=1 -DIS_BIG_ENDIAN=0 -DLIBHEIF_EXPORTS -DWITH_UNCOMPRESSED_CODEC=1 -Dheif_EXPORTS -I/opt/local/var/macports/build/libheif-31d816df/work/build -I/opt/local/var/macports/build/libheif-31d816df/work/libheif-1.23.0/libheif -I/opt/local/var/macports/build/libheif-31d816df/work/libheif-1.23.0/libheif/api -I/opt/local/var/macports/build/libheif-31d816df/work/libheif-1.23.0/include/libheif -I/opt/local/var/macports/build/libheif-31d816df/work/libheif-1.23.0/include -I/opt/local/include/webp -isystem /opt/local/include -isystem /opt/local/include/openjpeg-2.5 -pipe -Os -Wno-nonportable-include-path -Wno-error=nonportable-include-path -Wno-unknown-warning-option -Wno-error=unknown-warning-option -DNDEBUG -isystem/opt/local/include/libcxx/v1 -nostdinc++ -isystem/opt/local/include/LegacySupport -I/opt/local/include -stdlib=libc++ -std=c++20 -arch x86_64 -mmacosx-version-min=10.13 -fPIC -fvisibility=hidden -fvisibility-inlines-hidden -Wall -Wsign-compare -Wconversion -Wno-sign-conversion -Wno-error=conversion -Wno-error=unused-parameter -Wno-error=deprecated-declarations -Wno-error=tautological-compare -Wno-error=tautological-constant-out-of-range-compare -Wno-error=potentially-evaluated-expression -MD -MT libheif/CMakeFiles/heif.dir/security_limits.cc.o -MF CMakeFiles/heif.dir/security_limits.cc.o.d -o CMakeFiles/heif.dir/security_limits.cc.o -c /opt/local/var/macports/build/libheif-31d816df/work/libheif-1.23.0/libheif/security_limits.cc
:info:build /opt/local/var/macports/build/libheif-31d816df/work/libheif-1.23.0/libheif/box.cc:4155:15: error: no member named 'ranges' in namespace 'std'
:info:build  4155 |   return std::ranges::all_of(m_reference_types, [](uint32_t t) {
:info:build       |          ~~~~~^
:info:build /opt/local/var/macports/build/libheif-31d816df/work/libheif-1.23.0/libheif/box.cc:4156:17: error: no member named 'ranges' in namespace 'std'
:info:build  4156 |     return std::ranges::find(supported_reference_types, t) != supported_reference_types.end();
:info:build       |            ~~~~~^
:info:build /opt/local/var/macports/build/libheif-31d816df/work/libheif-1.23.0/libheif/box.cc:4166:14: error: no member named 'ranges' in namespace 'std'
:info:build  4166 |     if (std::ranges::find(supported_reference_types, refType) == supported_reference_types.end()) {
:info:build       |         ~~~~~^
:info:build [  7%] Building CXX object libheif/CMakeFiles/heif.dir/init.cc.o
:info:build cd /opt/local/var/macports/build/libheif-31d816df/work/build/libheif && /opt/local/bin/clang++-mp-17 -DENABLE_MULTITHREADING_SUPPORT=1 -DENABLE_PARALLEL_TILE_DECODING=1 -DHAVE_AOM_DECODER=1 -DHAVE_AOM_ENCODER=1 -DHAVE_BIT -DHAVE_BROTLI=1 -DHAVE_DAV1D=1 -DHAVE_JPEG_DECODER=1 -DHAVE_JPEG_ENCODER=1 -DHAVE_KVAZAAR=1 -DHAVE_KVAZAAR_ENABLE_LOGGING=1 -DHAVE_KVAZAAR_VERSION_STRING=0 -DHAVE_LIBDE265=1 -DHAVE_LIBSHARPYUV=1 -DHAVE_OPENJPEG_DECODER=1 -DHAVE_OPENJPEG_ENCODER=1 -DHAVE_OpenH264_DECODER=1 -DHAVE_SvtEnc=1 -DHAVE_UNISTD_H -DHAVE_VISIBILITY -DHAVE_X264=1 -DHAVE_X265=1 -DHAVE_ZLIB=1 -DIS_BIG_ENDIAN=0 -DLIBHEIF_EXPORTS -DWITH_UNCOMPRESSED_CODEC=1 -Dheif_EXPORTS -I/opt/local/var/macports/build/libheif-31d816df/work/build -I/opt/local/var/macports/build/libheif-31d816df/work/libheif-1.23.0/libheif -I/opt/local/var/macports/build/libheif-31d816df/work/libheif-1.23.0/libheif/api -I/opt/local/var/macports/build/libheif-31d816df/work/libheif-1.23.0/include/libheif -I/opt/local/var/macports/build/libheif-31d816df/work/libheif-1.23.0/include -I/opt/local/include/webp -isystem /opt/local/include -isystem /opt/local/include/openjpeg-2.5 -pipe -Os -Wno-nonportable-include-path -Wno-error=nonportable-include-path -Wno-unknown-warning-option -Wno-error=unknown-warning-option -DNDEBUG -isystem/opt/local/include/libcxx/v1 -nostdinc++ -isystem/opt/local/include/LegacySupport -I/opt/local/include -stdlib=libc++ -std=c++20 -arch x86_64 -mmacosx-version-min=10.13 -fPIC -fvisibility=hidden -fvisibility-inlines-hidden -Wall -Wsign-compare -Wconversion -Wno-sign-conversion -Wno-error=conversion -Wno-error=unused-parameter -Wno-error=deprecated-declarations -Wno-error=tautological-compare -Wno-error=tautological-constant-out-of-range-compare -Wno-error=potentially-evaluated-expression -MD -MT libheif/CMakeFiles/heif.dir/init.cc.o -MF CMakeFiles/heif.dir/init.cc.o.d -o CMakeFiles/heif.dir/init.cc.o -c /opt/local/var/macports/build/libheif-31d816df/work/libheif-1.23.0/libheif/init.cc
:info:build [  7%] Building CXX object libheif/CMakeFiles/heif.dir/logging.cc.o
:info:build cd /opt/local/var/macports/build/libheif-31d816df/work/build/libheif && /opt/local/bin/clang++-mp-17 -DENABLE_MULTITHREADING_SUPPORT=1 -DENABLE_PARALLEL_TILE_DECODING=1 -DHAVE_AOM_DECODER=1 -DHAVE_AOM_ENCODER=1 -DHAVE_BIT -DHAVE_BROTLI=1 -DHAVE_DAV1D=1 -DHAVE_JPEG_DECODER=1 -DHAVE_JPEG_ENCODER=1 -DHAVE_KVAZAAR=1 -DHAVE_KVAZAAR_ENABLE_LOGGING=1 -DHAVE_KVAZAAR_VERSION_STRING=0 -DHAVE_LIBDE265=1 -DHAVE_LIBSHARPYUV=1 -DHAVE_OPENJPEG_DECODER=1 -DHAVE_OPENJPEG_ENCODER=1 -DHAVE_OpenH264_DECODER=1 -DHAVE_SvtEnc=1 -DHAVE_UNISTD_H -DHAVE_VISIBILITY -DHAVE_X264=1 -DHAVE_X265=1 -DHAVE_ZLIB=1 -DIS_BIG_ENDIAN=0 -DLIBHEIF_EXPORTS -DWITH_UNCOMPRESSED_CODEC=1 -Dheif_EXPORTS -I/opt/local/var/macports/build/libheif-31d816df/work/build -I/opt/local/var/macports/build/libheif-31d816df/work/libheif-1.23.0/libheif -I/opt/local/var/macports/build/libheif-31d816df/work/libheif-1.23.0/libheif/api -I/opt/local/var/macports/build/libheif-31d816df/work/libheif-1.23.0/include/libheif -I/opt/local/var/macports/build/libheif-31d816df/work/libheif-1.23.0/include -I/opt/local/include/webp -isystem /opt/local/include -isystem /opt/local/include/openjpeg-2.5 -pipe -Os -Wno-nonportable-include-path -Wno-error=nonportable-include-path -Wno-unknown-warning-option -Wno-error=unknown-warning-option -DNDEBUG -isystem/opt/local/include/libcxx/v1 -nostdinc++ -isystem/opt/local/include/LegacySupport -I/opt/local/include -stdlib=libc++ -std=c++20 -arch x86_64 -mmacosx-version-min=10.13 -fPIC -fvisibility=hidden -fvisibility-inlines-hidden -Wall -Wsign-compare -Wconversion -Wno-sign-conversion -Wno-error=conversion -Wno-error=unused-parameter -Wno-error=deprecated-declarations -Wno-error=tautological-compare -Wno-error=tautological-constant-out-of-range-compare -Wno-error=potentially-evaluated-expression -MD -MT libheif/CMakeFiles/heif.dir/logging.cc.o -MF CMakeFiles/heif.dir/logging.cc.o.d -o CMakeFiles/heif.dir/logging.cc.o -c /opt/local/var/macports/build/libheif-31d816df/work/libheif-1.23.0/libheif/logging.cc
:info:build [  8%] Building CXX object libheif/CMakeFiles/heif.dir/compression.cc.o
:info:build cd /opt/local/var/macports/build/libheif-31d816df/work/build/libheif && /opt/local/bin/clang++-mp-17 -DENABLE_MULTITHREADING_SUPPORT=1 -DENABLE_PARALLEL_TILE_DECODING=1 -DHAVE_AOM_DECODER=1 -DHAVE_AOM_ENCODER=1 -DHAVE_BIT -DHAVE_BROTLI=1 -DHAVE_DAV1D=1 -DHAVE_JPEG_DECODER=1 -DHAVE_JPEG_ENCODER=1 -DHAVE_KVAZAAR=1 -DHAVE_KVAZAAR_ENABLE_LOGGING=1 -DHAVE_KVAZAAR_VERSION_STRING=0 -DHAVE_LIBDE265=1 -DHAVE_LIBSHARPYUV=1 -DHAVE_OPENJPEG_DECODER=1 -DHAVE_OPENJPEG_ENCODER=1 -DHAVE_OpenH264_DECODER=1 -DHAVE_SvtEnc=1 -DHAVE_UNISTD_H -DHAVE_VISIBILITY -DHAVE_X264=1 -DHAVE_X265=1 -DHAVE_ZLIB=1 -DIS_BIG_ENDIAN=0 -DLIBHEIF_EXPORTS -DWITH_UNCOMPRESSED_CODEC=1 -Dheif_EXPORTS -I/opt/local/var/macports/build/libheif-31d816df/work/build -I/opt/local/var/macports/build/libheif-31d816df/work/libheif-1.23.0/libheif -I/opt/local/var/macports/build/libheif-31d816df/work/libheif-1.23.0/libheif/api -I/opt/local/var/macports/build/libheif-31d816df/work/libheif-1.23.0/include/libheif -I/opt/local/var/macports/build/libheif-31d816df/work/libheif-1.23.0/include -I/opt/local/include/webp -isystem /opt/local/include -isystem /opt/local/include/openjpeg-2.5 -pipe -Os -Wno-nonportable-include-path -Wno-error=nonportable-include-path -Wno-unknown-warning-option -Wno-error=unknown-warning-option -DNDEBUG -isystem/opt/local/include/libcxx/v1 -nostdinc++ -isystem/opt/local/include/LegacySupport -I/opt/local/include -stdlib=libc++ -std=c++20 -arch x86_64 -mmacosx-version-min=10.13 -fPIC -fvisibility=hidden -fvisibility-inlines-hidden -Wall -Wsign-compare -Wconversion -Wno-sign-conversion -Wno-error=conversion -Wno-error=unused-parameter -Wno-error=deprecated-declarations -Wno-error=tautological-compare -Wno-error=tautological-constant-out-of-range-compare -Wno-error=potentially-evaluated-expression -MD -MT libheif/CMakeFiles/heif.dir/compression.cc.o -MF CMakeFiles/heif.dir/compression.cc.o.d -o CMakeFiles/heif.dir/compression.cc.o -c /opt/local/var/macports/build/libheif-31d816df/work/libheif-1.23.0/libheif/compression.cc
:info:build [  9%] Building CXX object libheif/CMakeFiles/heif.dir/compression_brotli.cc.o
:info:build cd /opt/local/var/macports/build/libheif-31d816df/work/build/libheif && /opt/local/bin/clang++-mp-17 -DENABLE_MULTITHREADING_SUPPORT=1 -DENABLE_PARALLEL_TILE_DECODING=1 -DHAVE_AOM_DECODER=1 -DHAVE_AOM_ENCODER=1 -DHAVE_BIT -DHAVE_BROTLI=1 -DHAVE_DAV1D=1 -DHAVE_JPEG_DECODER=1 -DHAVE_JPEG_ENCODER=1 -DHAVE_KVAZAAR=1 -DHAVE_KVAZAAR_ENABLE_LOGGING=1 -DHAVE_KVAZAAR_VERSION_STRING=0 -DHAVE_LIBDE265=1 -DHAVE_LIBSHARPYUV=1 -DHAVE_OPENJPEG_DECODER=1 -DHAVE_OPENJPEG_ENCODER=1 -DHAVE_OpenH264_DECODER=1 -DHAVE_SvtEnc=1 -DHAVE_UNISTD_H -DHAVE_VISIBILITY -DHAVE_X264=1 -DHAVE_X265=1 -DHAVE_ZLIB=1 -DIS_BIG_ENDIAN=0 -DLIBHEIF_EXPORTS -DWITH_UNCOMPRESSED_CODEC=1 -Dheif_EXPORTS -I/opt/local/var/macports/build/libheif-31d816df/work/build -I/opt/local/var/macports/build/libheif-31d816df/work/libheif-1.23.0/libheif -I/opt/local/var/macports/build/libheif-31d816df/work/libheif-1.23.0/libheif/api -I/opt/local/var/macports/build/libheif-31d816df/work/libheif-1.23.0/include/libheif -I/opt/local/var/macports/build/libheif-31d816df/work/libheif-1.23.0/include -I/opt/local/include/webp -isystem /opt/local/include -isystem /opt/local/include/openjpeg-2.5 -pipe -Os -Wno-nonportable-include-path -Wno-error=nonportable-include-path -Wno-unknown-warning-option -Wno-error=unknown-warning-option -DNDEBUG -isystem/opt/local/include/libcxx/v1 -nostdinc++ -isystem/opt/local/include/LegacySupport -I/opt/local/include -stdlib=libc++ -std=c++20 -arch x86_64 -mmacosx-version-min=10.13 -fPIC -fvisibility=hidden -fvisibility-inlines-hidden -Wall -Wsign-compare -Wconversion -Wno-sign-conversion -Wno-error=conversion -Wno-error=unused-parameter -Wno-error=deprecated-declarations -Wno-error=tautological-compare -Wno-error=tautological-constant-out-of-range-compare -Wno-error=potentially-evaluated-expression -MD -MT libheif/CMakeFiles/heif.dir/compression_brotli.cc.o -MF CMakeFiles/heif.dir/compression_brotli.cc.o.d -o CMakeFiles/heif.dir/compression_brotli.cc.o -c /opt/local/var/macports/build/libheif-31d816df/work/libheif-1.23.0/libheif/compression_brotli.cc
:info:build [  9%] Building CXX object libheif/CMakeFiles/heif.dir/compression_zlib.cc.o
:info:build cd /opt/local/var/macports/build/libheif-31d816df/work/build/libheif && /opt/local/bin/clang++-mp-17 -DENABLE_MULTITHREADING_SUPPORT=1 -DENABLE_PARALLEL_TILE_DECODING=1 -DHAVE_AOM_DECODER=1 -DHAVE_AOM_ENCODER=1 -DHAVE_BIT -DHAVE_BROTLI=1 -DHAVE_DAV1D=1 -DHAVE_JPEG_DECODER=1 -DHAVE_JPEG_ENCODER=1 -DHAVE_KVAZAAR=1 -DHAVE_KVAZAAR_ENABLE_LOGGING=1 -DHAVE_KVAZAAR_VERSION_STRING=0 -DHAVE_LIBDE265=1 -DHAVE_LIBSHARPYUV=1 -DHAVE_OPENJPEG_DECODER=1 -DHAVE_OPENJPEG_ENCODER=1 -DHAVE_OpenH264_DECODER=1 -DHAVE_SvtEnc=1 -DHAVE_UNISTD_H -DHAVE_VISIBILITY -DHAVE_X264=1 -DHAVE_X265=1 -DHAVE_ZLIB=1 -DIS_BIG_ENDIAN=0 -DLIBHEIF_EXPORTS -DWITH_UNCOMPRESSED_CODEC=1 -Dheif_EXPORTS -I/opt/local/var/macports/build/libheif-31d816df/work/build -I/opt/local/var/macports/build/libheif-31d816df/work/libheif-1.23.0/libheif -I/opt/local/var/macports/build/libheif-31d816df/work/libheif-1.23.0/libheif/api -I/opt/local/var/macports/build/libheif-31d816df/work/libheif-1.23.0/include/libheif -I/opt/local/var/macports/build/libheif-31d816df/work/libheif-1.23.0/include -I/opt/local/include/webp -isystem /opt/local/include -isystem /opt/local/include/openjpeg-2.5 -pipe -Os -Wno-nonportable-include-path -Wno-error=nonportable-include-path -Wno-unknown-warning-option -Wno-error=unknown-warning-option -DNDEBUG -isystem/opt/local/include/libcxx/v1 -nostdinc++ -isystem/opt/local/include/LegacySupport -I/opt/local/include -stdlib=libc++ -std=c++20 -arch x86_64 -mmacosx-version-min=10.13 -fPIC -fvisibility=hidden -fvisibility-inlines-hidden -Wall -Wsign-compare -Wconversion -Wno-sign-conversion -Wno-error=conversion -Wno-error=unused-parameter -Wno-error=deprecated-declarations -Wno-error=tautological-compare -Wno-error=tautological-constant-out-of-range-compare -Wno-error=potentially-evaluated-expression -MD -MT libheif/CMakeFiles/heif.dir/compression_zlib.cc.o -MF CMakeFiles/heif.dir/compression_zlib.cc.o.d -o CMakeFiles/heif.dir/compression_zlib.cc.o -c /opt/local/var/macports/build/libheif-31d816df/work/libheif-1.23.0/libheif/compression_zlib.cc
:info:build [  9%] Building CXX object libheif/CMakeFiles/heif.dir/region.cc.o
:info:build [ 10%] Building CXX object libheif/CMakeFiles/heif.dir/common_utils.cc.o
:info:build cd /opt/local/var/macports/build/libheif-31d816df/work/build/libheif && /opt/local/bin/clang++-mp-17 -DENABLE_MULTITHREADING_SUPPORT=1 -DENABLE_PARALLEL_TILE_DECODING=1 -DHAVE_AOM_DECODER=1 -DHAVE_AOM_ENCODER=1 -DHAVE_BIT -DHAVE_BROTLI=1 -DHAVE_DAV1D=1 -DHAVE_JPEG_DECODER=1 -DHAVE_JPEG_ENCODER=1 -DHAVE_KVAZAAR=1 -DHAVE_KVAZAAR_ENABLE_LOGGING=1 -DHAVE_KVAZAAR_VERSION_STRING=0 -DHAVE_LIBDE265=1 -DHAVE_LIBSHARPYUV=1 -DHAVE_OPENJPEG_DECODER=1 -DHAVE_OPENJPEG_ENCODER=1 -DHAVE_OpenH264_DECODER=1 -DHAVE_SvtEnc=1 -DHAVE_UNISTD_H -DHAVE_VISIBILITY -DHAVE_X264=1 -DHAVE_X265=1 -DHAVE_ZLIB=1 -DIS_BIG_ENDIAN=0 -DLIBHEIF_EXPORTS -DWITH_UNCOMPRESSED_CODEC=1 -Dheif_EXPORTS -I/opt/local/var/macports/build/libheif-31d816df/work/build -I/opt/local/var/macports/build/libheif-31d816df/work/libheif-1.23.0/libheif -I/opt/local/var/macports/build/libheif-31d816df/work/libheif-1.23.0/libheif/api -I/opt/local/var/macports/build/libheif-31d816df/work/libheif-1.23.0/include/libheif -I/opt/local/var/macports/build/libheif-31d816df/work/libheif-1.23.0/include -I/opt/local/include/webp -isystem /opt/local/include -isystem /opt/local/include/openjpeg-2.5 -pipe -Os -Wno-nonportable-include-path -Wno-error=nonportable-include-path -Wno-unknown-warning-option -Wno-error=unknown-warning-option -DNDEBUG -isystem/opt/local/include/libcxx/v1 -nostdinc++ -isystem/opt/local/include/LegacySupport -I/opt/local/include -stdlib=libc++ -std=c++20 -arch x86_64 -mmacosx-version-min=10.13 -fPIC -fvisibility=hidden -fvisibility-inlines-hidden -Wall -Wsign-compare -Wconversion -Wno-sign-conversion -Wno-error=conversion -Wno-error=unused-parameter -Wno-error=deprecated-declarations -Wno-error=tautological-compare -Wno-error=tautological-constant-out-of-range-compare -Wno-error=potentially-evaluated-expression -MD -MT libheif/CMakeFiles/heif.dir/region.cc.o -MF CMakeFiles/heif.dir/region.cc.o.d -o CMakeFiles/heif.dir/region.cc.o -c /opt/local/var/macports/build/libheif-31d816df/work/libheif-1.23.0/libheif/region.cc
:info:build cd /opt/local/var/macports/build/libheif-31d816df/work/build/libheif && /opt/local/bin/clang++-mp-17 -DENABLE_MULTITHREADING_SUPPORT=1 -DENABLE_PARALLEL_TILE_DECODING=1 -DHAVE_AOM_DECODER=1 -DHAVE_AOM_ENCODER=1 -DHAVE_BIT -DHAVE_BROTLI=1 -DHAVE_DAV1D=1 -DHAVE_JPEG_DECODER=1 -DHAVE_JPEG_ENCODER=1 -DHAVE_KVAZAAR=1 -DHAVE_KVAZAAR_ENABLE_LOGGING=1 -DHAVE_KVAZAAR_VERSION_STRING=0 -DHAVE_LIBDE265=1 -DHAVE_LIBSHARPYUV=1 -DHAVE_OPENJPEG_DECODER=1 -DHAVE_OPENJPEG_ENCODER=1 -DHAVE_OpenH264_DECODER=1 -DHAVE_SvtEnc=1 -DHAVE_UNISTD_H -DHAVE_VISIBILITY -DHAVE_X264=1 -DHAVE_X265=1 -DHAVE_ZLIB=1 -DIS_BIG_ENDIAN=0 -DLIBHEIF_EXPORTS -DWITH_UNCOMPRESSED_CODEC=1 -Dheif_EXPORTS -I/opt/local/var/macports/build/libheif-31d816df/work/build -I/opt/local/var/macports/build/libheif-31d816df/work/libheif-1.23.0/libheif -I/opt/local/var/macports/build/libheif-31d816df/work/libheif-1.23.0/libheif/api -I/opt/local/var/macports/build/libheif-31d816df/work/libheif-1.23.0/include/libheif -I/opt/local/var/macports/build/libheif-31d816df/work/libheif-1.23.0/include -I/opt/local/include/webp -isystem /opt/local/include -isystem /opt/local/include/openjpeg-2.5 -pipe -Os -Wno-nonportable-include-path -Wno-error=nonportable-include-path -Wno-unknown-warning-option -Wno-error=unknown-warning-option -DNDEBUG -isystem/opt/local/include/libcxx/v1 -nostdinc++ -isystem/opt/local/include/LegacySupport -I/opt/local/include -stdlib=libc++ -std=c++20 -arch x86_64 -mmacosx-version-min=10.13 -fPIC -fvisibility=hidden -fvisibility-inlines-hidden -Wall -Wsign-compare -Wconversion -Wno-sign-conversion -Wno-error=conversion -Wno-error=unused-parameter -Wno-error=deprecated-declarations -Wno-error=tautological-compare -Wno-error=tautological-constant-out-of-range-compare -Wno-error=potentially-evaluated-expression -MD -MT libheif/CMakeFiles/heif.dir/common_utils.cc.o -MF CMakeFiles/heif.dir/common_utils.cc.o.d -o CMakeFiles/heif.dir/common_utils.cc.o -c /opt/local/var/macports/build/libheif-31d816df/work/libheif-1.23.0/libheif/common_utils.cc
:info:build 3 errors generated.
:info:build make[2]: *** [libheif/CMakeFiles/heif.dir/box.cc.o] Error 1
:info:build make[2]: *** Waiting for unfinished jobs....
:info:build make[2]: Leaving directory `/opt/local/var/macports/build/libheif-31d816df/work/build'
:info:build make[1]: *** [libheif/CMakeFiles/heif.dir/all] Error 2
:info:build make[1]: Leaving directory `/opt/local/var/macports/build/libheif-31d816df/work/build'
:info:build make: *** [all] Error 2
:info:build make: Leaving directory `/opt/local/var/macports/build/libheif-31d816df/work/build'
:info:build Command failed:  cd "/opt/local/var/macports/build/libheif-31d816df/work/build" && /usr/bin/make -j8 -w all VERBOSE=ON 
:info:build Exit code: 2
:error:build Failed to build libheif: command execution failed
:debug:build Error code: CHILDSTATUS 28414 2
:debug:build Backtrace: command execution failed
:debug:build     while executing
:debug:build "system {*}$notty {*}$callback {*}$nice $fullcmdstring"
:debug:build     invoked from within
:debug:build "command_exec -callback portprogress::target_progress_callback build"
:debug:build     (procedure "portbuild::build_main" line 10)
:debug:build     invoked from within
:debug:build "$procedure $targetname"
:error:build See /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_multimedia_libheif/libheif/main.log for details.

[Dave-Allured (Dave Allured)]

@seamusdemora @workflowsguy Yes. MacPorts builders for 10.7 Lion through 10.14 Mojave are all hitting the same error, no member named 'ranges' in namespace 'std'. 10.15 Catalina and above are all building libheif correctly. There is no need for further reports for 10.7 through 10.14.

As I already said, these std::ranges references are in a tiny amount of new C++20 code added in libheif 1.23.0. This is all due to a deficiency in MacPorts C++20 compilers, which is being worked on elsewhere.

IMO it is futile to expect the C++20 compiler problem to be solved quickly. For interim relief, please try either one of these simple fallback solutions:

• ​https://github.com/macports/macports-ports/pull/33032

• ​https://github.com/macports/macports-ports/pull/33100

[potmj (Michael Pot)]

Above is the attached file Portfile.ELCapitan fix. It should work on slightly newer OS, but only tested on ElCapitan. Perhaps try that by replacing the Portfile in your tree. Something like sudo cp -v Portfile.Elcapitan `port file libheif` might work. It would be great if someone else could test it :-)

[Dave-Allured (Dave Allured)]

@potmj I am impressed by all your work in Portfile.ELCapitan. It looks like you solved several problems beyond simply the <ranges> issue. Are you able to fix it up to work for all OS versions? Can you run your own pull request for it?

[potmj (Michael Pot)]

Replying to Dave-Allured:

@potmj I am impressed by all your work in Portfile.ELCapitan. It looks like you solved several problems beyond simply the <ranges> issue. Are you able to fix it up to work for all OS versions? Can you run your own pull request for it?

Sorry, I'm just an end user really. I was hoping once a few people have tested this libheif fix, the port maintainer could take over. There may be simpler ways to achieve the fixes, but I am not really a macports expert. I haven't got macports on this 10.13 machine yet, and I really do prefer 10.5.8, it is faster & cleaner for me, just nothing much works on 10.5.8 anymore - why I need to get these ports fixed!

Yes, there were lots of problems to solve, & it tied up with upstream developers writing to C++23, which has no easy way to build on old machines, because of holes in the old libraries, I guess. It is making it really hard for the Macports maintainers I guess, especially when end users just want to keep using their old un bloated machines.

It should work on 10.13 & 10.15, just untested

[seamusdemora (Seamus)]

Replying to Dave-Allured:

IMO it is futile to expect the C++20 compiler problem to be solved quickly. For interim relief, please try either one of these simple fallback solutions:

• ​https://github.com/macports/macports-ports/pull/33032

• ​https://github.com/macports/macports-ports/pull/33100

But it seems neither of those PRs has been approved... Which seems to mean that we are "out-of-luck" for a quick resolution - and it may be quite some time (weeks, months... years) before this is resolved.

This may be a dumb question, but is there no way to get back to the last working version? port rev-upgrade doesn't seem to work. In my case, I've got a broken ffmpeg7 port - does anyone know any solutions to repair ffmpeg7?

[ballapete (Peter "Pete" Dyballa)]

Replying to seamusdemora:

Replying to Dave-Allured:

This may be a dumb question, but is there no way to get back to the last working version? port rev-upgrade doesn't seem to work. In my case, I've got a broken ffmpeg7 port - does anyone know any solutions to repair ffmpeg7?

It is possible that you still have the previous versions installed. I think MacPorts only deactivates the old version and then it's up to you to make clean. port echo inactive will show these old versions and you can re-activate any old version. (Which might make rev-upgrade necessary to resolve particular bindings to old libraries, but maybe port activate <whatever> already resolves these dependencies.)

This might not be necessary!

It's only a new version of some component that cannot be built. The previous state of software, including that component, is still installed and working as before. At least on my Mac this *is* the case. Here I can listen to internet radio with ffplay.

[ballapete (Peter "Pete" Dyballa)]

Having to rev-upgrade libheif-1.21.2 I get now:

cd /opt/local/var/macports/build/libheif-020685e0/work/build/libheif && /opt/local/bin/clang++-mp-17 -DENABLE_MULTITHREADING_SUPPORT=1 -DENABLE_PARALLEL_TILE_DECODING=1 -DHAVE_AOM_DECODER=1 -DHAVE_AOM_ENCODER=1 -DHAVE_BIT -DHAVE_BROTLI=1 -DHAVE_DAV1D=1 -DHAVE_JPEG_DECODER=1 -DHAVE_JPEG_ENCODER=1 -DHAVE_KVAZAAR=1 -DHAVE_KVAZAAR_ENABLE_LOGGING=1 -DHAVE_LIBDE265=1 -DHAVE_LIBSHARPYUV=1 -DHAVE_OPENJPEG_DECODER=1 -DHAVE_OPENJPEG_ENCODER=1 -DHAVE_OpenH264_DECODER=1 -DHAVE_SvtEnc=1 -DHAVE_UNISTD_H -DHAVE_VISIBILITY -DHAVE_X264=1 -DHAVE_X265=1 -DHAVE_ZLIB=1 -DIS_BIG_ENDIAN=0 -DLIBHEIF_EXPORTS -DWITH_UNCOMPRESSED_CODEC=1 -Dheif_EXPORTS -I/opt/local/var/macports/build/libheif-020685e0/work/build -I/opt/local/var/macports/build/libheif-020685e0/work/libheif-1.21.2/libheif -I/opt/local/var/macports/build/libheif-020685e0/work/libheif-1.21.2/libheif/api -I/opt/local/var/macports/build/libheif-020685e0/work/libheif-1.21.2/include/libheif -I/opt/local/var/macports/build/libheif-020685e0/work/libheif-1.21.2/include -I/opt/local/include/webp -isystem /opt/local/include -isystem /opt/local/include/openjpeg-2.5 -pipe -Os -Wno-nonportable-include-path -Wno-error=nonportable-include-path -Wno-unknown-warning-option -Wno-error=unknown-warning-option -DNDEBUG -isystem/opt/local/include/libcxx/v1 -nostdinc++ -isystem/opt/local/include/LegacySupport -I/opt/local/include -stdlib=libc++ -std=c++20 -arch x86_64 -mmacosx-version-min=10.13 -fPIC -fvisibility=hidden -fvisibility-inlines-hidden   -Wall -Wsign-compare -Wconversion -Wno-sign-conversion -Wno-error=conversion -Wno-error=unused-parameter -Wno-error=deprecated-declarations -Wno-error=tautological-compare -Wno-error=tautological-constant-out-of-range-compare -Wno-error=potentially-evaluated-expression -MD -MT libheif/CMakeFiles/heif.dir/plugins/encoder_svt.cc.o -MF CMakeFiles/heif.dir/plugins/encoder_svt.cc.o.d -o CMakeFiles/heif.dir/plugins/encoder_svt.cc.o -c /opt/local/var/macports/build/libheif-020685e0/work/libheif-1.21.2/libheif/plugins/encoder_svt.cc
/opt/local/var/macports/build/libheif-020685e0/work/libheif-1.21.2/libheif/plugins/encoder_svt.cc:851:37: error: use of undeclared identifier 'SvtAv1PredStructure'; did you mean 'PredStructure'?
  851 |         svt_config.pred_structure = SvtAv1PredStructure::SVT_AV1_PRED_RANDOM_ACCESS;
      |                                     ^~~~~~~~~~~~~~~~~~~
      |                                     PredStructure
/opt/local/include/svt-av1/EbSvtAv1Enc.h:134:107: note: 'PredStructure' declared here
  134 | typedef enum PredStructure { ALL_INTRA, LOW_DELAY, RANDOM_ACCESS, PRED_TOTAL_COUNT, PRED_INVALID = 0xFF } PredStructure;
      |                                                                                                           ^
/opt/local/var/macports/build/libheif-020685e0/work/libheif-1.21.2/libheif/plugins/encoder_svt.cc:851:58: error: no member named 'SVT_AV1_PRED_RANDOM_ACCESS' in 'PredStructure'
  851 |         svt_config.pred_structure = SvtAv1PredStructure::SVT_AV1_PRED_RANDOM_ACCESS;
      |                                     ~~~~~~~~~~~~~~~~~~~~~^

I am pretty sure that two weeks ago compilation succeeded:

  libheif @1.21.2_3+examples+kvazaar (active) requested_variants='' platform='darwin 17' archs='x86_64' date='2026-05-31T22:36:04+0200'

What damage was done to MacPorts in-between?

[JohnFHall (John Hall)]

Well NOW I'm really buggered... my gotto app, for access to an old dos program, dosbox-x, now fails withh its dependency on something likely related to libheif. Frustrating, as I have no idea on the intenals of macports.

MacPRO:~ johnhall$ sudo port outdated
The following installed ports are outdated:
ffmpeg                         8.1_1 < 8.1.1_0
ffmpeg7                        7.1.2_1 < 7.1.4_0
ImageMagick                    6.9.13-46_0 < 6.9.13-50_0
libheif                        1.21.2_3 < 1.23.0_0
llvm-19                        19.1.7_2 < 19.1.7_3
llvm-21                        21.1.8_1 < 21.1.8_2
mpg123                         1.33.5_0 < 1.33.6_0
nss                            3.124_0 < 3.125_0
p5.34-business-isbn-data       20260604.1.0_0 < 20260611.1.0_0
p5.34-gd                       2.850.0_0 < 2.860.0_0
p5.34-test-simple              1.302.219_0 < 1.302.220_0
putty                          0.83_0 < 0.84_0
python313                      3.13.13_0 < 3.13.14_0
yt-dlp                         2026.03.17_0 < 2026.06.09_0
MacPRO:~ johnhall$ sudo port rev-upgrade
--->  Scanning binaries for linking errors
--->  Found 16 broken files, matching files to ports
--->  Found 4 broken ports, determining rebuild order
You can always run 'port rev-upgrade' again to fix errors.
The following ports will be rebuilt:
 dosbox @0.74
 libheif @1.21.2+examples+kvazaar
 ffmpeg @8.1+gpl2
 ffmpeg7 @7.1.2+gpl2+vmaf
Continue? [Y/n]: Y
The following port will be upgraded: dosbox
--->  Computing dependencies for dosbox
--->  Cleaning dosbox
The following port will be upgraded: libheif
--->  Computing dependencies for libheif
--->  Fetching archive for libheif
Attempting to fetch http://aarnet.au.packages.macports.org/macports-archives/libheif/libheif-1.23.0_0%2Bexamples%2Bkvazaar.darwin_17.x86_64.tbz2
Attempting to fetch http://kmq.jp.packages.macports.org/libheif/libheif-1.23.0_0%2Bexamples%2Bkvazaar.darwin_17.x86_64.tbz2
--->  Building libheif
Error: Failed to build libheif: command execution failed

[ballapete (Peter "Pete" Dyballa)]

Replying to JohnFHall:

Well NOW I'm really buggered... my gotto app, for access to an old dos program, dosbox-x, now fails withh its dependency on something likely related to libheif. Frustrating, as I have no idea on the intenals of macports.

MacPRO:~ johnhall$ sudo port outdated

port outdated does not need sudo.

To understand a bit of MacPorts internals:

port deps dosbox-x. This will show on which other software (ports) ffmpeg7 depends (why ffmpeg7 and not recent ffmpeg 8?). sudo port rev-upgrade shows that ffmpeg7 is broken. Exactly this can be the cause why dosbox-x is failing. My work-around with stupid sudo port rev-upgrade is:

1. Run sudo port build ffmpeg7 to create a (hopefully) fixed build of the failing port.
2. Install the fixed port over the faulty one – which is a bit tricky, because port thinks it's so clever: it sees that the port in question is already installed and not outdated and so nothing has to be done. There is no sudo port just-update-from-sources <whatever> or sudo port reinstall-from-sources <whatever>. So we have, maybe, up to three options here:

a) deactivate the faulty installed port: sudo port deactivate <whatever> and then install the just built port (I think it's not tested by me)

b) uninstall forcibly the faulty installed port: sudo port uninstall -f <whatever> and then install the just built port (performed many times, I have some guts – and successfully building it, + optionally testing it, gives some cause)

c) sudo port edit <Portfile> and increase the port's revision either by one or by some character (1 -> 1a or such) (not sure whether the latter works) and then build or better upgrade <port>

But likely your case is not that complicated with an outdated <port>. Just upgrade the outdated version of ffmpeg7! This should produce an unbroken port. But:

port rdeps ffmpeg7 | grep libheif

on the command line shows:

          libheif

port will try to first upgrade libheif. What will help here is to change in libheif's Portfile the version from 1.23.0 to old 1.21.2 and the new revision from 0 to 3.

These complications show that MacPorts needs a go back or such command to fetch an older copy of Portfile. At least for some ports on which too many other ports depend critically. (It can be a local store, I think, as for example tlmgr for TeX Live provides…) Or to forcibly upgrade some outdated port without first performing this on its dependencies.

[ballapete (Peter "Pete" Dyballa)]

Forgot to mention that all changes to Portfile will get lost upon next selfupdate. So it might be useful to save the changed version somewhere and restore it if needed. And before restoring it it could be advised to diff changed and original/new version!

[ballapete (Peter "Pete" Dyballa)]

Replying to ballapete:

Replying to JohnFHall:

Or to forcibly upgrade some outdated port without first performing this on its dependencies.

I think this already exists! Just found time to read again the man page:

      Installation and upgrade

       -n
           Don’t follow dependencies in upgrade (affects upgrade and install)

Could be exactly what JohnFHall needs: sudo port upgrade -n ffmpeg7. Maybe a -s is needed to build locally from sources, making the installation of compilers and libraries necessary… (And using -v too can help understanding how MacPorts works.)

Anyway, I'd first try sudo port -v upgrade -n ffmpeg7 and if that fails sudo port -sv upgrade -n ffmpeg7.

[ballapete (Peter "Pete" Dyballa)]

I found a use case for -n: TeX Live '26 on High Sierra. poppler would be needed, but it does not build, see #74000, #73696, … So I used -n when upgrading from the 2025 installation. First it had a side-effect: port did not want to fetch the sources archives. I had to fetch them manually (with no actual effect, it was kind of a dry-run, see later).

Now trying sudo port -vs upgrade -n texlive-basic texlive-common texlive-bin (because port would not follow all dependencies I have to name them all – which I know from invoking sudo port -vs upgrade texlive-basic) I get:

The following ports will be upgraded:
 texlive-basic
 texlive-common
 texlive-bin
Continue? [Y/n]: --->  Upgrading texlive-basic (1/3)
--->  Computing dependencies for texlive-basic..
The following dependencies will be installed:  texlive-bin +x11
Continue? [Y/n]: --->  Verifying checksums for texlive-bin
--->  Checksumming texlive-source-2026.78235-stripped.tar.xz
Error: Failed to checksum texlive-bin: texlive-source-2026.78235-stripped.tar.xz does not exist in /opt/local/var/macports/distfiles/texlive-bin
Error: See /opt/local/var/macports/logs/_opt_mports_macports-ports_tex_texlive-bin/texlive-bin/main.log for details.
Error: Follow https://guide.macports.org/#project.tickets if you believe there is a bug.

Running port -vs distfiles texlive-basic texlive-common texlive-bin I get listed, among other stuff:

--->  Distfiles for texlive-bin
[texlive-source-2026.78235-stripped.tar.xz] /opt/local/var/macports/distfiles/texlive-bin/texlive-source-2026.78235-stripped.tar.xz
 rmd160: bc01778e01cc99333dfea608268b28470eccb5ce
 sha256: 7446e1bf1d4a52216bdaa7fca19b9575ff7017acd37203c15d1deceba9c20bb8
 size: 44915484
…
 
[tlpkg-TeXLive-2026.78235.tar.xz] /opt/local/var/macports/distfiles/texlive-bin/tlpkg-TeXLive-2026.78235.tar.xz
 rmd160: a141d0c36dcdf9530ce4860dcd42a26c4e096a8a
 sha256: 7aad94fce00749288f9a1dd4a03bf482a62c4e84edef953fbf0491d098de9369
 size: 119340
…

These two files neither exist here nor are they fetched. OK, first I seem to need texlive-bin, so restart with that port first on line. Same zero effect.

Bad example… (I guess)

[JohnFHall (John Hall)]

Replying to ballapete:

Replying to ballapete:

Replying to JohnFHall:

Or to forcibly upgrade some outdated port without first performing this on its dependencies.

I think this already exists! Just found time to read again the man page:

      Installation and upgrade

       -n
           Don’t follow dependencies in upgrade (affects upgrade and install)

Could be exactly what JohnFHall needs: sudo port upgrade -n ffmpeg7. Maybe a -s is needed to build locally from sources, making the installation of compilers and libraries necessary… (And using -v too can help understanding how MacPorts works.)

Anyway, I'd first try sudo port -v upgrade -n ffmpeg7 and if that fails sudo port -sv upgrade -n ffmpeg7.

Thanks Peter,
I tried the build options suggested. It built ffmpeg7 ok, but still ran into libheif problem. Wasn't game to try Portfile suggestion.

dosbox-x fails not finding a (removed) by who knows what, dlylib
viz:
MacPRO:~ johnhall$ dosbox-x
dyld: Library not loaded: /opt/local/lib/libSvtAv1Enc.3.dylib
  Referenced from: /opt/local/lib/libavcodec.62.dylib
  Reason: image not found
Abort trap: 6              dosbox-x

There is a /opt/local/lib/libSvtAv1Enc.4.1.0.dylib, but no longer libSvtAv1Enc.3.1.2 (as found in time capsule backup).

I do appreciate your help, but I'm sorry, it's too hard for me. Looks like I wait for libheif fix or give macports a miss...

[ballapete (Peter "Pete" Dyballa)]

port can also be invoked with provides <some pathname>. This is not much helpful when something does not exist, but you found /opt/local/lib/libSvtAv1Enc.4.1.0.dylib, which could be the argument for provides. This way you can find out to which port the file could belong: svt-av1.

Similarly you can determine to which port /opt/local/lib/libavcodec.62.dylib belongs: ffmpeg. When ffmpeg was built and installed an older version of svt-av1 was installed and ffmpeg was set up to use that old dylib. sudo port rev-upgrade already showed you that ffmpeg was broken, and port outdated showed you that a new version exists. So easiest would be to just sudo port -v upgrade ffmpeg (or better sudo port -v upgrade -n ffmpeg?). This will fix the problem with gone /opt/local/lib/libSvtAv1Enc.3.dylib because the new version of ffmpeg will now be set up to use /opt/local/lib/libSvtAv1Enc.4.1.0.dylib instead.

Another option would be to re-activate the old version of svt-av1. port installed svt-av1 could show something similar to this:

The following ports are currently installed:
  emacs @29.3_1+imagemagick+x11
  emacs @29.4_1+imagemagick+x11 (active)

The (active) version is the one in use, the other one(s) are kind of slag, or backups (for me). You could re-activate the old version of svt-av1 à la sudo port activate emacs @29.3_1+imagemagick+x11 (the whole line with the old version of svt-av1), but this could make other, upgraded software unusable. To check which software now depends on the new version of svt-av1 run port echo installed and 'depends::svt-av1(\s|$)'.

[JohnFHall (John Hall)]

Replying to ballapete:

Thank you for your exquisite detailed help.

port echo installed and 'depends::svt-av1(\s|$)' returns nothing, even with ffmpeg7 active

My very temporary solution to dosbox-x not finding dylib, is to extract old libSvtAv1Enc.3.1.2.dylib from time capsule, and rename it to /opt/local/lib/libSvtAv1Enc.3.dylib

[ballapete (Peter "Pete" Dyballa)]

Replying to JohnFHall:

Replying to ballapete:

port echo installed and 'depends::svt-av1(\s|$)' returns nothing, even with ffmpeg7 active

Maybe outdated instead of installed returns something…

[ballapete (Peter "Pete" Dyballa)]

Replying to ryandesign: Does this change mean that the upgrade was set free without testing?

[seamusdemora (Seamus)]

This is not a complaint, but a sanity check for my thinking. MacPorts on my Mojave system seems to have been broken for several weeks (maybe since ~ #73985). From my reading of some of the posts here & in related tickets, it seems the following may accurately summarize the situation:

• it has become impossible to compile programs on some of the older systems (e.g. Mojave)

• unfortunately these failures to compile may have left some of us without any working version of our ports; "some of us" may mean only those who foolishly used sudo port reclaim after the system prompted us to do so.

• there seems to be no good/easy/documented way to "put MacPorts in reverse" to recover these lost and broken ports.

• there may or may not be a "fix" for the above maladies; if there is a fix, that fix may be a long time in coming.

If the above is is an accurate summary of the current situation, I'm not the only one who's disappointed. After pondering the situation for a few days the only course of action that comes to mind is to take the drastic step of uninstalling MacPorts. Some of the ports (e.g. ffmpeg) are still currently available from other sources... whether or not and how well they work of course remain to be seen. This sounds like being caught between the proverbial "rock and a hard place".

Other thoughts & comments are solicited!

[ballapete (Peter "Pete" Dyballa)]

Is your ffmpeg really broken? All that is happening is that the new version of libheif does not compile. The old installation should be intact, and ffmpeg as well.

[ballapete (Peter "Pete" Dyballa)]

Presumingly I never used sudo port reclaim, instead performing tidying manually and controlled. In tcsh…

port echo inactive | egrep -v 'xorg-server|freetype|emacs' > /tmp/2much && cat /tmp/2much finds all unused, inactive ports. Ports that are important for me (xorg-server|freetype|emacs), are filtered out. The cat /tmp/2much lists for me what has been found as obsolete. I can check whether there is something I better should keep. For the next run I can extend the filter list.

foreach PORT ( `cat /tmp/2much | sed -e 's/^  //' | tr ' ' /` )
 port -v uninstall `echo $PORT | tr / ' '`
end

finally uninstalls the old software, leaving sources in /opt/local/var/macports/distfiles/ – some ports do not come as pre-built binaries.

In bash the latter loop would be something like

IFS=$(echo -ne "\n\b")
for PORT in `cat /tmp/2much`
do
  sudo port uninstall $PORT
done

Since $IFS, the shell's Internal Field Separator, was changed in that instance, it should be killed afterwards. Usually IFS contains SPACE, CHARACTER TABULATION and LINE FEED characters. I am not sure how to re-establish that. Another option would be to turn all SPACE sequences into a single character and preserve it as for example '·‘ (MIDDLE DOT). So the lines of port name and port version are preserved and finally each of these single "words" has to be turned via $(echo $PORT | tr '·' ' ') into a line sudo port uninstall can understand.

[ryandesign (Ryan Carsten Schmidt)]

Replying to ballapete:

Replying to ryandesign: Does this change mean that the upgrade was set free without testing?

I'm not the right person to ask since I didn't do the update, but looking up what happened (which anyone can do), I see that it was ​submitted as a pull request and that it passed CI builds on macOS 14, 15, and 26. Very few contributors check their ports on older systems so the failure on macOS 10.14 and earlier wasn't discovered until it went through the buildbot.

[ryandesign (Ryan Carsten Schmidt)]

Replying to seamusdemora:

• it has become impossible to compile programs on some of the older systems (e.g. Mojave)

The fact that as software evolves its requirements increase, making it incompatible with older systems, is not a new phenomenon.

• unfortunately these failures to compile may have left some of us without any working version of our ports; "some of us" may mean only those who foolishly used sudo port reclaim after the system prompted us to do so.

• there seems to be no good/easy/documented way to "put MacPorts in reverse" to recover these lost and broken ports.

See wiki:howto/InstallingOlderPort

• there may or may not be a "fix" for the above maladies; if there is a fix, that fix may be a long time in coming.

MacPorts is a volunteer project. Anyone can volunteer to fix any issue at any time.

In this case, the libheif port is already programmed to offer an older version (1.18.2) to Mac OS X 10.6 and older while offering the latest version (1.23.0) to newer systems. That mechanism could be extended to offer an intermediate version (perhaps 1.21.2 which we were using before) to Mac OS X 10.7 thru 10.14 while retaining 1.23.0 for newer systems.

@i0ntempest, what do you think?

Other thoughts & comments are solicited!

You would reach a wider audience by soliciting these thoughts and comments on the ​macports-users mailing list.

[JULWAL1 (Jules Warm)]

This worked for me on macOS Sierra:

sudo port upgrade libheif configure.compiler=macports-gcc-15 configure.cxx_stdlib=libstdc++ configure.cxxflags="-std=c++20" configure.cppflags=""

$ sudo port upgrade -n libheif configure.compiler=macports-gcc-15 configure.cxx_stdlib=libstdc++
The following port will be upgraded: libheif
Continue? [Y/n]: y
--->  Computing dependencies for libheif
--->  Fetching distfiles for libheif
--->  Verifying checksums for libheif
--->  Extracting libheif
--->  Configuring libheif
--->  Building libheif                                   
--->  Staging libheif into destroot                      
--->  Installing libheif @1.23.0_0+examples+kvazaar
--->  Cleaning libheif
--->  Computing dependencies for libheif
--->  Deactivating libheif @1.21.2_3+examples+kvazaar
--->  Cleaning libheif
--->  Activating libheif @1.23.0_0+examples+kvazaar
--->  Cleaning libheif                                   
--->  Scanning binaries for linking errors
--->  Found 13 broken files, matching files to ports     
--->  Found 2 broken ports, determining rebuild order
You can always run 'port rev-upgrade' again to fix errors.
The following ports will be rebuilt:
 gd2 @2.3.3+x11
 ImageMagick @6.9.13-46+openexr+x11
Continue? [Y/n]: y
The following port will be upgraded: gd2
--->  Computing dependencies for gd2
--->  Cleaning gd2
The following port will be upgraded: ImageMagick
The following new ports will be installed as dependencies: jxrlib libsdl12 libsdl libsdl_image libbpg xdg-utils
--->  Installing jxrlib @1.4.0_0 (1/7)
--->  Fetching archive for jxrlib
--->  Installing jxrlib @1.4.0_0
--->  Activating jxrlib @1.4.0_0
--->  Cleaning jxrlib
--->  Installing libsdl12 @1.2.15-20250302_0 (2/7)
--->  Fetching archive for libsdl12
--->  Installing libsdl12 @1.2.15-20250302_0
--->  Activating libsdl12 @1.2.15-20250302_0
--->  Cleaning libsdl12                                  
--->  Installing libsdl @1.2.15-20220801_1+legacy (3/7)
--->  Computing dependencies for libsdl
--->  Fetching archive for libsdl
--->  Installing libsdl @1.2.15-20220801_1+legacy
--->  Activating libsdl @1.2.15-20220801_1+legacy
--->  Cleaning libsdl
--->  Installing libsdl_image @1.2.12-20220527_1 (4/7)
--->  Computing dependencies for libsdl_image
--->  Fetching archive for libsdl_image
--->  Installing libsdl_image @1.2.12-20220527_1
--->  Activating libsdl_image @1.2.12-20220527_1
--->  Cleaning libsdl_image
--->  Installing libbpg @0.9.8_1 (5/7)
--->  Computing dependencies for libbpg
--->  Fetching archive for libbpg
--->  Installing libbpg @0.9.8_1
--->  Activating libbpg @0.9.8_1
--->  Cleaning libbpg
--->  Installing xdg-utils @1.2.1_0 (6/7)
--->  Fetching archive for xdg-utils
--->  Installing xdg-utils @1.2.1_0
--->  Activating xdg-utils @1.2.1_0
--->  Cleaning xdg-utils                                 
--->  Upgrading ImageMagick (7/7)
--->  Computing dependencies for ImageMagick
--->  Cleaning ImageMagick
--->  Scanning binaries for linking errors
--->  Found 13 broken files, matching files to ports     
--->  Found 2 broken ports, determining rebuild order
--->  Rebuilding in order
     gd2 @2.3.3_7+x11
     ImageMagick @6.9.13-46_0+openexr+x11
The following port will be upgraded: gd2
--->  Computing dependencies for gd2
--->  Fetching distfiles for gd2
Attempting to fetch https://github.com/libgd/libgd/releases/download/gd-2.3.3/libgd-2.3.3.tar.xz
--->  Verifying checksums for gd2
--->  Extracting gd2
--->  Applying patches to gd2
--->  Configuring gd2
--->  Building gd2                                       
--->  Staging gd2 into destroot                          
--->  Unable to uninstall gd2 @2.3.3_7+x11, the following ports depend on it:
--->  	graphviz @12.2.1_0+pangocairo+x11
Warning: Uninstall forced.  Proceeding despite dependencies.
--->  Deactivating gd2 @2.3.3_7+x11
--->  Cleaning gd2
--->  Uninstalling gd2 @2.3.3_7+x11
--->  Cleaning gd2
--->  Computing dependencies for gd2
--->  Installing gd2 @2.3.3_7+x11
--->  Activating gd2 @2.3.3_7+x11
--->  Cleaning gd2
The following port will be upgraded: ImageMagick
--->  Computing dependencies for ImageMagick
--->  Fetching distfiles for ImageMagick
Attempting to fetch https://distfiles.macports.org/ImageMagick/ImageMagick-6.9.13-46.tar.xz
--->  Verifying checksums for ImageMagick                                            
--->  Extracting ImageMagick
--->  Configuring ImageMagick
--->  Building ImageMagick                               
--->  Staging ImageMagick into destroot                  
--->  Deactivating ImageMagick @6.9.13-46_0+openexr+x11  
--->  Cleaning ImageMagick                               
--->  Uninstalling ImageMagick @6.9.13-46_0+openexr+x11
--->  Cleaning ImageMagick
--->  Computing dependencies for ImageMagick
--->  Installing ImageMagick @6.9.13-46_0+openexr+x11
--->  Activating ImageMagick @6.9.13-46_0+openexr+x11
--->  Cleaning ImageMagick                               
--->  Scanning binaries for linking errors
--->  No broken files found.                             
--->  No broken ports found.
--->  Some of the ports you installed have notes:
  libheif has the following notes:
    Support for rav1e now disabled by default; enable via +rav1e


$ port installed libheif
The following ports are currently installed:
  libheif @1.21.2_3+examples+kvazaar
  libheif @1.23.0_0+examples+kvazaar (active)


$ port contents libheif | grep libheif.dylib
  /opt/local/lib/libheif.dylib


$ otool -L /opt/local/lib/libheif.dylib
/opt/local/lib/libheif.dylib:
	/opt/local/lib/libheif.1.dylib (compatibility version 1.0.0, current version 1.23.0)
	/opt/local/lib/libMacportsLegacySupport.dylib (compatibility version 1.0.0, current version 1.5.2)
	/opt/local/lib/libx265.216.dylib (compatibility version 216.0.0, current version 216.0.0)
	/opt/local/lib/libde265.0.dylib (compatibility version 0.0.0, current version 0.1.12)
	/opt/local/lib/libdav1d.7.dylib (compatibility version 7.0.0, current version 7.0.0)
	/opt/local/lib/libaom.3.dylib (compatibility version 3.0.0, current version 3.13.1)
	/opt/local/lib/libSvtAv1Enc.3.dylib (compatibility version 3.0.0, current version 3.1.2)
	/opt/local/lib/libjpeg.8.dylib (compatibility version 8.0.0, current version 8.3.2)
	/opt/local/lib/libopenjp2.7.dylib (compatibility version 7.0.0, current version 2.5.4)
	/opt/local/lib/libkvazaar.7.dylib (compatibility version 13.0.0, current version 13.0.0)
	/opt/local/lib/libx264.165.dylib (compatibility version 0.0.0, current version 0.0.0)
	/opt/local/lib/libopenh264.7.dylib (compatibility version 7.0.0, current version 7.0.0)
	/opt/local/lib/libsharpyuv.0.dylib (compatibility version 2.0.0, current version 2.2.0)
	/opt/local/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.3.2)
	/opt/local/lib/libbrotlidec.1.dylib (compatibility version 1.0.0, current version 1.2.0)
	/opt/local/lib/libbrotlienc.1.dylib (compatibility version 1.0.0, current version 1.2.0)
	@rpath/libstdc++.6.dylib (compatibility version 7.0.0, current version 7.34.0)
	@rpath/libgcc_s.1.1.dylib (compatibility version 1.0.0, current version 1.1.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1238.60.2)


$ heif-info --version
1.23.0
libheif: 1.23.0
plugin path: plugins are disabled

(Ignore the $ terminal prompt)

As a side-note and without going-off on a tangent...

I was experimenting with MacPorts Clang-16 to 21 and the following command does successfully compile c++20 code on macOS Sierra:

clang++-mp-16 -std=c++20 -D_LIBCPP_DISABLE_AVAILABILITY -nostdinc++   -isysroot "$(xcrun --show-sdk-path 2>/dev/null)"   -I/opt/local/libexec/llvm-16/include/c++/v1   -I/opt/local/include/libfmt11   -L/opt/local/lib/libfmt11   -lfmt   /opt/local/lib/libcxx/libc++.dylib   -Wl,-rpath,/opt/local/libexec/llvm-16/lib   -Wl,-rpath,/opt/local/lib/libfmt11   test20.cpp -o test20

(Assuming: libfmt11 , libcxx , legacy-support , clang-16 , llvm-16 are installed as well as Xcode / developer tools)

or

clang++-mp-NN -std=c++20 -D_LIBCPP_DISABLE_AVAILABILITY -nostdinc++   -isysroot "$(xcrun --show-sdk-path 2>/dev/null)"   -I/opt/local/libexec/llvm-NN/include/c++/v1   -I/opt/local/include/libfmt11   -L/opt/local/lib/libfmt11   -lfmt   /opt/local/lib/libcxx/libc++.dylib   -Wl,-rpath,/opt/local/libexec/llvm-NN/lib   -Wl,-rpath,/opt/local/lib/libfmt11   test20.cpp -o test20

and replace the three NNs with the version of clang you have installed.

test20.cpp contains c++17 and c++20 code - I can attach it if requested.

[JohnFHall (John Hall)]

Replying to JULWAL1:

This worked for me on macOS Sierra:

sudo port upgrade libheif configure.compiler=macports-gcc-15 configure.cxx_stdlib=libstdc++ configure.cxxflags="-std=c++20" configure.cppflags=""

Thank you so much. I finally worked up the courage to try your solution, and it worked for me too. I now have a workaable macports. Well done.

[kencu (Ken)]

Replying to JohnFHall:

Thank you so much. I finally worked up the courage to try your solution, and it worked for me too. I now have a workaable macports. Well done.

Actually, you don't. Macports cannot work reliably with some software linked agains libstdc++ and some linked against libc++. It may build and link, but you cannot hope for it to function in a reliable fashion.

Enter this into ChatGPT for more detail "what happens if I try to use macports with some software linked agains libstdc++ and some linked against libc++?"

Such things can work in very selected situations, where there are no other libraries to interact with.

Your practical options?

1. hold back software as required (tedious but easy)
2. build everything on MacPorts against libstdc++ (probably a lot of work)
3. upgrade macports-libcxx to a newer version, and do a lot of testing to see if anything breaks (easiest, risky unless you do the testing, some things are likely to break in an occult fashion).
4. bootstrap some new version of libc++ using some bootstrap setup, and then build everything in macports against that new libc++ (purest and probably best, some work involved, some things that build with XCode etc will be hard to arm-wrestle to use the new libc++).

[JohnFHall (John Hall)]

Replying to kencu:

Replying to JohnFHall:

Thank you so much. I finally worked up the courage to try your solution, and it worked for me too. I now have a workaable macports. Well done.

Actually, you don't. Macports cannot work reliably with some software linked agains libstdc++ and some linked against libc++. It may build and link, but you cannot hope for it to function in a reliable fashion.

Well, fuck me, as us Aussies say. I now officially give the fuck up.

[reneeotten (Renee Otten)]

In 5d9fb1fd934a73aace867af9fada007c8dbef89f/macports-ports (master):

libheif: also pin older version on 10.13 and 10.14

• still fails on the buildbot after 2eb0457d84fa3ee3a42f69926a9a95ef8bbc9f1c

Closes: #74078

[ryandesign (Ryan Carsten Schmidt)]

Replying to reneeotten:

In 5d9fb1fd934a73aace867af9fada007c8dbef89f/macports-ports (master):

libheif: also pin older version on 10.13 and 10.14

• still fails on the buildbot after 2eb0457d84fa3ee3a42f69926a9a95ef8bbc9f1c

Closes: #74078

This cannot work; this needs to be undone.

Users of macOS 10.7 thru 10.14 previously had version 1.21.2.

You've now changed the port to offer those users 1.18.2.

You haven't increased the epoch, so users who already have 1.21.2 won't know about the available downgrade.

If they were to downgrade, their existing software built against libheif 1.21.2 would probably not work.

If new users install libheif on these older systems, they'll get 1.18.2, and binaries we have that were built with 1.21.2 will probably not work.

As I suggested in comment:45, we should instead extend the libheif port to reintroduce version 1.21.2 for 10.7 thru 10.14.

[reneeotten (Renee Otten)]

Fine with me....

I've tried to keep up with the complaints about this, go through the PR queue and try to merge things in a reasonable time-frame. I personally don't care about older OSes and have no way to test them, we cannot keep holding updates back just for the sake of keeping ports working on old OS versions. Maintainers of ports do not respond, and there seems nobody around who actually wants to do the work on keeping old OSes functional or is willing to help out others who do spend time on this (e.g., ​PR 31641); in the meantime Trac is flooded with complaints about "us" breaking things on older OSes for this port and others...

Feel free to revert whatever you want and/or come up with a solution where modern OSes can be updated to follow upstream releases and at the same time keep old OS versions functional.

I will keep merging PRs that pass on the latest three OSes (i.e., all CI runs); if that policy has changed, please let me know and will just stop working on that as well.

[ryandesign (Ryan Carsten Schmidt)]

Replying to ryandesign:

This cannot work; this needs to be undone.

OK, it's not quite as bad as that, and might not need to be reverted. While the "current version" of libheif.1.dylib is different between 1.18.2 and 1.21.2, the "compatibility version" is the same.

However, it does still need to be corrected (not necessarily by you). We do want to be consistent. Either want all users of old systems to have 1.18.2 or we want them to have 1.21.2, and what has been committed so far doesn't accomplish that.

I understand your frustration. I don't want to suggest you should stop working on things. I am not working on these things right now. It's just that this type of change is not correct. This is the type of change that Josh points to as evidence for why we should not have different versions of ports for different systems, because updates and changes to the ports are not handled correctly. I would like to avoid having Josh issue a mandate that we stop doing this, therefore I would like for all updates and changes to such ports to be done correctly. If you don't want to work on that right now, I totally understand. However, to your point of not having access to older systems, that's not required to ensure that ports aren't unintentionally downgraded for some users.

[reneeotten (Renee Otten)]

Replying to ryandesign:

However, it does still need to be corrected (not necessarily by you). We do want to be consistent. Either want all users of old systems to have 1.18.2 or we want them to have 1.21.2, and what has been committed so far doesn't accomplish that.

I understand your frustration. I don't want to suggest you should stop working on things. I am not working on these things right now. It's just that this type of change is not correct. This is the type of change that Josh points to as evidence for why we should not have different versions of ports for different systems, because updates and changes to the ports are not handled correctly. I would like to avoid having Josh issue a mandate that we stop doing this, therefore I would like for all updates and changes to such ports to be done correctly. If you don't want to work on that right now, I totally understand. However, to your point of not having access to older systems, that's not required to ensure that ports aren't unintentionally downgraded for some users.

Ryan: I agree with all of that. Having different versions of a port depending on the OS versions is indeed very brittle but right now that's the only way to keep on supporting older OSes (not saying we should do so, but that's my personal opinion).

You are right that I could have checked to make sure that we'd handle a "downgrade" correctly. But as I said, I am not interested in older OSes and have to assume at some point that users of older OSes who are submitting PRs and/or commenting in tickets do their homework and make sure things are handled correctly. I just "extended" the change in the original PR to include 10.13 and 10.14 where the newer version still failed.

[jmroot (Joshua Root)]

Replying to reneeotten:

Having different versions of a port depending on the OS versions is indeed very brittle but right now that's the only way to keep on supporting older OSes (not saying we should do so, but that's my personal opinion).

I don't want to start a debate again, but just to be clear, my preferred solution is to have separate ports (or subports) providing the different versions of the software, with a stub port that depends on the correct versioned port according to the OS version.

[kencu (Ken)]

There is one lucky break in this story.

Apple doesn't tend to use C++ ABIs for system frameworks. So you are largely immune from the potential problem of having ABI issues when calling such frameworks.

" It is very unusual to encounter a system framework whose public API requires that your application use the same C++ ABI as Apple used internally. Apple has deliberately avoided that dependency for decades. This is one reason you can successfully build applications with GCC, Clang, libc++, libstdc++, or even non-Apple toolchains and still call most macOS framework APIs without C++ ABI compatibility concerns. "

[JULWAL1 (Jules Warm)]

Interesting.

I have been experimenting again and created a local MacPorts repository so that I can test the latest versions of certain ports after running:

port -v livecheck <portname>

and decided to attempt rebuilding libheif @1.23.0 using MacPorts Clang-16 (or above).

I noticed that by editing the previous Portfile (prior to yesterday) for libheif @1.23.0 and adding:

configure.cxxflags-append \
-D_LIBCPP_DISABLE_AVAILABILITY

and changing:

legacysupport.use_mp_libcxx yes

to:

legacysupport.use_mp_libcxx no

I then ran: sudo port selfupdate and the following commands relating to my local MacPorts repo:

sudo portindex -d -x ~/macports-ports

sudo port clean --all libheif

sudo port fetch libheif

sudo port extract libheif

sudo port -d build libheif

It managed to compile up to 79% and then failed at the linker stage - exactly like the earlier contributor's experience to this conversation from the start. The main.log file showed:

:info:build cd /opt/local/var/macports/build/libheif-a1fad494/work/build/libheif && /opt/local/bin/clang++-mp-16 -DENABLE_MULTITHREADING_SUPPORT=1 -DENABLE_PARALLEL_TILE_DECODING=1 -DHAVE_AOM_DECODER=1 -DHAVE_AOM_ENCODER=1 -DHAVE_BIT -DHAVE_BROTLI=1 -DHAVE_DAV1D=1 -DHAVE_JPEG_DECODER=1 -DHAVE_JPEG_ENCODER=1 -DHAVE_KVAZAAR=1 -DHAVE_KVAZAAR_ENABLE_LOGGING=1 -DHAVE_KVAZAAR_VERSION_STRING=0 -DHAVE_LIBDE265=1 -DHAVE_LIBSHARPYUV=1 -DHAVE_OPENJPEG_DECODER=1 -DHAVE_OPENJPEG_ENCODER=1 -DHAVE_OpenH264_DECODER=1 -DHAVE_SvtEnc=1 -DHAVE_UNISTD_H -DHAVE_VISIBILITY -DHAVE_X264=1 -DHAVE_X265=1 -DHAVE_ZLIB=1 -DIS_BIG_ENDIAN=0 -DLIBHEIF_EXPORTS -DWITH_UNCOMPRESSED_CODEC=1 -Dheif_EXPORTS -I/opt/local/var/macports/build/libheif-a1fad494/work/build -I/opt/local/var/macports/build/libheif-a1fad494/work/libheif-1.23.0/libheif -I/opt/local/var/macports/build/libheif-a1fad494/work/libheif-1.23.0/libheif/api -I/opt/local/var/macports/build/libheif-a1fad494/work/libheif-1.23.0/include/libheif -I/opt/local/var/macports/build/libheif-a1fad494/work/libheif-1.23.0/include -I/opt/local/include/webp -isystem /opt/local/include -isystem /opt/local/include/openjpeg-2.5 -pipe -Os -Wno-nonportable-include-path -Wno-error=nonportable-include-path -Wno-unknown-warning-option -Wno-error=unknown-warning-option -D_LIBCPP_DISABLE_AVAILABILITY -DNDEBUG -isystem/opt/local/include/LegacySupport -I/opt/local/include -stdlib=libc++ -std=c++20 -arch x86_64 -mmacosx-version-min=10.12 -fPIC -fvisibility=hidden -fvisibility-inlines-hidden -Wall -Wsign-compare -Wconversion -Wno-sign-conversion -Wno-error=conversion -Wno-error=unused-parameter -Wno-error=deprecated-declarations -Wno-error=tautological-compare -Wno-error=tautological-constant-out-of-range-compare -Wno-error=potentially-evaluated-expression -MD -MT libheif/CMakeFiles/heif.dir/omaf_boxes.cc.o -MF CMakeFiles/heif.dir/omaf_boxes.cc.o.d -o CMakeFiles/heif.dir/omaf_boxes.cc.o -c /opt/local/var/macports/build/libheif-a1fad494/work/libheif-1.23.0/libheif/omaf_boxes.cc
:info:build [ 79%] Linking CXX shared library libheif.dylib
:info:build cd /opt/local/var/macports/build/libheif-a1fad494/work/build/libheif && /opt/local/bin/cmake -E cmake_link_script CMakeFiles/heif.dir/link.txt --verbose=ON
:info:build Undefined symbols for architecture x86_64:
:info:build   "typeinfo for std::bad_variant_access", referenced from:
:info:build       __ZNSt3__126__throw_bad_variant_accessB7v160006Ev in context.cc.o
:info:build       __ZNSt3__126__throw_bad_variant_accessB7v160006Ev in file.cc.o
:info:build       __ZNSt3__126__throw_bad_variant_accessB7v160006Ev in pixelimage.cc.o
:info:build       __ZNSt3__126__throw_bad_variant_accessB7v160006Ev in brands.cc.o
:info:build       __ZNSt3__126__throw_bad_variant_accessB7v160006Ev in heif_image.cc.o
:info:build       __ZNSt3__126__throw_bad_variant_accessB7v160006Ev in heif_regions.cc.o
:info:build       __ZNSt3__126__throw_bad_variant_accessB7v160006Ev in heif_properties.cc.o
:info:build       ...
:info:build   "vtable for std::bad_variant_access", referenced from:
:info:build       __ZNSt3__126__throw_bad_variant_accessB7v160006Ev in context.cc.o
:info:build       __ZNSt3__126__throw_bad_variant_accessB7v160006Ev in file.cc.o
:info:build       __ZNSt3__126__throw_bad_variant_accessB7v160006Ev in pixelimage.cc.o
:info:build       __ZNSt3__126__throw_bad_variant_accessB7v160006Ev in brands.cc.o
:info:build       __ZNSt3__126__throw_bad_variant_accessB7v160006Ev in heif_image.cc.o
:info:build       __ZNSt3__126__throw_bad_variant_accessB7v160006Ev in heif_regions.cc.o
:info:build       __ZNSt3__126__throw_bad_variant_accessB7v160006Ev in heif_properties.cc.o
:info:build       ...
:info:build   NOTE: a missing vtable usually means the first non-inline virtual member function has no definition.
:info:build ld: symbol(s) not found for architecture x86_64
:info:build clang: error: linker command failed with exit code 1 (use -v to see invocation)
:info:build /opt/local/bin/clang++-mp-16 -pipe -Os -Wno-nonportable-include-path -Wno-error=nonportable-include-path -Wno-unknown-warning-option -Wno-error=unknown-warning-option -D_LIBCPP_DISABLE_AVAILABILITY -DNDEBUG -isystem/opt/local/include/LegacySupport -I/opt/local/include -stdlib=libc++ -arch x86_64 -mmacosx-version-min=10.12 -dynamiclib -Wl,-headerpad_max_install_names -Wl,-compatibility_version,17.0.0 -Wl,-headerpad_max_install_names -L/opt/local/lib -lMacportsLegacySupport -compatibility_version 1.0.0 -current_version 1.23.0 -o libheif.1.23.0.dylib -install_name @rpath/libheif.1.dylib CMakeFiles/heif.dir/bitstream.cc.o CMakeFiles/heif.dir/box.cc.o CMakeFiles/heif.dir/error.cc.o CMakeFiles/heif.dir/context.cc.o CMakeFiles/heif.dir/file.cc.o CMakeFiles/heif.dir/file_layout.cc.o CMakeFiles/heif.dir/image/pixelimage.cc.o CMakeFiles/heif.dir/image/image_description.cc.o CMakeFiles/heif.dir/plugin_registry.cc.o CMakeFiles/heif.dir/nclx.cc.o CMakeFiles/heif.dir/security_limits.cc.o CMakeFiles/heif.dir/init.cc.o CMakeFiles/heif.dir/logging.cc.o CMakeFiles/heif.dir/compression.cc.o CMakeFiles/heif.dir/compression_brotli.cc.o CMakeFiles/heif.dir/compression_zlib.cc.o CMakeFiles/heif.dir/common_utils.cc.o CMakeFiles/heif.dir/region.cc.o CMakeFiles/heif.dir/brands.cc.o CMakeFiles/heif.dir/id_creator.cc.o CMakeFiles/heif.dir/text.cc.o CMakeFiles/heif.dir/api/libheif/heif.cc.o CMakeFiles/heif.dir/api/libheif/heif_library.cc.o CMakeFiles/heif.dir/api/libheif/heif_image.cc.o CMakeFiles/heif.dir/api/libheif/heif_color.cc.o CMakeFiles/heif.dir/api/libheif/heif_regions.cc.o CMakeFiles/heif.dir/api/libheif/heif_plugin.cc.o CMakeFiles/heif.dir/api/libheif/heif_properties.cc.o CMakeFiles/heif.dir/api/libheif/heif_items.cc.o CMakeFiles/heif.dir/api/libheif/heif_sequences.cc.o CMakeFiles/heif.dir/api/libheif/heif_tai_timestamps.cc.o CMakeFiles/heif.dir/api/libheif/heif_brands.cc.o CMakeFiles/heif.dir/api/libheif/heif_metadata.cc.o CMakeFiles/heif.dir/api/libheif/heif_aux_images.cc.o CMakeFiles/heif.dir/api/libheif/heif_entity_groups.cc.o CMakeFiles/heif.dir/api/libheif/heif_security.cc.o CMakeFiles/heif.dir/api/libheif/heif_encoding.cc.o CMakeFiles/heif.dir/api/libheif/heif_decoding.cc.o CMakeFiles/heif.dir/api/libheif/heif_image_handle.cc.o CMakeFiles/heif.dir/api/libheif/heif_context.cc.o CMakeFiles/heif.dir/api/libheif/heif_tiling.cc.o CMakeFiles/heif.dir/api/libheif/heif_components.cc.o CMakeFiles/heif.dir/api/libheif/heif_uncompressed.cc.o CMakeFiles/heif.dir/api/libheif/heif_text.cc.o CMakeFiles/heif.dir/api/libheif/heif_omaf.cc.o CMakeFiles/heif.dir/codecs/decoder.cc.o CMakeFiles/heif.dir/codecs/encoder.cc.o "CMakeFiles/heif.dir/image-items/hevc.cc.o" CMakeFiles/heif.dir/codecs/hevc_boxes.cc.o CMakeFiles/heif.dir/codecs/hevc_dec.cc.o CMakeFiles/heif.dir/codecs/hevc_enc.cc.o "CMakeFiles/heif.dir/image-items/avif.cc.o" CMakeFiles/heif.dir/codecs/avif_enc.cc.o CMakeFiles/heif.dir/codecs/avif_dec.cc.o CMakeFiles/heif.dir/codecs/avif_boxes.cc.o "CMakeFiles/heif.dir/image-items/jpeg.cc.o" CMakeFiles/heif.dir/codecs/jpeg_boxes.cc.o CMakeFiles/heif.dir/codecs/jpeg_dec.cc.o CMakeFiles/heif.dir/codecs/jpeg_enc.cc.o "CMakeFiles/heif.dir/image-items/jpeg2000.cc.o" CMakeFiles/heif.dir/codecs/jpeg2000_dec.cc.o CMakeFiles/heif.dir/codecs/jpeg2000_enc.cc.o CMakeFiles/heif.dir/codecs/jpeg2000_boxes.cc.o "CMakeFiles/heif.dir/image-items/vvc.cc.o" CMakeFiles/heif.dir/codecs/vvc_dec.cc.o CMakeFiles/heif.dir/codecs/vvc_enc.cc.o CMakeFiles/heif.dir/codecs/vvc_boxes.cc.o "CMakeFiles/heif.dir/image-items/avc.cc.o" CMakeFiles/heif.dir/codecs/avc_boxes.cc.o CMakeFiles/heif.dir/codecs/avc_dec.cc.o CMakeFiles/heif.dir/codecs/avc_enc.cc.o "CMakeFiles/heif.dir/image-items/mask_image.cc.o" "CMakeFiles/heif.dir/image-items/image_item.cc.o" "CMakeFiles/heif.dir/image-items/grid.cc.o" "CMakeFiles/heif.dir/image-items/overlay.cc.o" "CMakeFiles/heif.dir/image-items/iden.cc.o" "CMakeFiles/heif.dir/image-items/tiled.cc.o" "CMakeFiles/heif.dir/color-conversion/colorconversion.cc.o" "CMakeFiles/heif.dir/color-conversion/rgb2yuv.cc.o" "CMakeFiles/heif.dir/color-conversion/rgb2yuv_sharp.cc.o" "CMakeFiles/heif.dir/color-conversion/yuv2rgb.cc.o" "CMakeFiles/heif.dir/color-conversion/rgb2rgb.cc.o" "CMakeFiles/heif.dir/color-conversion/monochrome.cc.o" "CMakeFiles/heif.dir/color-conversion/hdr_sdr.cc.o" "CMakeFiles/heif.dir/color-conversion/alpha.cc.o" "CMakeFiles/heif.dir/color-conversion/chroma_sampling.cc.o" "CMakeFiles/heif.dir/color-conversion/bayer_bilinear.cc.o" CMakeFiles/heif.dir/sequences/seq_boxes.cc.o CMakeFiles/heif.dir/sequences/chunk.cc.o CMakeFiles/heif.dir/sequences/track.cc.o CMakeFiles/heif.dir/sequences/track_visual.cc.o CMakeFiles/heif.dir/sequences/track_metadata.cc.o CMakeFiles/heif.dir/plugins/encoder_x265.cc.o CMakeFiles/heif.dir/plugins/decoder_libde265.cc.o CMakeFiles/heif.dir/plugins/decoder_dav1d.cc.o CMakeFiles/heif.dir/plugins/decoder_aom.cc.o CMakeFiles/heif.dir/plugins/encoder_aom.cc.o CMakeFiles/heif.dir/plugins/encoder_svt.cc.o CMakeFiles/heif.dir/plugins/decoder_jpeg.cc.o CMakeFiles/heif.dir/plugins/encoder_jpeg.cc.o CMakeFiles/heif.dir/plugins/decoder_openjpeg.cc.o CMakeFiles/heif.dir/plugins/encoder_openjpeg.cc.o CMakeFiles/heif.dir/plugins/encoder_kvazaar.cc.o CMakeFiles/heif.dir/plugins/encoder_x264.cc.o CMakeFiles/heif.dir/plugins/decoder_openh264.cc.o CMakeFiles/heif.dir/plugins/encoder_mask.cc.o CMakeFiles/heif.dir/plugins/nalu_utils.cc.o CMakeFiles/heif.dir/plugins/encoder_uncompressed.cc.o CMakeFiles/heif.dir/plugins/decoder_uncompressed.cc.o CMakeFiles/heif.dir/codecs/uncompressed/unc_boxes.cc.o "CMakeFiles/heif.dir/image-items/unc_image.cc.o" CMakeFiles/heif.dir/codecs/uncompressed/unc_codec.cc.o CMakeFiles/heif.dir/codecs/uncompressed/unc_dec.cc.o CMakeFiles/heif.dir/codecs/uncompressed/unc_enc.cc.o CMakeFiles/heif.dir/codecs/uncompressed/unc_decoder.cc.o CMakeFiles/heif.dir/codecs/uncompressed/unc_decoder_legacybase.cc.o CMakeFiles/heif.dir/codecs/uncompressed/unc_decoder_component_interleave.cc.o CMakeFiles/heif.dir/codecs/uncompressed/unc_decoder_pixel_interleave.cc.o CMakeFiles/heif.dir/codecs/uncompressed/unc_decoder_block_pixel_interleave.cc.o CMakeFiles/heif.dir/codecs/uncompressed/unc_decoder_bytealign_component_interleave.cc.o CMakeFiles/heif.dir/codecs/uncompressed/unc_decoder_block_component_interleave.cc.o CMakeFiles/heif.dir/codecs/uncompressed/unc_decoder_mixed_interleave.cc.o CMakeFiles/heif.dir/codecs/uncompressed/unc_decoder_row_interleave.cc.o CMakeFiles/heif.dir/codecs/uncompressed/unc_encoder.cc.o CMakeFiles/heif.dir/codecs/uncompressed/unc_encoder_rgb_pixel_interleave.cc.o CMakeFiles/heif.dir/codecs/uncompressed/unc_encoder_rgb_bytealign_pixel_interleave.cc.o CMakeFiles/heif.dir/codecs/uncompressed/unc_encoder_component_interleave.cc.o CMakeFiles/heif.dir/codecs/uncompressed/unc_encoder_rgb_block_pixel_interleave.cc.o CMakeFiles/heif.dir/mini.cc.o CMakeFiles/heif.dir/omaf_boxes.cc.o  /opt/local/lib/libx265.dylib /opt/local/lib/libde265.dylib /opt/local/lib/libdav1d.dylib /opt/local/lib/libaom.3.13.1.dylib /opt/local/lib/libSvtAv1Enc.dylib /opt/local/lib/libjpeg.dylib /opt/local/lib/libjpeg.dylib /opt/local/lib/libopenjp2.2.5.4.dylib /opt/local/lib/libkvazaar.dylib /opt/local/lib/libx264.dylib /opt/local/lib/libopenh264.dylib /opt/local/lib/libsharpyuv.dylib /opt/local/lib/libz.dylib /opt/local/lib/libbrotlidec.dylib /opt/local/lib/libbrotlienc.dylib -lm
:info:build make[2]: *** [libheif/libheif.1.23.0.dylib] Error 1
:info:build make[2]: Leaving directory `/opt/local/var/macports/build/libheif-a1fad494/work/build'
:info:build make[1]: *** [libheif/CMakeFiles/heif.dir/all] Error 2
:info:build make[1]: Leaving directory `/opt/local/var/macports/build/libheif-a1fad494/work/build'
:info:build make: *** [all] Error 2
:info:build make: Leaving directory `/opt/local/var/macports/build/libheif-a1fad494/work/build'
:info:build Command failed:  cd "/opt/local/var/macports/build/libheif-a1fad494/work/build" && /usr/bin/make -w all VERBOSE=ON 
:info:build Exit code: 2
:error:build Failed to build libheif: command execution failed

Dead-end or are there options for resolving it using clang-16 or above (instead of gcc-15)?

Update:

I added to the bottom of the Portfile in question (as well as the previous two edits above):

platform darwin {
    if {${os.major} < 17} {
        configure.ldflags-append -L${prefix}/lib/libcxx -Wl,-rpath,${prefix}/lib/libcxx
    }
}

and then ran the following commands:

$ sudo port uninstall libheif @1.23.0_0+examples+kvazaar
Note: It is not recommended to uninstall/deactivate a port that has dependents as it breaks the dependents.
The following ports will break:
 gd2 @2.3.3_7
 ImageMagick @6.9.13-46_0
Uninstall libheif anyway? [y/N]: y
Warning: Uninstall forced.  Proceeding despite dependencies.
--->  Deactivating libheif @1.23.0_0+examples+kvazaar
--->  Cleaning libheif
--->  Uninstalling libheif @1.23.0_0+examples+kvazaar
--->  Cleaning libheif

$ sudo portindex -d -x ~/macports-ports

$ sudo port install libheif
--->  Computing dependencies for libheif
--->  Activating libheif @1.23.0_0+examples+kvazaar
--->  Cleaning libheif                                   
--->  Scanning binaries for linking errors
--->  No broken files found.                             
--->  No broken ports found.
--->  Some of the ports you installed have notes:
  libheif has the following notes:
    Support for rav1e now disabled by default; enable via +rav1e

$ port installed libheif
The following ports are currently installed:
  libheif @1.21.2_3+examples+kvazaar
  libheif @1.23.0_0+examples+kvazaar (active)

$ port -v installed libheif
The following ports are currently installed:
  libheif @1.21.2_3+examples+kvazaar requested_variants='' platform='darwin 16' archs='x86_64' date='2026-05-26T12:00:34+0100'
  libheif @1.23.0_0+examples+kvazaar (active) requested_variants='' platform='darwin 16' archs='x86_64' date='2026-06-23T18:45:07+0100'

$ heif-info --version
1.23.0
libheif: 1.23.0
plugin path: plugins are disabled

$ otool -L /opt/local/lib/libheif.1.23.0.dylib 
/opt/local/lib/libheif.1.23.0.dylib:
	/opt/local/lib/libheif.1.dylib (compatibility version 17.0.0, current version 1.23.0)
	/opt/local/lib/libMacportsLegacySupport.dylib (compatibility version 1.0.0, current version 1.5.2)
	/opt/local/lib/libx265.216.dylib (compatibility version 216.0.0, current version 216.0.0)
	/opt/local/lib/libde265.0.dylib (compatibility version 0.0.0, current version 0.1.12)
	/opt/local/lib/libdav1d.7.dylib (compatibility version 7.0.0, current version 7.0.0)
	/opt/local/lib/libaom.3.dylib (compatibility version 3.0.0, current version 3.13.1)
	/opt/local/lib/libSvtAv1Enc.4.dylib (compatibility version 4.0.0, current version 4.1.0)
	/opt/local/lib/libjpeg.8.dylib (compatibility version 8.0.0, current version 8.3.2)
	/opt/local/lib/libopenjp2.7.dylib (compatibility version 7.0.0, current version 2.5.4)
	/opt/local/lib/libkvazaar.7.dylib (compatibility version 13.0.0, current version 13.0.0)
	/opt/local/lib/libx264.165.dylib (compatibility version 0.0.0, current version 0.0.0)
	/opt/local/lib/libopenh264.7.dylib (compatibility version 7.0.0, current version 7.0.0)
	/opt/local/lib/libsharpyuv.0.dylib (compatibility version 2.0.0, current version 2.2.0)
	/opt/local/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.3.2)
	/opt/local/lib/libbrotlidec.1.dylib (compatibility version 1.0.0, current version 1.2.0)
	/opt/local/lib/libbrotlienc.1.dylib (compatibility version 1.0.0, current version 1.2.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1238.60.2)
	/opt/local/lib/libcxx/libc++.1.0.dylib (compatibility version 1.0.0, current version 1.0.0)

It moved past the 79% previous linker error and got to 100% and then installed with no issues.

[ryandesign (Ryan Carsten Schmidt)]

Replying to reneeotten:

Ryan: I agree with all of that. Having different versions of a port depending on the OS versions is indeed very brittle but right now that's the only way to keep on supporting older OSes (not saying we should do so, but that's my personal opinion).

I agree using an older version for older systems is acceptable, perhaps even only temporarily, but it doesn't have to be brittle; it just has to be done correctly. It, or any other change, needs to be reviewed before a PR is merged.

You are right that I could have checked to make sure that we'd handle a "downgrade" correctly. But as I said, I am not interested in older OSes and have to assume at some point that users of older OSes who are submitting PRs and/or commenting in tickets do their homework and make sure things are handled correctly. I just "extended" the change in the original PR to include 10.13 and 10.14 where the newer version still failed.

My apologies; my complaint was intended for the author of that original PR; I didn't realize, when I saw your commit, that you had not made the original change.

Replying to JULWAL1:

configure.cxxflags-append \
-D_LIBCPP_DISABLE_AVAILABILITY

platform darwin {
    if {${os.major} < 17} {
        configure.ldflags-append -L${prefix}/lib/libcxx -Wl,-rpath,${prefix}/lib/libcxx
    }
}

Interesting. I'm not familiar with those things so I'm not comfortable committing that change, but others can investigate and do so. For now, I'll commit an update to 1.22.2 for 10.7–10.14, which I've verified builds on OS X 10.7.

[ryandesign (Ryan Carsten Schmidt)]

In 9f4bc82efde3b884bd816ff001032d3cd1ca8403/macports-ports (master):

libheif: Update to 1.22.2 (macOS 10.7 thru 10.14)

Closes: #74078
See: ​https://github.com/macports/macports-ports/pull/33032
See: ​https://github.com/macports/macports-ports/pull/33100

[scrutinizer11]

So what's the current situation? In Mojave, the update still fails on me. I wouldn't have cared much about HEIF had it not been an ffmpeg's dependency, so I can't run over it with the "-p" option to blur this failure just to get ffmpeg. As a result, it won't update my copy of yt-dlp.

[Dave-Allured (Dave Allured)]

So what's the current situation? In Mojave, the update still fails on me.

Libheif was fixed by Ryan's update of June 23 (above). Thanks Ryan for taking care of that. The buildbots now report good builds for all OS 10.6 through Tahoe 26: ​https://ports.macports.org/port/libheif

Here is the specific build log for Mojave 10.14: ​https://build.macports.org/builders/ports-10.14_x86_64-builder/builds/263288

So libheif should be working for you now. If not, try uninstalling and reinstalling port libheif. If it still fails and you don't immediately find the problem by comparing your build log with the working one, then please post your build log here, and I will take a look.

I also created libheif-devel to update to the latest version 1.23.1. You could try uninstalling libheif and install libheif-devel. This is speculative, I do not understand where your current build problem is coming from.

​https://ports.macports.org/port/libheif-devel

[scrutinizer11]

It tumbles down halfway when I'm running port -q outdated preceded or not by port sync.

[reneeotten (Renee Otten)]

as Dave said: add the complete main.log

[scrutinizer11]

I can't attach it.

[scrutinizer11]

Ok, I've finally figured that out. Here's a WeTransfer link to download the log. It expires in 3 days.

main.log: ​https://we.tl/t-vJRXkdJCXP4h09ZV

[Dave-Allured (Dave Allured)]

Sorry, that hits some of my security flags.

• Obfuscated link
• Link target HTML contains script
• Target HTML scripts contains obfuscation
• Service agreement challenge

Put log file inside compressed tar or zip file. Then upload using "Attachments/Attach another file" button at top of this page. If still too large, upload in two or more parts. Try a different browser.

[scrutinizer11]

main.log 12.06-12.07

[Dave-Allured (Dave Allured)]

main.log, got it. Thanks. I need to check your Portfile version. Please show:

ls -l /opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs/ports/multimedia/libheif/Portfile

[scrutinizer11]

-rw-r--r--  1 macports  wheel  6615 Jun  4 15:52 /opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs/ports/multimedia/libheif/Portfile

[Dave-Allured (Dave Allured)]

Okay, there is the problem. You have an outdated version of the libheif Portfile, before the fix for "ranges" was added. It looks like your port sync command did not capture the most recent updates, and I can not explain why. You can see the different Portfile versions in the "history" view on github:

​https://github.com/macports/macports-ports/blob/master/multimedia/libheif/Portfile

I suggest retry port sync or port selfupdate. Then look at the /opt/local/ Portfile that you showed above, to ensure that it was correctly updated. Then port upgrade libheif. There are also manual methods, if port sync does not properly update that Portfile.

Alternatively, you could wait a few days for the new libheif version 1.23.1 that I pushed today:

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

[scrutinizer11]

Thanks for your assistance. I used these commands to kick things off and updated all the necessary binaries. I'm buffled why port sync failed. It shouldn't have. Before the issue surfaced, I had relied on my shell script to auto update ports and the MacPort base. I double-checked that the relevant command in my script was instructed to execute with the superuser privileges. Now, I ran the copy in Terminal and it worked. Go figure.