LinuxQuestions.org
Welcome to the most active Linux Forum on the web.
Home Forums Tutorials Articles Register
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Linux From Scratch
User Name
Password
Linux From Scratch This Forum is for the discussion of LFS.
LFS is a project that provides you with the steps necessary to build your own custom Linux system.

Notices


Reply
  Search this Thread
Old 05-02-2023, 11:51 AM   #1
jr_bob_dobbs
Member
 
Registered: Mar 2009
Distribution: Bedrock, Devuan, Slackware, Linux From Scratch, Void
Posts: 651
Blog Entries: 135

Rep: Reputation: 188Reputation: 188
BLFS 11.3 x86_64 json_c fails all tests


I'm currently in the middle of a LFS build. I'm following the LFS 11.3 book on my x86_64 computer, except for six deviations.

One. As I did in my previous LFS 8.0, 8.1 and 11.2 installs, I am using the Slackware package tools as the package manager for my LFS. This is verified stable technology that I've used before. For LFS 11.2 on, a newer version of the tools was used, with the advantage of not needing a special version of tar as previous versions did. The Slackware package manager is briefly mentioned in Section 8.2.2.7, paragraph four of the LFS 11.3 book. Naturally this means the packages will not be compiled in the $LFS/sources directory but in a different directory tree, in which each package is compiled and packed in its own directory, while the package contents are installed to the usual locations.

Two. The "which" command is a dependency of one of the Slackware tools. I installed the shell script version from the BLFS book, along with the Slackware tools, before the first package of Chapter 8.

Three. This LFS build, as was done in previous successful builds, is being done in multiple sessions. $LFS is defined for all required users and scripting was created for mistake-free chrooting. The LFS volume is in /etc/fstab and is mounted at boot time.

Four. I'll be installing my text editor instead of vim.

Five. Before the system is bootable, cryptsetup, cpio and lvm-related programs will need to be compiled, because all Linux distros on my computer reside on thin-provisioned LVM partitions.

Six. I'm using the 5.15.86 version of the kernel, because that worked so well with my hardware in my LFS 11.2 system.

A pause to quote from Chapter One of the LFS 11.3 book:
Quote:
Deviating from this book does not mean that we will not help you. After all, LFS is about personal preference. Being up-front about any changes to the established procedure helps us evaluate and determine possible causes of your problem.
The LFS 11.3 install went well, with test results for the three critical packages of binutils, glib and gcc perfect matching those in the LFS book.

Having performed due-diligence as to disclosure about my deviations from the "established procedure," of the LFS 11.3 book, I will now begin my actual question.

Becuase the LFS system is on a thin-provisioned LVM volume that is in turn on a LUKS partition, additional programs need to be compiled before booting into the LFS 11.3 install. So now it's a BLFS install. Here is the compile tree I came up with:
Code:
needed to boot
 o cpio - IN
 o cryptsetup
    * LVM2  v
    * json_c
       - cmake  - IN
          > curl (no crucial deps) - IN
          > ngjttp - IN
             . libxml2  (deps already in) - IN
             . boost - IN
          > libarchive - IN
             . libxml2  (deps already in) - IN
             . lzo  - IN
             . nettle  (deps aready in) - IN
          > libuv  (no deps) - IN
    * popt  (no deps) - IN
 o btrfs_progs - IN
    * lzo  (no deps) - IN
    * [lvm2]   v
    * reiserfsprogs  v
 o LVM2
    * libaio  (no deps) - IN
    * mdadm (no deps) - IN
    * reiserfsprogs  (no deps) - IN
    * which - IN
    * thin_provisioning_tools  v
    * [valgrind] (no deps if no tests) - IN
       - gdb - IN
          > python_six - IN
    * [xfsprogs] - IN
       - inih  (no deps) - IN
       - liburcu (no deps) - IN
 o thin_provisioning_tools - IN
    * libaio  (no deps) - IN
    * boost (will have to use porg for this one) - IN
       - which - IN
       - ICU - IN
          > [firejail] - IN
Right now I'm at json_c and that fails. It fails ALL tests.

