Skip to content

[FIX]: Fix libpng ARM source inclusion for non-Darwin AArch64 CMake builds - #2302

Open
x15sr71 wants to merge 1 commit into
CCExtractor:masterfrom
x15sr71:fix/linux-aarch64-libpng-neon-link
Open

[FIX]: Fix libpng ARM source inclusion for non-Darwin AArch64 CMake builds#2302
x15sr71 wants to merge 1 commit into
CCExtractor:masterfrom
x15sr71:fix/linux-aarch64-libpng-neon-link

Conversation

@x15sr71

@x15sr71 x15sr71 commented Aug 2, 2026

Copy link
Copy Markdown
Contributor

In raising this pull request, I confirm the following (please check boxes):

Reason for this PR:

  • This PR adds new functionality.
  • This PR fixes a bug that I have personally experienced or that a real user has reported and for which a sample exists.
  • This PR is porting code from C to Rust.

Sanity check:

  • I have read and understood the contributors guide.
  • I have checked that another pull request for this purpose does not exist.
  • If the PR adds new functionality, I've added it to the changelog. If it's just a bug fix, I have NOT added it to the changelog.
  • I am NOT adding new C code unless it's to fix an existing, reproducible bug.

Repro instructions:

  • Reproduced the failure while building CCExtractor with CMake on Linux AArch64 (Ubuntu 24.04, GCC 13.3, CMake 3.28) using the pre-fix CMakeLists.txt.

Issue

Building CCExtractor from source with CMake on Linux AArch64 (Ubuntu 24.04, GCC 13.3, CMake 3.28) fails at link time:

/usr/bin/ld: pngrtran.c: undefined reference to `png_do_expand_palette_rgba8_neon'
/usr/bin/ld: pngrtran.c: undefined reference to `png_do_expand_palette_rgb8_neon'
/usr/bin/ld: pngrtran.c: undefined reference to `png_riffle_palette_neon'
/usr/bin/ld: pngrutil.c: undefined reference to `png_init_filter_functions_neon'
collect2: error: ld returned 1 exit status

The identical commit builds cleanly on Apple Silicon macOS.

Root Cause

Bundled libpng (thirdparty/libpng/pngpriv.h) auto-enables ARM NEON code paths (PNG_ARM_NEON_OPT=2) whenever the compiler defines __ARM_NEON/ __ARM_NEON__ — which GCC/clang do unconditionally on any aarch64 target, since NEON is mandatory in the AArch64 ISA. This causes pngrtran.c and pngrutil.c to reference NEON symbols regardless of OS.

