libpng linking error: libonnxruntime-genai.so: undefined reference to `png_init_filter_functions_vsx'

[mgiessing]

Describe the bug
Linking libpng throws an error libonnxruntime-genai.so: undefined reference to 'png_init_filter_functions_vsx' when building onnxruntime-genai (v0.7.0) using python3 build.py --ort_home=/onnxruntime-genai/ort --cmake_generator Ninja --parallel --config Release:

[...]
FAILED: benchmark/c/model_benchmark 
: && /opt/rh/gcc-toolset-13/root/usr/bin/c++ -O3 -DNDEBUG -mcpu=power8 benchmark/c/CMakeFiles/model_benchmark.dir/main.cpp.o benchmark/c/CMakeFiles/model_benchmark.dir/options.cpp.o benchmark/c/CMakeFiles/model_benchmark.dir/posix/resource_utils.cpp.o -o benchmark/c/model_benchmark -L/onnxruntime-genai/ort/lib -Wl,-rpath,/onnxruntime-genai/ort/lib:/onnxruntime-genai/build/Linux/Release  libonnxruntime-genai.so  -lonnxruntime && :
/opt/rh/gcc-toolset-13/root/usr/libexec/gcc/ppc64le-redhat-linux/13/ld: libonnxruntime-genai.so: undefined reference to `png_init_filter_functions_vsx'
collect2: error: ld returned 1 exit status
[164/165] Linking CXX executable unit_tests
FAILED: unit_tests 
: && /opt/rh/gcc-toolset-13/root/usr/bin/c++ -O3 -DNDEBUG -mcpu=power8 test/CMakeFiles/unit_tests.dir/c_api_tests.cpp.o test/CMakeFiles/unit_tests.dir/main.cpp.o test/CMakeFiles/unit_tests.dir/model_tests.cpp.o test/CMakeFiles/unit_tests.dir/sampling_benchmark.cpp.o test/CMakeFiles/unit_tests.dir/sampling_tests.cpp.o test/CMakeFiles/unit_tests.dir/worker_thread_test.cpp.o -o unit_tests -L/onnxruntime-genai/ort/lib -Wl,-rpath,/onnxruntime-genai/ort/lib:/onnxruntime-genai/build/Linux/Release  libonnxruntime-genai.so  lib/libgtest.a  -lpthread && :
/opt/rh/gcc-toolset-13/root/usr/libexec/gcc/ppc64le-redhat-linux/13/ld: libonnxruntime-genai.so: undefined reference to `png_init_filter_functions_vsx'
collect2: error: ld returned 1 exit status
ninja: build stopped: subcommand failed.
[...]

I do not have access to an ARM or x86 system, but I would assume on those systems it would try to link against png_init_filter_functions_neon or png_init_filter_functions_avx (or avx2/avx512)

To Reproduce
Steps to reproduce the behavior:

Probably difficult as you won't have a Power System 😅

However my build script looks roughly like this:

ARCH=ppc64le #x86_64 for intel, aarch64 for arm...

docker run -ti --rm quay.io/pypa/manylinux_2_28_${ARCH}:2024.11.23-1

git clone -b v0.7.0 https://github.com/microsoft/onnxruntime-genai && cd onnxruntime-genai

mkdir ort && cd ort
# I manually build onnxruntime1.20.1 before which I copy in here
cp /tmp/onnxruntime-linux-ppc64le-v1.20.1.tgz .
tar -xvf onnxruntime-linux-ppc64le-v1.20.1.tgz
mv onnxruntime-linux-ppc64le-v1.20.1/include .
mv onnxruntime-linux-ppc64le-v1.20.1/lib .

export PATH=/opt/python/cp310-cp310/bin:$PATH

# Seems cmake==4.0.0 is too new?
pip3 install --prefer-binary --extra-index-url https://repo.fury.io/mgiessing "cmake<4" requests ninja

python3 build.py --ort_home=/onnxruntime-genai/ort --cmake_generator Ninja --parallel --config Release

Everything runs through until the linking is failing

Expected behavior
I'd expect to build properly

Screenshots
If applicable, add screenshots to help explain your problem.

Desktop (please complete the following information):

• OS: Almalinux8 (manylinux_2_28 pypi image to built glibc 2.28 compliant wheels)
• Version onnxruntime-genai v0.7.0

Additional context
Interstingly I can make this work if I just "disable" the powerpc intrinsics (VSX) by changing the following flag in build/Linux/Release/_deps/dlib-src/dlib/external/libpng/pngpriv.h and rebuild:

[...]
#  define PNG_POWERPC_VSX_IMPLEMENTATION 1
[...]

to

[...]
#  define PNG_POWERPC_VSX_IMPLEMENTATION 0
[...]

[wenbingl]

@mgiessing, I think you already found the root cause. the source code comes from this github project https://github.com/davisking/dlib/blob/3ac03fa4d835599bfc6602678f2c6ccbb3d58c6d/dlib/external/libpng/pngpriv.h#L269, so either this libpng sub project should include png_init_filter_functions_vsx function for PowerPc, or disable PNG_POWERPC_VSX_IMPLEMENTATION. If you can contribute a change for that and validate the fixing with your PowerPc system, the owner of dlib is always welcoming the PR.