Maneage - Bugs: bug #63043, cmake build rule uses host...
You are not allowed to post comments on this tracker with your current authentication level.
bug #63043: cmake build rule uses host liblzma.so and other host libraries
Submitter: | Boud Roukema <boud> | ||
Submitted: | Sat 10 Sep 2022 12:55:27 PM UTC | ||
Category: | Software | Severity: | 4 - Important |
Item Group: | Output not reasonable | Status: | Fixed |
Privacy: | Public | Assigned to: | boud |
Open/Closed: | Open |
( Jump to the original submission )
Tue 20 Sep 2022 08:36:17 PM UTC, comment #8: |
Boud Roukema <boud>![]() ![]() |
Thu 15 Sep 2022 04:36:23 PM UTC, comment #7: Thanks a lot for the complete analysis of the situation! I hadn't noticed the 'git clone' parts! Probably they are used when they decided to update those software and build new CMake tarballs, not when building from a pre-built tarball.
|
Mohammad Akhlaghi <makhlaghi>![]() |
Tue 13 Sep 2022 09:40:08 PM UTC, comment #6: It seems like the internal versions are in:
|
Boud Roukema <boud>![]() ![]() |
Sun 11 Sep 2022 08:59:06 PM UTC, comment #5: As you mentioned, one of the reasons that I had initially added the '--system-*' options was to be sure about the versions of these libraries in the final reporting of the used software by CMake.
|
Mohammad Akhlaghi <makhlaghi>![]() |
Sun 11 Sep 2022 08:54:36 PM UTC, comment #4: I just tried building CMake by removing all those '--system-*' options, and instead completely disabled any system libs by adding '--no-system-libs' instead.
|
Mohammad Akhlaghi <makhlaghi>![]() |
Sun 11 Sep 2022 03:26:58 PM UTC, comment #3: I had a look in my build logs for CMake (it has always been bothering us in Maneage from the day it was inserted! Anytime someone asks me what is the worst software you have confronted, I always immediately say CMake! It doesn't even need thinking! But any way, let's get to the main point...).
|
Mohammad Akhlaghi <makhlaghi>![]() |
Sat 10 Sep 2022 11:05:11 PM UTC, comment #2: Compilation of 'cmake' fails on CentOS 7, so ldd .local/bin/cmake gives No such file or directory . :P
|
Boud Roukema <boud>![]() ![]() |
Sat 10 Sep 2022 07:36:06 PM UTC, comment #1: I'll look into the build logs of CMake next time I build Maneage. But a good way to check the linking status of a program or shared library is to use 'ldd' (on GNU/Linux systems). When I run it on my current build of Maneage I get the output shown in the P.S.
|
Mohammad Akhlaghi <makhlaghi>![]() |
Sat 10 Sep 2022 12:55:27 PM UTC, original submission:
DESCRIPTION:
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.
|
Boud Roukema <boud>![]() ![]() |
No files currently attached
Depends on the following items: None found
Items that depend on this one: None found
There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.
Follow 2 latest changes.
Date | Changed by | Updated Field | Previous Value | => | Replaced by |
---|---|---|---|---|---|
2022-09-15 | makhlaghi | Status | None | ![]() |
Fixed |
Assigned to | None | ![]() |
boud |
Commit 52814c3 builds fully from scratch through to final verify.tex checksums on CentOS 7 and Debian 11.5. Fine by me to put this in the core branch and close this (cmake) bug.
https://codeberg.org/boud/maneage_dev/commit/52814c33554cd03a3ce54d8e25bed30688201cbc