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: Sat, 10 Sep 2022 08:55:29 -0400 (EDT)

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

                 Summary: cmake build rule uses host liblzma.so and other host
libraries
                 Project: Maneage
               Submitter: boud
               Submitted: Sat 10 Sep 2022 12:55:27 PM UTC
                Category: Software
                Severity: 4 - Important
              Item Group: Output not reasonable
                  Status: None
                 Privacy: Public
             Assigned to: None
             Open/Closed: Open
         Discussion Lock: Any


    _______________________________________________________

Follow-up Comments:


-------------------------------------------------------
Date: Sat 10 Sep 2022 12:55:27 PM UTC By: Boud Roukema <boud>
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)








    _______________________________________________________

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]