[BUG] fasttech Symbol not found 2.67

[big610]

Read the FAQ first

• I have checked the FAQ but the issue is not covered

Description

fastech Symbol not found 2.67

dyld: Symbol not found: _VTRegisterSupplementalVideoDecoderIfAvailable
Referenced from:fastfetch-macos-amd64/fastfetch (which was built for Mac OS X 15.0)
Expected in: /System/Library/Frameworks/VideoToolbox.framework/Versions/A/VideoToolbox
zsh: abort

flashtech 2.67 works perfect like all previous versions 2.66 & below

OS: Mac OS X Catalina 10.15.8 (19H2036) x86_64

Version used

2.67

Bug prevalence

Always

Regression

No

Installation

GitHub Releases

Package manager

fastfetch-macos-amd64

Screenshots

No response

Configuration

System information

dyld: Symbol not found: _VTRegisterSupplementalVideoDecoderIfAvailable

Features built-in

Referenced from:fastfetch-macos-amd64/fastfetch (which was built for Mac OS X 15.0)

[aldahiiir]

I don't have a Catalina machine to reproduce this, but I downloaded and inspected the macOS binary from Arch Linux.

Could you confirm that this is the exact artifact you used?

fastfetch-macos-amd64.tar.gz

This is how I inspected it without running it:

curl -LO https://github.com/fastfetch-cli/fastfetch/releases/download/2.67.0/fastfetch-macos-amd64.tar.gz
tar -xzf fastfetch-macos-amd64.tar.gz

file fastfetch-macos-amd64/usr/bin/fastfetch

go tool nm fastfetch-macos-amd64/usr/bin/fastfetch \
  | rg 'VTRegisterSupplemental|VTIsHardwareDecodeSupported'

The relevant output is:

U _VTIsHardwareDecodeSupported
U _VTRegisterSupplementalVideoDecoderIfAvailable

The U means that these functions are not implemented inside Fastfetch. The executable expects macOS's VideoToolbox framework to provide them.

_VTRegisterSupplementalVideoDecoderIfAvailable was introduced in Fastfetch by 111c1bab, behind a macOS 11 availability check in codec_apple.c.

However, the error suggests that dyld is treating this symbol as a required import. Since Catalina's VideoToolbox doesn't provide it, dyld aborts while loading the executable, before the __builtin_available(macOS 11.0, *) check can run.

I also checked the official 2.66 binary, and it doesn't reference this symbol. That seems to explain why 2.66 starts on the same system while 2.67 doesn't.

A few possible fixes that come to mind:

• Build with a lower macOS deployment target so the newer API is weak-linked.
• Explicitly mark the function as a weak import and check that it exists before calling it.
• Resolve it dynamically with dlsym so dyld doesn't require the symbol at startup.

[CarterLi]

Fixed in 51a4f34