Thanks to the use of "make test > $WYAN/test_log.txt 2>&1" in my slack-build script, here is the test output:
Code:
Running tests...
Test project /sources/lfs_slackbuilds/json_c/build_it/json-c-0.16/build
      Start  1: test1
 1/23 Test  #1: test1 ............................***Failed    0.10 sec
      Start  2: test2
 2/23 Test  #2: test2 ............................***Failed    0.11 sec
      Start  3: test4
 3/23 Test  #3: test4 ............................***Failed    0.03 sec
      Start  4: testReplaceExisting
 4/23 Test  #4: testReplaceExisting ..............***Failed    0.03 sec
      Start  5: test_cast
 5/23 Test  #5: test_cast ........................***Failed    0.03 sec
      Start  6: test_charcase
 6/23 Test  #6: test_charcase ....................***Failed    0.03 sec
      Start  7: test_compare
 7/23 Test  #7: test_compare .....................***Failed    0.03 sec
      Start  8: test_deep_copy
 8/23 Test  #8: test_deep_copy ...................***Failed    0.03 sec
      Start  9: test_double_serializer
 9/23 Test  #9: test_double_serializer ...........***Failed    0.03 sec
      Start 10: test_float
10/23 Test #10: test_float .......................***Failed    0.03 sec
      Start 11: test_int_add
11/23 Test #11: test_int_add .....................***Failed    0.03 sec
      Start 12: test_locale
12/23 Test #12: test_locale ......................***Failed    0.03 sec
      Start 13: test_null
13/23 Test #13: test_null ........................***Failed    0.03 sec
      Start 14: test_parse
14/23 Test #14: test_parse .......................***Failed    0.03 sec
      Start 15: test_parse_int64
15/23 Test #15: test_parse_int64 .................***Failed    0.03 sec
      Start 16: test_printbuf
16/23 Test #16: test_printbuf ....................***Failed    0.03 sec
      Start 17: test_set_serializer
17/23 Test #17: test_set_serializer ..............***Failed    0.03 sec
      Start 18: test_set_value
18/23 Test #18: test_set_value ...................***Failed    0.03 sec
      Start 19: test_strerror
19/23 Test #19: test_strerror ....................***Failed    0.03 sec
      Start 20: test_util_file
20/23 Test #20: test_util_file ...................***Failed    0.03 sec
      Start 21: test_visit
21/23 Test #21: test_visit .......................***Failed    0.03 sec
      Start 22: test_object_iterator
22/23 Test #22: test_object_iterator .............***Failed    0.03 sec
      Start 23: test_json_pointer
23/23 Test #23: test_json_pointer ................***Failed    0.03 sec

0% tests passed, 23 tests failed out of 23

Total Test time (real) =   0.85 sec

The following tests FAILED:
	  1 - test1 (Failed)
	  2 - test2 (Failed)
	  3 - test4 (Failed)
	  4 - testReplaceExisting (Failed)
	  5 - test_cast (Failed)
	  6 - test_charcase (Failed)
	  7 - test_compare (Failed)
	  8 - test_deep_copy (Failed)
	  9 - test_double_serializer (Failed)
	 10 - test_float (Failed)
	 11 - test_int_add (Failed)
	 12 - test_locale (Failed)
	 13 - test_null (Failed)
	 14 - test_parse (Failed)
	 15 - test_parse_int64 (Failed)
	 16 - test_printbuf (Failed)
	 17 - test_set_serializer (Failed)
	 18 - test_set_value (Failed)
	 19 - test_strerror (Failed)
	 20 - test_util_file (Failed)
	 21 - test_visit (Failed)
	 22 - test_object_iterator (Failed)
	 23 - test_json_pointer (Failed)
Errors while running CTest
Output from these tests are in: /sources/lfs_slackbuilds/json_c/build_it/json-c-0.16/build/Testing/Temporary/LastTest.log
Use "--rerun-failed --output-on-failure" to re-run the failed cases verbosely.
make: *** [Makefile:91: test] Error 8
I then looked and discovered that the LastTest.log mentioned in the above is a zero length file.

