On 07/08/2015 10:06 PM, Frans de Boer wrote:
On 07/08/2015 09:36 PM, Bruce Dubbs wrote:
Frans de Boer wrote:
On 07/08/2015 08:10 PM, Bruce Dubbs wrote:
Frans de Boer wrote:
There seems to be a glitch introduced in the latest SVN.
The test 'tests/misc/seq-long-double.sh' seems to take forever now.
The
executed command during this test is 'seq 999999 inf', which seems
just
that infinity.
Never have seen this by 8.23 or earlier. Has anybody else noticed
this?
My log tells me that it took 5 minutes to build and run the tests which
is about the same time coreutils in lfs-7.7 took.
I do not have any more detailed timing than that.
-- Bruce
I swapped 8.24 with 8.23 - leaving all other the same - and everything
worked as before. When I tried 8.23 the mentioned test flashed by, not
giving enough time to to see what the actual command was. When i use seq
from the 8.23 distribution and uses the same arguments it also run
forever. Meaning - probably - that the 'inf' argument is wrong. In the
mentioned shell it is copied from INTIME_OFLOW, but can't find where it
is being set. It must be somewhere within the tests/coreutils package
(8.23 uses the same shell and that worked well).
I went into chroot and the tests pass for me. Looking at the test. it
does:
a=$INTMAX_MAX
b=$INTMAX_OFLOW
seq $a $b > out || fail=1
It looks like it gets the INTMAX_MAX and INTMAX_OFLOW variables from an
executable file src/getlimits. On my system:
INT_MAX =2147483647
INT_OFLOW=2147483648
So it will go fast.
See src/getlimits.c:
#define print_int(TYPE) \
sprintf (limit + 1, "%"PRIuMAX, (uintmax_t) TYPE##_MAX); \
printf (#TYPE"_MAX=%s\n", limit + 1); \
printf (#TYPE"_OFLOW=%s\n", decimal_absval_add_one (limit));
Ultimately, INT_MAX is defined in /usr/include/limits.h:
# define INT_MAX 2147483647
I don't know what system you are working on, but check your headers.
-- Bruce
I will look into it again tomorrow evening (The Netherlands).
Ok, being back and having checked:
The output of getlimits_ for INTMAX_MAX = 9223372036854775807 and for
INT_OFLOW = 9223372036854775808.
Feeding these number into seq makes it run as expected. However on my
system de first command argument was 999999 and the last one 'inf'. So
somewhere these values have changed. I am using a AMD Phenom II X4
64-bit processor. Thus the values are correct but not fed into the seq
command.
There is however a warning displayed:
....
++ INTMAX_MIN=-9223372036854775808
++ INTMAX_UFLOW=-9223372036854775809
++ UINTMAX_MAX=18446744073709551615
++ UINTMAX_OFLOW=18446744073709551616
++ FLT_MIN=1.1754944e-38
++ FLT_MAX=3.4028235e+38
++ DBL_MIN=2.2250738585072014e-308
++ DBL_MAX=1.7976931348623157e+308
++ LDBL_MIN=3.3621031431120935063e-4932
++ LDBL_MAX=1.189731495357231765e+4932
+ test 2147483647
+ cat
+ skip_ 'this test runs only on systems with glibc and long double !=
double'
@Bruce: your system shows the limit for a 32-bit system, might be the
reason why it works with your system?
Regards, Frans.
--
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
Do not top post on this list.
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?
http://en.wikipedia.org/wiki/Posting_style
