Непонятные тормоза при ./configure 0

поизучать вывод

$ grep -A 20 "length of command line" config.log

если не понятно, что написано, привести этот вывод здесь.

может быть, что 20 строчек — мало. а может — много.

ну, там понятно будет.

Никак, это нормальное поведение.

привожу

# grep -A 20 "length of command line" config.log
configure:5305: checking the maximum length of command line arguments
configure:5370: result: 16384
configure:5381: checking command to parse /usr/bin/nm -B output from gcc object
configure:5470: gcc -c -g -O2  conftest.c >&5
configure:5473: $? = 0
configure:5477: /usr/bin/nm -B conftest.o \| sed -n -e 's/^.*[  ]\([ABCDGIRSTW][ABCDGIRSTW]*\)[         ][      ]*\(\)\([_A-Za-z][_A-Za-z0-9]*\)$/\1 \2\3 \3/p'
\> conftest.nm
configure:5480: $? = 0
configure:5532: gcc -o conftest -g -O2   conftest.c conftstm.o >&5
configure:5535: $? = 0
configure:5573: result: ok
configure:5577: checking for objdir
configure:5592: result: .libs
configure:5682: checking for ar
configure:5698: found /usr/bin/ar
configure:5709: result: ar
configure:5762: checking for ranlib
configure:5778: found /usr/bin/ranlib
configure:5789: result: ranlib
configure:5842: checking for strip
configure:5858: found /usr/bin/strip
configure:5869: result: strip

configure:5305: checking the maximum length of command line arguments

configure:5370: result: 16384

осталось поизучать строчки файла 'configure' с 5305 до 5370

что именно оно там делает, и на каком этапе задумывается.

И никто мне не верит, вот ведь. Просто эта директива проверяет максимально возможную длину командной строки, постепенно ее наращивая, а, соответственно, передача толпы аргументов и поиск верхнего порога — задача нешустрая, особенно когда этот порог высокий. Так что, не надо страдать фигней.

вот и пусть в этом сам и убедится, что именно это и происходит.

кстати, вот что интересно ведь.

xargs должен знать, какое максимальное значение длины командной строки может использоваться. т.е. сами textutils об этом в курсе…

cebka
Никак, это нормальное поведение.

Ребята, я ж грю, что это стало с НЕКОТОРОГО времени, т.е. до этого все было путем, и не думал он по столько. :( А строки изучу, но не менять же их в каждом configure ?

нет конечно, менять их не надо.

то есть если раньше на тех же самых программах не думало по стольку, то как раз и надо искать причину этой появившейся задумчивости.

так как задумывается именно на этом, то отдельно эти строчки и рассматривать.

скопировать их в отдельный shell-скрипт, и исполнять с отладкой: sh -x script.

т.е. это-то понятно, я думаю?

кстати, очень интересен будет-таки как и результат, так и решение этой проблемки.

Genie
вот и пусть в этом сам и убедится, что именно это и происходит.

кстати, вот что интересно ведь.

xargs должен знать, какое максимальное значение длины командной строки может использоваться. т.е. сами textutils об этом в курсе…

А ни фига он не знает. Цитата из man:

BUGS

If utility attempts to invoke another command such that the number of

arguments or the size of the environment is increased, it risks execvp(3)

failing with E2BIG.

Смотрим, что за ошибка:

[E2BIG] The number of bytes in the new process' argument list

is larger than the system-imposed limit. This limit

is specified by the sysctl(3) MIB variable

KERN_ARGMAX.

Sysctl, конечно, платформенно зависимый.

У меня, например:

> sysctl -d kern.argmax

kern.argmax: Maximum bytes of argument to execve(2)

kern.argmax: 65536

хммм… вот лично у меня… этта…

$ time echo `dd if=/dev/zero bs=8k count=8k|tr '\0' '#'`|wc -c
8192+0 входных записей
8192+0 выходных записей
67108865
real    0m17.761s
user    0m14.285s
sys     0m2.677s

16k*16k выделять оно, правда, отказалось.

$ echo `dd if=/dev/zero bs=16k count=16k|tr '\0' '#'`|wc -c
16384+0 входных записей
16384+0 выходных записей
bash: xmalloc: cannot allocate 268435457 bytes (0 bytes allocated)
      0

и даже вот так эта зараза пытается что-то делать:

$ time echo `yes 1|dd bs=2 count=32M`|wc -c
33554432+0 входных записей
33554432+0 выходных записей
      0
real    8m0.426s
user    2m7.600s
sys     5m15.469s

видимо, памяти не хватило… :))