Paul Eggert wrote:
Thanks for tracking it down. I see the problem now. Gzip uses a different style of finding executables, where one can copy an executable to a different directory without changing its behavior, so I applied this fix instead. If it doesn't fix your problem please let me know.
Thanks. After aplying the patch the test still fails, even in a more explicit way. It now mentions zutils in test-suite.log:
-------------------------------- + env zegrep --help zgrep: unrecognized option '--__bindir' Try '/usr/local/bin/zutils --help' for more information. + fail=1 + env zegrep --version zgrep: unrecognized option '--__bindir' Try '/usr/local/bin/zutils --help' for more information. --------------------------------And the scripts remain unusable until they are installed in $bindir (or the '--__bindir' option is explicitly passed to them):
-------------------------------- $ ./zcmp --version zcmp (gzip) 1.5 Copyright (C) 2010 Free Software Foundation, Inc. This is free software. You may redistribute copies of it under the terms of the GNU General Public License <http://www.gnu.org/licenses/gpl.html>. There is NO WARRANTY, to the extent permitted by law. Written by Paul Eggert. $ ./zcmp a b zdiff: unrecognized option '--__bindir' Try 'zdiff --help' for more information. $ --------------------------------I have been testing the "different style of finding executables" of gzip and I think it is broken unless the "executables to be found" are located at $bindir. For example, zcmp can be moved out of $bindir as long as zdiff remains in $bindir.
OTOH, the method used by ed works in any directory (even before installation) as long as 'ed' and 'red' remain together in the same directory.
BTW, any simplification in the configuration of gzip is welcome. In the AMD K6 II where I am testing this, configure takes 4m20s to execute.
Best regards, Antonio.
test-suite.log.lz
Description: Binary data
