Discussion:
make distclean and bash-4.4 - FYI
Michael Felt
2018-10-31 19:03:25 UTC
Permalink
Hi,

I finally got around to patching and packaging bash-4.4.23 and had to
run a "make distclean" because I had copied the old version and without
the make distclean make kept looking for "bashversion" in the old path
.../bash-4.4.19/bashversion

This is just FYI - I'll install yacc, which is what make is complaining
about now - but I also wonder if I could have avoided this by trying to
build oot (out of tree). Is this supported, or even recommended?

Thanks for a great product!

Michael
Michael Felt
2018-10-31 19:13:19 UTC
Permalink
Post by Michael Felt
Hi,
I finally got around to patching and packaging bash-4.4.23 and had to
run a "make distclean" because I had copied the old version and without
the make distclean make kept looking for "bashversion" in the old path
.../bash-4.4.19/bashversion
This is just FYI - I'll install yacc,
make worked well after yacc was installed
Post by Michael Felt
which is what make is complaining
about now - but I also wonder if I could have avoided this by trying to
build oot (out of tree). Is this supported, or even recommended?
Thanks for a great product!
Michael
Running "make test", and I amy have forgotten something I did in the past.
a) running tests as root (initially)
b) ends with:
run-vredir
14,16c14,16
< ./vredir.tests: line 25: $v: A file descriptor does not refer to an
open file.
< ./vredir.tests: line 26: $v: A file descriptor does not refer to an
open file.
< ./vredir.tests: line 27: $v: A file descriptor does not refer to an
open file.
---
Post by Michael Felt
./vredir.tests: line 25: $v: Bad file descriptor
./vredir.tests: line 26: $v: Bad file descriptor
./vredir.tests: line 27: $v: Bad file descriptor
90,91c90,91
< ./vredir6.sub: redirection error: cannot duplicate fd: The process
file table is full.
< ./vredir6.sub: line 13: /dev/null: The process file table is full.
---
Post by Michael Felt
./vredir6.sub: redirection error: cannot duplicate fd: Invalid argument
./vredir6.sub: line 13: /dev/null: Invalid argument
I am mainly surprised by "process file table is full" - is there
something specific I can do to look at this more closely?

Michael
Chet Ramey
2018-10-31 19:31:54 UTC
Permalink
Post by Michael Felt
Running "make test", and I amy have forgotten something I did in the past.
a) running tests as root (initially)
run-vredir
14,16c14,16
< ./vredir.tests: line 25: $v: A file descriptor does not refer to an
open file.
< ./vredir.tests: line 26: $v: A file descriptor does not refer to an
open file.
< ./vredir.tests: line 27: $v: A file descriptor does not refer to an
open file.
---
Post by Michael Felt
./vredir.tests: line 25: $v: Bad file descriptor
./vredir.tests: line 26: $v: Bad file descriptor
./vredir.tests: line 27: $v: Bad file descriptor
These are just different messages for the same value of errno.
Post by Michael Felt
90,91c90,91
< ./vredir6.sub: redirection error: cannot duplicate fd: The process
file table is full.
< ./vredir6.sub: line 13: /dev/null: The process file table is full.
---
Post by Michael Felt
./vredir6.sub: redirection error: cannot duplicate fd: Invalid argument
./vredir6.sub: line 13: /dev/null: Invalid argument
Same.
Post by Michael Felt
I am mainly surprised by "process file table is full" - is there
something specific I can do to look at this more closely?
No, it's expected. That script tests the behavior when the process's open
file limit (`ulimit -n') is set to something very small. It's interesting
that AIX (you're running AIX, right?) chooses to return -1/EMFILE even
though the process doesn't have the maximum number of file descriptors open.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU ***@case.edu http://tiswww.cwru.edu/~chet/
Michael Felt
2018-11-01 10:43:10 UTC
Permalink
Post by Chet Ramey
Post by Michael Felt
Running "make test", and I amy have forgotten something I did in the past.
a) running tests as root (initially)
run-vredir
14,16c14,16
< ./vredir.tests: line 25: $v: A file descriptor does not refer to an
open file.
< ./vredir.tests: line 26: $v: A file descriptor does not refer to an
open file.
< ./vredir.tests: line 27: $v: A file descriptor does not refer to an
open file.
---
Post by Michael Felt
./vredir.tests: line 25: $v: Bad file descriptor
./vredir.tests: line 26: $v: Bad file descriptor
./vredir.tests: line 27: $v: Bad file descriptor
These are just different messages for the same value of errno.
Post by Michael Felt
90,91c90,91
< ./vredir6.sub: redirection error: cannot duplicate fd: The process
file table is full.
< ./vredir6.sub: line 13: /dev/null: The process file table is full.
---
Post by Michael Felt
./vredir6.sub: redirection error: cannot duplicate fd: Invalid argument
./vredir6.sub: line 13: /dev/null: Invalid argument
Same.
Post by Michael Felt
I am mainly surprised by "process file table is full" - is there
something specific I can do to look at this more closely?
No, it's expected. That script tests the behavior when the process's open
file limit (`ulimit -n') is set to something very small.
Using defaults:
***@x065:[/]ulimit -n
2000
Post by Chet Ramey
It's interesting
that AIX (you're running AIX, right?) chooses to return -1/EMFILE even
though the process doesn't have the maximum number of file descriptors open.
Well, it is AIX 5.3 (TL7). Maybe there are more choices for errno today, than there was in 2007. I'll create a clean source to patch/build oot, and compare AIX 5.3, 61. and 7.1 (no ready access to 7.2, sorry).
Michael Felt
2018-11-01 11:24:59 UTC
Permalink
Post by Michael Felt
Post by Chet Ramey
Post by Michael Felt
I am mainly surprised by "process file table is full" - is there
something specific I can do to look at this more closely?
No, it's expected. That script tests the behavior when the process's open
file limit (`ulimit -n') is set to something very small.
2000
Post by Chet Ramey
It's interesting
that AIX (you're running AIX, right?) chooses to return -1/EMFILE even
though the process doesn't have the maximum number of file descriptors open.
Well, it is AIX 5.3 (TL7). Maybe there are more choices for errno today, than there was in 2007. I'll create a clean source to patch/build oot, and compare AIX 5.3, 61. and 7.1 (no ready access to 7.2, sorry).
In case you are interested..
AIX 6.1 and 7.1 stop at the same point, but get there MUCH faster. I started the AIX 5.3 make test even before I started the builds on AIX 6.1 and 7.1,

AIX 5.3 is still showing:
warning: if the text of an error message concerning `redir1.*' not being
warning: found or messages concerning bad file descriptors produce diff
warning: output, please do not consider it a test failure

while AIX 6.1 and AIX 7.1 have already "make error" status.

FYI (who really cares about AIX 5.3 these days :p )
Chet Ramey
2018-11-01 14:35:34 UTC
Permalink
Post by Chet Ramey
No, it's expected. That script tests the behavior when the process's open
file limit (`ulimit -n') is set to something very small.
2000
The script sets it very low (6) to test various failure modes.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU ***@case.edu http://tiswww.cwru.edu/~chet/
Chet Ramey
2018-10-31 19:24:56 UTC
Permalink
Post by Michael Felt
Hi,
I finally got around to patching and packaging bash-4.4.23 and had to
run a "make distclean" because I had copied the old version and without
the make distclean make kept looking for "bashversion" in the old path
.../bash-4.4.19/bashversion
The build directory is written to the Makefile so the build artifacts
(like bashversion) get removed from the right place. This is how you
support multiple build directories from a single source directory, for
instance.
Post by Michael Felt
This is just FYI - I'll install yacc, which is what make is complaining
about now - but I also wonder if I could have avoided this by trying to
build oot (out of tree). Is this supported, or even recommended?
You should install bison, not yacc, otherwise you'll run into problems
resulting from yacc's inability to support recursive parsers. And yes,
a build directory separate from the source directory is the recommended
configuration.
Post by Michael Felt
Thanks for a great product!
Thanks for your kind words.

Chet
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU ***@case.edu http://tiswww.cwru.edu/~chet/
Michael Felt
2018-11-01 10:43:22 UTC
Permalink
Post by Chet Ramey
Post by Michael Felt
Hi,
I finally got around to patching and packaging bash-4.4.23 and had to
run a "make distclean" because I had copied the old version and without
the make distclean make kept looking for "bashversion" in the old path
.../bash-4.4.19/bashversion
The build directory is written to the Makefile so the build artifacts
(like bashversion) get removed from the right place. This is how you
support multiple build directories from a single source directory, for
instance.
Post by Michael Felt
This is just FYI - I'll install yacc, which is what make is complaining
about now - but I also wonder if I could have avoided this by trying to
build oot (out of tree). Is this supported, or even recommended?
You should install bison, not yacc, otherwise you'll run into problems
resulting from yacc's inability to support recursive parsers. And yes,
a build directory separate from the source directory is the recommended
configuration.
If I "must", I shall build and install yacc. However, my hope is that:
a) I won't need either after I create a source-directory, and build oot
b) I prefer to work, as much as possible, from platform supplied tools.

Thanks for the extra info.
Post by Chet Ramey
Post by Michael Felt
Thanks for a great product!
Thanks for your kind words.
Chet
Loading...