reproduce-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug #63043] cmake build rule uses host liblzma.so and other host librar


From: Boud Roukema
Subject: [bug #63043] cmake build rule uses host liblzma.so and other host libraries
Date: Tue, 13 Sep 2022 17:40:08 -0400 (EDT)

Follow-up Comment #6, bug #63043 (project reproduce):

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)".



    _______________________________________________________

Reply to this item at:

  <https://savannah.nongnu.org/bugs/?63043>

_______________________________________________
Message sent via Savannah
https://savannah.nongnu.org/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]