I ran into this issue when running tests for the MacPorts port of oath-toolkit
(https://ports.macports.org/port/oath-toolkit/) on Mac OS 10.14.6. I don't know
the specific reason, but it seems like the test process inherits a lot of open
files from its parent, as the actual fd returned by fcntl
Hi,
Nicholas Gaya wrote:
> fd 10 is already in use (which happens to be the case in the testing
> environment where I ran into this bug)
3 questions:
1) What is this environment that leaves fd 10 open when it starts a process?
2) For which purpose does it use this fd?
3) What would happen if we c
Hello,
I believe I have found a bug in gnulib's test-fcntl.c. In order to test the
functionality of fcntl with FD_DUPFD_CLOEXEC, the test dups an open file
descriptor using the flag and execs a child process to check that the file
descriptor gets closed on exec. The problem is that the current
Eric Blake writes:
> It was pointed out to me that for multiple years, m4's
> 'm4-latest.tar.XX' links were out of date at https://ftp.gnu.org/gnu/m4/
> - the links were created in in 2013 when I released m4-1.4.17, but never
> updated in 2016 when I released m4-1.4.18.
>
> I managed to fix the l
It was pointed out to me that for multiple years, m4's
'm4-latest.tar.XX' links were out of date at https://ftp.gnu.org/gnu/m4/
- the links were created in in 2013 when I released m4-1.4.17, but never
updated in 2016 when I released m4-1.4.18.
I managed to fix the latest links today with:
$ build