However, src/CMakeLists.txt only compiled the NEON implementation sources (thirdparty/libpng/arm/*.c) under Darwin + arm64:

if (${CMAKE_SYSTEM_NAME} MATCHES "Darwin")
  if(${CMAKE_HOST_SYSTEM_PROCESSOR} MATCHES "arm64")
    include_directories(${PROJECT_SOURCE_DIR}/thirdparty/libpng/arm)
    aux_source_directory(${PROJECT_SOURCE_DIR}/thirdparty/libpng/arm SOURCEFILE)
  else()
    include_directories("/usr/local/include")
  endif()
endif()

On Linux AArch64 the symbols are referenced but never defined, producing the undefined-reference errors above.

Fix

Split the OS-specific include-path logic from the architecture-specific source-selection logic, and gate the latter on the target processor (CMAKE_SYSTEM_PROCESSOR) rather than host + OS:

# ARM libpng sources
if(CMAKE_SYSTEM_PROCESSOR MATCHES "^(arm64|aarch64)$")
    include_directories(${PROJECT_SOURCE_DIR}/thirdparty/libpng/arm)
    aux_source_directory(${PROJECT_SOURCE_DIR}/thirdparty/libpng/arm SOURCEFILE)
endif()

# macOS include paths
if(CMAKE_SYSTEM_NAME MATCHES "Darwin")
    if(CMAKE_SYSTEM_PROCESSOR MATCHES "^(arm64|aarch64)$")
        include_directories("/opt/homebrew/include")
    else()
        include_directories("/usr/local/include")
    endif()
endif()

CMAKE_SYSTEM_PROCESSOR (target arch) is used instead of CMAKE_HOST_SYSTEM_PROCESSOR (build-machine arch), which is also the technically correct variable for this decision and fixes a latent cross-compilation bug in the original code (host arch and target arch only happened to match for native builds).

Behavior on macOS Intel, Apple Silicon, and Linux x86_64 is unchanged.

Testing

  • Reproduced the failure on Linux AArch64 (Ubuntu 24.04, GCC 13.3, CMake 3.28) with the original CMake configuration.
  • Applied this patch and performed a clean rebuild
  • Verified that the bundled libpng ARM NEON sources are now compiled into the build by confirming the generated object files (e.g. filter_neon_intrinsics.c.o and palette_neon_intrinsics.c.o), which were absent before the change.
  • Confirmed the previous undefined NEON linker errors no longer occur.
  • Verified the resulting binary by running, it executes successfully and prints the expected version information.

@ccextractor-bot

Copy link
Copy Markdown
Collaborator
CCExtractor CI platform finished running the test files on linux. Below is a summary of the test results, when compared to test for commit 2feb09a...:
Report Name Tests Passed
Broken 9/13
CEA-708 2/14
DVB 1/7
DVD 3/3
DVR-MS 2/2
General 23/27
Hardsubx 1/1
Hauppage 3/3
MP4 3/3
NoCC 10/10
Options 68/86
Teletext 20/21
WTV 12/13
XDS 31/34

Your PR breaks these cases:

NOTE: The following tests have been failing on the master branch as well as the PR:

Congratulations: Merging this PR would fix the following tests:

  • ccextractor --service 1 --out=ttxt da904de35d..., Last passed: Never
  • ccextractor --autoprogram --out=ttxt --latin1 132d7df7e9..., Last passed: Never
  • ccextractor --autoprogram --out=srt --latin1 b22260d065..., Last passed: Never

It seems that not all tests were passed completely. This is an indication that the output of some files is not as expected (but might be according to you).

Check the result page for more info.

@ccextractor-bot

Copy link
Copy Markdown
Collaborator
CCExtractor CI platform finished running the test files on windows. Below is a summary of the test results, when compared to test for commit 9f78685...:
Report Name Tests Passed
Broken 10/13
CEA-708 2/14
DVB 2/7
DVD 3/3
DVR-MS 2/2
General 25/27
Hardsubx 1/1
Hauppage 3/3
MP4 3/3
NoCC 10/10
Options 78/86
Teletext 20/21
WTV 13/13
XDS 34/34

Your PR breaks these cases:

NOTE: The following tests have been failing on the master branch as well as the PR:

Congratulations: Merging this PR would fix the following tests:

  • ccextractor --out=srt --latin1 611b4a9235..., Last passed: Never
  • ccextractor --autoprogram --out=ttxt --latin1 1020459a86..., Last passed: Never
  • ccextractor --autoprogram --out=ttxt --latin1 132d7df7e9..., Last passed: Never
  • ccextractor --autoprogram --out=ttxt --latin1 99e5eaafdc..., Last passed: Never
  • ccextractor --autoprogram --out=ttxt --latin1 01509e4d27..., Last passed: Never
  • ccextractor --dru c83f765c66..., Last passed: Never
  • ccextractor --startat 4 --endat 7 c83f765c66..., Last passed: Never
  • ccextractor --startcreditstext "CCextractor Start crdit Testing" c4dd893cb9..., Last passed: Never
  • ccextractor --startcreditsnotbefore 1 --startcreditstext "CCextractor Start crdit Testing" c4dd893cb9..., Last passed: Never
  • ccextractor --startcreditsnotafter 2 --startcreditstext "CCextractor Start crdit Testing" c4dd893cb9..., Last passed: Never
  • ccextractor --startcreditsforatleast 1 --startcreditstext "CCextractor Start crdit Testing" c4dd893cb9..., Last passed: Never
  • ccextractor --startcreditsforatmost 2 --startcreditstext "CCextractor Start crdit Testing" c4dd893cb9..., Last passed: Never
  • ccextractor --out=srt --latin1 f23a544ba8..., Last passed: Never
  • ccextractor --autoprogram --out=srt --latin1 --ucla d037c7509e..., Last passed: Never
  • ccextractor --autoprogram --out=srt --latin1 --ucla 7d3f25c32c..., Last passed: Never
  • ccextractor --autoprogram --out=ttxt --latin1 --ucla --xds 7f41299cc7..., Last passed: Never

It seems that not all tests were passed completely. This is an indication that the output of some files is not as expected (but might be according to you).

Check the result page for more info.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants