It seems like the internal versions are in:

cmake-3.24.0/Utilities/cmbzip2
cmake-3.24.0/Utilities/cmcurl
cmake-3.24.0/Utilities/cmliblzma
cmake-3.24.0/Utilities/cmzlib

but there are also scripts for doing git clone to upstream repositories of these:

cmake-3.24.0/Utilities/Scripts/update-bzip2.bash
cmake-3.24.0/Utilities/Scripts/update-curl.bash
cmake-3.24.0/Utilities/Scripts/update-liblzma.bash
cmake-3.24.0/Utilities/Scripts/update-third-party.bash
cmake-3.24.0/Utilities/Scripts/update-zlib.bash

On Debian 11.3, using --no-system-libs and grepping the log gives:

egrep -C1 --color=always "cmliblzma" log.config.20220912.1 |wc
    622    9678  450111
egrep -C1 --color=always "git clone" log.config.20220912.1 |wc
      0       0       0

On CentOS 7,  using --no-system-libs and grepping the log gives:

egrep -C1 --color=always "cmliblzma" log.config.20220912.1 |wc
    691   10164  430116
egrep -C1 --color=always "git clone" log.config.20220912.1 |wc
      0       0       0

So it seems very much like the internal cmake Utilities/ versions are used, not versions downloaded with git clone.
The output from ldd is similar to what you (Mohammad) gave.

So then the question is whether cmake having different versions of curl and the three compression libraries to the Maneage versions of the four libraries could cause build bugs, analysis bugs, or reproducibility bugs (or others?).

My guess is that cmake will only do de_compression, not compression. I have no idea if cmake rules can have the effect of using cmake as a binary front end to _curl.

Given that the four packages are, AFAIK, quite mature, it's quite likely that back-portability should be quite good between different versions that are not too far from each other. If problems do occur, then people using packages that depend on cmake will have to re-open this bug, or open a related one and propose a more robust solution.

So I'm fine with --no-system-libs and the LaTeX target something like: "CMake $(cmake-version) (with internal libraries distributed in Utilities/cm* in tarball)".

I just tried building CMake by removing all those '--system-*' options, and instead completely disabled any system libs by adding '--no-system-libs' instead.

