drop dependency/linking to libpng12

[yarikoptic]

It is an ancient version of the library which is generally no longer available. But the "bleeding edge" https://afni.nimh.nih.gov/pub/dist/tgz/linux_openmp_64.tgz seems to still links to it

❯ ldd linux_openmp_64/afni | grep libpng
	libpng12.so.0 => not found
	libpng16.so.16 => /lib/x86_64-linux-gnu/libpng16.so.16 (0x00007efef2f5c000)

could be avoided???

[afni-rickr]

That ancient build system does not explicitly link to version 12, except that is the version it has. That old package is still built because it actually works on many newer systems without users needing to do almost anything.
We should figure out a more appropriate package for Debian to use. And if you want to go farther, we could actually set up a local Debian build machine with its own Makefile. But note that once we set up a build machine, we generally leave it as static, so that people can rely on its stability (which is why openmp_64 still relies on libpng12, so many years down the road).

[yarikoptic]

I think it would be wise given that AFAIK the majority of Linux systems are Debian based ;)
And ideally there should be no separate Makefile and cmake build system was used ;) @TheChymera attests that it works for his Gentoo builds quite well.

[afni-rickr]

Sure, we don't know of any users asking for Debian, but maybe some want it and we just don't know.
The cmake setup is not quite right yet, in any case. We recently saw that cmake is linking both versions of NIFTI, and the result seems to actually apply NIFTI-1 while the AFNI side requires NIFTI-2. Maybe this even varies to some degree, and it should at least vary based on whether NIFTI is compiled locally. I spent some time and did not figure out how to fix that. I would not trust NIFTI I/O via a cmake package without verifying the linking.

[yarikoptic]

@TheChymera did you observe similar issue with NIFTI lib? have any ideas on how to help?

[TheChymera]

The main afni executable only links NIFTI-2 here (which I ship as part of the AFNI package itself, might be cool to unbundle it, but that's a wholly separate issue):

[deco]~ ❱ ldd /usr/bin/afni | rg nifti
	libnifti2.so.2 => /usr/lib64/libnifti2.so.2 (0x00007f560ede9000)
	libnifticdf.so.2 => /usr/lib64/libnifticdf.so.2 (0x00007f560e575000)
[deco]~ ❱ equery b /usr/lib64/libnifti2.so.2
 * Searching for /usr/lib64/libnifti2.so.2 ...
sci-biology/afni-24.0.08-r1 (/usr/lib64/libnifti2.so.2 -> libnifti2.so.2.1.0)
sci-biology/afni-24.0.08-r1 (/usr/lib64/libnifti2.so.2.1.0)

@afni-rickr anything else I should look for?

I've been very satisfied with the CMake system, and with the fact that @leej3 was still happy to help out with it. I can test some more stuff if you want, but I see no reason to not make more use of it, if anything it might make linking easier to sort out.

[afni-rickr]

Oh, that looks great. I see those are linking to the external libraries, which seems like it should not pose the same problem. In the problematic case, we built them within the same cmake command, so maybe we should not even allow for that local linking option right now. The bad linking turned up in the docker image (which we have not been making in many months now <sigh>).
It's great to know that cmake has been working well for you, and nice to know that @leej3 has been in touch.
Just for kicks, what is the linking for nifti_tool and nifti1_tool?

Also, what is the actual cmake command that you are using to build with? Do you have -DUSE_SYSTEM_NIFTI=ON, for example? The cmake command for docker is in cmake_build_dockerfile.

[TheChymera]

@afni-rickr

[deco]~ ❱ ldd /usr/bin/nifti_tool
	linux-vdso.so.1 (0x00007ffe9b36c000)
	libnifti2.so.2 => /usr/lib64/libnifti2.so.2 (0x00007fadaa4fc000)
	libznz.so.3 => /usr/lib64/libznz.so.3 (0x00007fadaa4f7000)
	libc.so.6 => /lib64/libc.so.6 (0x00007fadaa335000)
	libm.so.6 => /lib64/libm.so.6 (0x00007fadaa25a000)
	libz.so.1 => /usr/lib64/libz.so.1 (0x00007fadaa240000)
	/lib64/ld-linux-x86-64.so.2 (0x00007fadaa588000)
[deco]~ ❱ ldd /usr/bin/nifti1_tool
	linux-vdso.so.1 (0x00007fffa44cd000)
	libniftiio.so.2 => /usr/lib64/libniftiio.so.2 (0x00007f6d75291000)
	libznz.so.3 => /usr/lib64/libznz.so.3 (0x00007f6d7528c000)
	libc.so.6 => /lib64/libc.so.6 (0x00007f6d750ca000)
	libm.so.6 => /lib64/libm.so.6 (0x00007f6d74fef000)
	libz.so.1 => /usr/lib64/libz.so.1 (0x00007f6d74fd5000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f6d75306000)

As for the CMake command, it's here (it's also mostly transparent from the Gentoo build recipe):

