GNOME Bugzilla – Bug 605938
ORBit2-2.14.17 fails on 'make check'
Last modified: 2018-01-09 01:05:43 UTC
Created attachment 150716 [details] Config.log ./configure --prefix=/usr --sysconfdir=/etc/gnome/2.28.1 (OK) make (OK) make check: Making check in linc2 make[1]: Entering directory `/usr/src/ORBit2-2.14.17/linc2' Making check in include make[2]: Entering directory `/usr/src/ORBit2-2.14.17/linc2/include' Making check in linc make[3]: Entering directory `/usr/src/ORBit2-2.14.17/linc2/include/linc' make check-am make[4]: Entering directory `/usr/src/ORBit2-2.14.17/linc2/include/linc' make[4]: Nothing to be done for `check-am'. make[4]: Leaving directory `/usr/src/ORBit2-2.14.17/linc2/include/linc' make[3]: Leaving directory `/usr/src/ORBit2-2.14.17/linc2/include/linc' make[3]: Entering directory `/usr/src/ORBit2-2.14.17/linc2/include' make[3]: Nothing to be done for `check-am'. make[3]: Leaving directory `/usr/src/ORBit2-2.14.17/linc2/include' make[2]: Leaving directory `/usr/src/ORBit2-2.14.17/linc2/include' Making check in src make[2]: Entering directory `/usr/src/ORBit2-2.14.17/linc2/src' make[2]: Nothing to be done for `check'. make[2]: Leaving directory `/usr/src/ORBit2-2.14.17/linc2/src' Making check in test make[2]: Entering directory `/usr/src/ORBit2-2.14.17/linc2/test' make check-TESTS make[3]: Entering directory `/usr/src/ORBit2-2.14.17/linc2/test' Available protocols: { ' IPv4': 2, 16, 6, 0x0002 [s-ail] ' IPv6': 10, 28, 6, 0x0002 [s-ail] ' UNIX': 1, 110, 0, 0x0003 [-dail] } Testing 'broken' ... Testing blocking code ... buffer 512 buffer 1024 buffer 0 Testing is_local checking ... UNIX IPv4 ** (process:2984): WARNING **: can't getaddrinfo on 'AlexLFS' /bin/sh: line 4: 2984 Segmentation fault ${dir}$tst FAIL: test-linc ======================================================================= 1 of 1 test failed Please report to http://bugzilla.gnome.org/enter_bug.cgi?product=ORBit2 ======================================================================= make[3]: *** [check-TESTS] Error 1 make[3]: Leaving directory `/usr/src/ORBit2-2.14.17/linc2/test' make[2]: *** [check-am] Error 2 make[2]: Leaving directory `/usr/src/ORBit2-2.14.17/linc2/test' make[1]: *** [check-recursive] Error 1 make[1]: Leaving directory `/usr/src/ORBit2-2.14.17/linc2' make: *** [check-recursive] Error 1 ---------------------------------------------------------------------- i686-pc-linux-gnu (B)LFS, 2.6.32.2, GNU Make 3.81, gcc (GCC) 4.1.2 libIDL-0.8.13
Can you do: $ ping `hostname` You need to have a resolving hostname to do this sort of IPv4 test -and (presumably) and IPv4 interface. Having said that a crash is a bit lame; patch appreciated to do better :-)
Created attachment 150786 [details] Successful (network up) 'make check' log
Hi Michael, ANSWERS > ping `hostname` It failed. Why? The network was not up during 'make check' :) Why wasn't it up? Because in 99% of checks for literally hundreds of package installs I didn't need it up nor was it explicitly required. However, to redeem myself, FWIW, I'm attaching the successful 'make check' log. COMMENTS 1. I'm all for _not_ including a comment like "Make sure your network is up" in the INSTALL at step 3 (the optional 'make check'). People weren't reading books anymore even in the preceding "almost non-twitter" decade. However, an ever so delicate hint on 'make check' failure log that the victim should check whether the network is up and about should be in order. A humble suggestion is to follow the example of what they do nowadays on installing the Xorg-7.5 libraries. Some 'pc' files end up in '/usr/share/pkgconfig' now instead of the tried and true '/usr/lib/pkgconfig' like in the old days (xtrans-1.2.5 vs. the 7.4 version). On the ugly compile error, they just indicate that, among other things, you make sure your PKG_CONFIG_PATH is correct (obviously there was no reason to include the "share" path before). That's what it sould be and what I call a word to the wise. (to their credit, the 'man pkgconfig' is of no help especially on the order of directories - confusing and misleading, as it should be). 2. I agree the segfaulting on a dummy's network down situation is a bit over the top. Thank you for your interest and comments. -- Alex
No patch, not a new issue => wontfix. Thanks for the feedback though; happy to take a patch to make it friendlier in this case.
Created attachment 366524 [details] [review] Make test error more friendly than a segfault