In the build commands, I noticed that the build commands contain '-DLZMA_API_STATIC' option, and in the end, and in the full log, I couldn't find any '/usr/lib/*.so' in any of the linking commands!

In the end, I could also confirm that it had done a static build to its internal libz, liblzma, libcurl and libbz2 (its not in the libraries it now links to, see the P.S.).

Can you try this on your CentOS 7?


P.S. List of libraries that CMake links with when it is built with '--no-system-libs':

$ ldd .local/bin/cmake
        libgcc_s.so.1 => /BDIR/software/installed/lib/libgcc_s.so.1 (0x00007f5fa675f000)
        libiconv.so.2 => /BDIR/software/installed/lib/libiconv.so.2 (0x00007f5fa6919000)
        libssl.so.3 => /BDIR/software/installed/lib/libssl.so.3 (0x00007f5fa6868000)
        libcrypto.so.3 => /BDIR/software/installed/lib/libcrypto.so.3 (0x00007f5fa6200000)
        libstdc++.so.6 => /BDIR/software/installed/lib/libstdc++.so.6 (0x00007f5fa5e00000)
        libz.so.1 => /BDIR/software/installed/lib/libz.so.1 (0x00007f5fa6742000)
        libm.so.6 => /usr/lib/libm.so.6 (0x00007f5fa6780000)
        libc.so.6 => /usr/lib/libc.so.6 (0x00007f5fa5c19000)
        linux-vdso.so.1 (0x00007ffdc496b000)
        /lib64/ld-linux-x86-64.so.2 => /usr/lib64/ld-linux-x86-64.so.2 (0x00007f5fa7576000)

Compilation of 'cmake' fails on CentOS 7, so ldd .local/bin/cmake gives No such file or directory . :P

On Debian 11.3, ldd .local/bin/cmake shows that the Maneage libraries for curl, liblzma, bz2, have been linked.

So the risk might be lower than I stated earlier: if linking succeeds, then on at least two systems, the Maneage libraries are linked, not the host ones.

Hypothesis: with the current build rules, both the host system and Maneage libraries are examined, and, if both are valid, a decision is then made to use the Maneage libraries (probably because they're listed first). However, if one is invalid (missing symbols), then there's a fatal error.

On Debian 11.3, the log includes lines like

/BUILD/software/installed/bin/g++ -liconv -O3 -DNDEBUG -Wl,-rpath-link=/BUILD/software/installed/lib -L/BUILD/software/installed/lib CMakeFiles/testAffinity.dir/testAffinity.cxx.o -o testAffinity  ../../Source/libCMakeLib.a ../../Source/kwsys/libcmsys.a ../../Utilities/std/libcmstd.a ../../Utilities/cmexpat/libcmexpat.a ../../Utilities/cmlibarchive/libarchive/libcmlibarchive.a /usr/lib/x86_64-linux-gnu/libz.so /usr/lib/x86_64-linux-gnu/liblzma.so ../../Utilities/cmzstd/libcmzstd.a /BUILD/software/installed/lib/libbz2.so /BUILD/software/installed/lib/libcurl.so ../../Utilities/cmjsoncpp/libcmjsoncpp.a ../../Utilities/cmlibuv/libcmlibuv.a -ldl -lrt ../../Utilities/cmlibrhash/libcmlibrhash.a -lpthread

The option '-L/BUILD/software/installed/lib' is given before '/usr/lib/x86_64-linux-gnu/liblzma.so', and 'g++' may work with several iterations - first check for consistency, and later make a final decision.

In any case, it should be possible to find build rules for cmake where '/usr/lib/x86_64-linux-gnu/liblzma.so' is absent or becomes '/BUILD/software/installed/lib/liblzma.so'; that would give valid command lines for the compile instructions.

The error appears to come from something like a 'configure' command earlier, but 'cmake' doesn't use a standard 'configure' file, just './bootstrap', so it's not clear where the problem happens; there are several lines like this:

checking for -Wl,--no-as-needed... -- Looking for lzma_lzma_preset in /usr/lib/x86_64-linux-gnu/liblzma.so - found
-- Found LibLZMA: /usr/lib/x86_64-linux-gnu/liblzma.so (found version "5.2.5")

I'm just guessing: I'm not an expert on g++ compilation algorithms or the cmake build algorithm.

DESCRIPTION:
Maneage commit f459fc2 [1] (same as core maneage 4318670, but with the xz hack reverted), configured on CentOS 7, has a fatal error when compiling cmake, as explained in bug 62700 [0]. This is because the cmake build rule in high-level.mk says

       ./bootstrap --prefix=$(idir) --system-curl --system-zlib \
                    --system-bzip2 --system-liblzma &&          \

which (presumably) means that "system" libraries should be used, not cmake's own versions. This was inserted in commit 2a3304cfb of Maneage in Dec 2018 by Mohammad. The motivation is (most likely) to avoid cmake's choice of libraries, and instead use Maneage's versions. However, cmake's bootstrap and configure system chooses, in some cases, host system versions of these libraries instead of the Maneage versions.

This is a bug in our build of cmake on any OS, since we have all four of curl, zlib, bzip2, and liblzma built earlier in the configure pipeline. We should not use host libraries that we already have prepared within Maneage.

Bug 62700 is only one example of this cmake build bug having bad consequences; other examples may have occurred undetected, and future examples can be expected.

REPRODUCE THE BUG:
To see the error, build commit f459fc2 [1] from scratch.

Do grep /usr/lib64/liblzma\.so on the log of the build, where /usr/lib64/liblzma\.so* is your host system location of liblzma.so .

You should see something like

/BUILD/build/software/installed/bin/g++ -liconv -O3 -DNDEBUG -Wl,-rpath-link=/BUILD/build/software/installed/lib -L/BUILD/build/software/installed/lib CMakeFiles/ctresalloc.dir/CTestResourceAllocation/ctresalloc.cxx.o -o ../../bin/ctresalloc  ../../Source/libCTestLib.a ../../Source/libCMakeLib.a ../../Source/kwsys/libcmsys.a ../../Utilities/std/libcmstd.a ../../Utilities/cmexpat/libcmexpat.a ../../Utilities/cmlibarchive/libarchive/libcmlibarchive.a /usr/lib64/libz.so /usr/lib64/liblzma.so ../../Utilities/cmzstd/libcmzstd.a /usr/lib64/libbz2.so ../../Utilities/cmjsoncpp/libcmjsoncpp.a ../../Utilities/cmlibuv/libcmlibuv.a -ldl -lrt ../../Utilities/cmlibrhash/libcmlibrhash.a -lpthread /BUILD/build/software/installed/lib/libcurl.so

This particular line shows that host-system liblzma.so and libbz2.so were linked, though Maneage libcurl.so was linked. In general, this bug is likely to lead to random behaviour.

FAILED HACKS:
Commit 213eddd [2] tries adding LDFLAGS and CFLAGS to the cmake rule to try to force usage of Maneage libraries.

Commit fa98e74e [3] tries adding LDFLAGS alone to the cmake rule to try to force usage of Maneage libraries.

Both these commits fail: they still show linking to /usr/lib64/liblzma.so in the cmake build.

My guess is that some sort of usage of LDFLAGS and CFLAGS should be able to work, keeping in mind that Darwin/xnu apparently has a problem if both C_INCLUDE_FLAGS and CPPFLAGS include the same directory. The question is where to insert these into the cmake build structure.

URLS:
[0] https://savannah.nongnu.org/bugs/?62700

[1] https://codeberg.org/boud/maneage_dev/commit/f459fc2199f1a2b74702efa7e8d239c276e2ed97 (core Maneage without the xz hack)

[2] https://codeberg.org/boud/maneage_dev/commit/213eddd9cc456a2a5c272ccf2080dd6027fbd070 (LDFLAGS and CFLAGS)

[3] https://codeberg.org/boud/maneage_dev/commit/fa98e74e2313026198125566c57b20ad9cbb53a5 (LDFLAGS)