Adding the "--rerun-failed --output-on-failure" parameters to the command I used to test resulted in this:
Code:
make: unrecognized option '--output-on-failure'
Usage: make [options] [target] ...
Options:
  -b, -m                      Ignored for compatibility.
  -B, --always-make           Unconditionally make all targets.
  -C DIRECTORY, --directory=DIRECTORY
                              Change to DIRECTORY before doing anything.
  -d                          Print lots of debugging information.
  --debug[=FLAGS]             Print various types of debugging information.
  -e, --environment-overrides
                              Environment variables override makefiles.
  -E STRING, --eval=STRING    Evaluate STRING as a makefile statement.
  -f FILE, --file=FILE, --makefile=FILE
                              Read FILE as a makefile.
  -h, --help                  Print this message and exit.
  -i, --ignore-errors         Ignore errors from recipes.
  -I DIRECTORY, --include-dir=DIRECTORY
                              Search DIRECTORY for included makefiles.
  -j [N], --jobs[=N]          Allow N jobs at once; infinite jobs with no arg.
  --jobserver-style=STYLE     Select the style of jobserver to use.
  -k, --keep-going            Keep going when some targets can't be made.
  -l [N], --load-average[=N], --max-load[=N]
                              Don't start multiple jobs unless load is below N.
  -L, --check-symlink-times   Use the latest mtime between symlinks and target.
  -n, --just-print, --dry-run, --recon
                              Don't actually run any recipe; just print them.
  -o FILE, --old-file=FILE, --assume-old=FILE
                              Consider FILE to be very old and don't remake it.
  -O[TYPE], --output-sync[=TYPE]
                              Synchronize output of parallel jobs by TYPE.
  -p, --print-data-base       Print make's internal database.
  -q, --question              Run no recipe; exit status says if up to date.
  -r, --no-builtin-rules      Disable the built-in implicit rules.
  -R, --no-builtin-variables  Disable the built-in variable settings.
  --shuffle[={SEED|random|reverse|none}]
                              Perform shuffle of prerequisites and goals.
  -s, --silent, --quiet       Don't echo recipes.
  --no-silent                 Echo recipes (disable --silent mode).
  -S, --no-keep-going, --stop
                              Turns off -k.
  -t, --touch                 Touch targets instead of remaking them.
  --trace                     Print tracing information.
  -v, --version               Print the version number of make and exit.
  -w, --print-directory       Print the current directory.
  --no-print-directory        Turn off -w, even if it was turned on implicitly.
  -W FILE, --what-if=FILE, --new-file=FILE, --assume-new=FILE
                              Consider FILE to be infinitely new.
  --warn-undefined-variables  Warn when an undefined variable is referenced.

This program built for x86_64-pc-linux-gnu
Report bugs to <bug-make@gnu.org>
Has anyone else run tests while building the json_c package as per the BLFS 11.3 book? If so, were they the same results?

Thank you.

Last edited by jr_bob_dobbs; 05-02-2023 at 11:52 AM.
 
Old 05-08-2023, 05:57 PM   #2
coltson
Member
 
Registered: Oct 2010
Posts: 149

Rep: Reputation: 3
Hi. I never tinkered with json_c before (actually, never heard about it until now). However, by reading through your posts, my intuition tells me that there might be something wrong with your cmake install, especially the weird "0" size log file, followed by the not accepting the parameter "--output-on-failure".

You might try to build or use another cmake and test with it, outside your lfs environment, perhaps another version of cmake.
 
Old 05-22-2023, 02:27 PM   #3
jr_bob_dobbs
Member
 
Registered: Mar 2009
Distribution: Bedrock, Devuan, Slackware, Linux From Scratch, Void
Posts: 651

Original Poster
Blog Entries: 135

Rep: Reputation: 188Reputation: 188
Thanks for the reply. I never knew what json_c was either
before I started to use thin provisioning.

Did a bunch of compiles of cmake and json_c versions. Cmake test results seem normal save that there was one test failure: "RunCMake.FindBoost". Checked boost's logs. Boost looks OK.

I then compiled a version of json_c that was old enough to still use ./configure instead of cmake. Bonus, it had previoulsy compiled in an even older LFS from around 2019. All tests still failed! Weird. So cmake is irrelevant to whatever the problem is.

Last edited by jr_bob_dobbs; 05-22-2023 at 02:28 PM.
 
  


Reply



Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
zstd tests failing on decompression only tests fabulousUnicorn Linux From Scratch 6 08-31-2022 11:25 AM
[SOLVED] BLFS 10.0 How do I get total ownership of my blfs system ? Captian Kangeroo Linux From Scratch 4 12-09-2020 08:45 PM
[SOLVED] Dovecot authorization fails when trying to connect via Mutt but all suggested Dovecot auth tests work spenced Linux - Server 1 04-18-2020 11:04 PM
BLFS 8.1: libsoup tests fail jr_bob_dobbs Linux From Scratch 1 02-12-2018 06:46 PM
ipm timed out error on Red Hat 2.6.9-67.0.22.ELsmp #1 SMP x86_64 x86_64 x86_64 GNU/L bellnarm Linux - Newbie 0 07-07-2009 04:36 PM

LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Linux From Scratch

All times are GMT -5. The time now is 07:01 AM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Open Source Consulting | Domain Registration