cmake -C /var/tmp/portage/sci-biology/afni-24.0.08-r1/work/afni-AFNI_24.0.08_build/gentoo_common_config.cmake
    -G Ninja
    -DCMAKE_INSTALL_PREFIX=/usr
    -DLIBDIR=/usr/lib64
    -DNIFTI_INSTALL_LIBRARY_DIR=/usr/lib64
    -DGIFTI_INSTALL_LIBRARY_DIR=/usr/lib64
    -DGIFTI_INSTALL_LIB_DIR=/usr/lib64
    -DAFNI_INSTALL_LIBRARY_DIR=/usr/lib64
    -DCMAKE_INSTALL_LIBDIR=/usr/lib64
    -DCOMP_COREBINARIES=ON
    -DUSE_SYSTEM_NIFTI=OFF
    -DUSE_SYSTEM_GIFTI=OFF
    -DUSE_SYSTEM_XMHTML=OFF
    -DUSE_SYSTEM_GTS=ON
    -DFETCHCONTENT_SOURCE_DIR_NIFTI_CLIB=/var/tmp/portage/sci-biology/afni-24.0.08-r1/work/nifti_clib-da476fd27f46098f37f5c9c4c1baee01e559572c
    -DFETCHCONTENT_SOURCE_DIR_GIFTI_CLIB=/var/tmp/portage/sci-biology/afni-24.0.08-r1/work/gifti_clib-d3e873d8539d9b469daf7db04093da1d7e73d4f7
    -DCOMP_GUI=ON
    -DCOMP_PLUGINS=ON
    -DUSE_OMP=ON
    -DCOMP_PYTHON=OFF
    -DUSE_SYSTEM_F2C=ON
    -DCMAKE_BUILD_TYPE=RelWithDebInfo
    -DCMAKE_TOOLCHAIN_FILE=/var/tmp/portage/sci-biology/afni-24.0.08-r1/work/afni-AFNI_24.0.08_build/gentoo_toolchain.cmake
    /var/tmp/portage/sci-biology/afni-24.0.08-r1/work/afni-AFNI_24.0.08

And these are the mystery Gentoo file contents from the command above:

decohost ~ # cat /var/tmp/portage/sci-biology/afni-24.0.08-r1/work/afni-AFNI_24.0.08_build/gentoo_common_config.cmake
set(CMAKE_GENTOO_BUILD ON CACHE BOOL "Indicate Gentoo package build")
set(LIB_SUFFIX 64 CACHE STRING "library path suffix" FORCE)
set(CMAKE_INSTALL_LIBDIR lib64 CACHE PATH "Output directory for libraries")
set(CMAKE_INSTALL_INFODIR "/usr/share/info" CACHE PATH "")
set(CMAKE_INSTALL_MANDIR "/usr/share/man" CACHE PATH "")
set(CMAKE_USER_MAKE_RULES_OVERRIDE "/var/tmp/portage/sci-biology/afni-24.0.08-r1/work/afni-AFNI_24.0.08_build/gentoo_rules.cmake" CACHE FILEPATH "Gentoo override rules")
set(CMAKE_INSTALL_DOCDIR "/usr/share/doc/afni-24.0.08-r1" CACHE PATH "")
set(BUILD_SHARED_LIBS ON CACHE BOOL "")
set(Python3_FIND_UNVERSIONED_NAMES FIRST CACHE STRING "")
set(FETCHCONTENT_FULLY_DISCONNECTED ON CACHE BOOL "")
set(CMAKE_DISABLE_PRECOMPILE_HEADERS ON CACHE BOOL "")
set(CMAKE_INSTALL_ALWAYS 1)
set(CMAKE_ASM_FLAGS_RELWITHDEBINFO "" CACHE STRING "")
set(CMAKE_ASM-ATT_FLAGS_RELWITHDEBINFO "" CACHE STRING "")
set(CMAKE_C_FLAGS_RELWITHDEBINFO "" CACHE STRING "")
set(CMAKE_CXX_FLAGS_RELWITHDEBINFO "" CACHE STRING "")
set(CMAKE_Fortran_FLAGS_RELWITHDEBINFO "" CACHE STRING "")
set(CMAKE_EXE_LINKER_FLAGS_RELWITHDEBINFO "" CACHE STRING "")
set(CMAKE_MODULE_LINKER_FLAGS_RELWITHDEBINFO "" CACHE STRING "")
set(CMAKE_SHARED_LINKER_FLAGS_RELWITHDEBINFO "" CACHE STRING "")
set(CMAKE_STATIC_LINKER_FLAGS_RELWITHDEBINFO "" CACHE STRING "")
decohost ~ # cat /var/tmp/portage/sci-biology/afni-24.0.08-r1/work/afni-AFNI_24.0.08_build/gentoo_toolchain.cmake
set(CMAKE_ASM_COMPILER "x86_64-pc-linux-gnu-gcc")
set(CMAKE_ASM-ATT_COMPILER "x86_64-pc-linux-gnu-gcc")
set(CMAKE_C_COMPILER "x86_64-pc-linux-gnu-gcc")
set(CMAKE_CXX_COMPILER "x86_64-pc-linux-gnu-g++")
set(CMAKE_Fortran_COMPILER "x86_64-pc-linux-gnu-gfortran")
set(CMAKE_AR /usr/bin/x86_64-pc-linux-gnu-ar CACHE FILEPATH "Archive manager" FORCE)
set(CMAKE_RANLIB /usr/bin/x86_64-pc-linux-gnu-ranlib CACHE FILEPATH "Archive index generator" FORCE)
set(CMAKE_SYSTEM_PROCESSOR "x86_64")

This could be done even better ofc, I should be using more system stuff, or at least try to and notify you of version incompatibilities, but I took a break from it after the last stint. @yarikoptic I could get back on this if it's also useful to you 🤔

[afni-rickr]

It is helpful to have these for reference, and to see that things work well when using the system libraries. Thanks!