Hi Paul,
Sorry for late reply and thank you so much for checking into the problem. Comments added below. Thanks, Kelly If you need support for DevX Tools: http://devxsupport.cisco.com/ Specifically, for NXOS, see - https://wiki.cisco.com/display/NEXUSPMO/ContactingNexusOpsAndTools On 10/22/20, 3:04 PM, "Paul Eggert" <egg...@cs.ucla.edu> wrote: On 10/21/20 7:36 AM, Thien-Thi Nguyen wrote: > "Kelly Wang (kellythw)" <kelly...@cisco.com> <https://lists.gnu.org/r/bug-rcs/2020-10/msg00018.html> > I download rcs 5.10.0, untarred and try to run ./configure. > However it is hang in 'checking whether getcwd handles long > file names properly...' for more than 30+ min and still hang. > This is from ‘gl_FUNC_GETCWD_PATH_MAX’ in m4/getcwd-path-max.m4. > IIUC, the test tries to create a filename up to, and then a bit > longer than, PATH_MAX in length. It does this in a ‘while (1)’ > loop, relying on ‘break’ to exit the loop. Perhaps this is a C > compiler problem? I'd guess that it's due to thrashing, e.g., there's a huge PATH_MAX or something like that. At any rate, it's surely a Gnulib problem rather than an RCS problem so I'll cc. this to bug-gnulib. Kelly, I created the attached tarball getcwd-test.tar.gz by running './gnulib-tool --create-testdir --dir getcwd-test getcwd' in the Gnulib source directory. Please try: tar xf getcwd-test.tar.gz cd getcwd-test ./configure [Kelly] yes, it hanged in the similar way as rcs. make check in the same filesystem where you tried and failed to build RCS. If it hangs in a similar way while running 'configure', it's a Gnulib problem. If it succeeds then something odd is going on and it may be either a Gnulib or RCS problem. Assuming it hangs, leave it hanging but look at the working directory. You should see a file conftest.c that looks like the attached separate file. Let us know of any differences between your conftest.c and the attached one. Also, try the following commands: gcc conftest.c strace -o tr ./a.out The strace should also hang so you may need to type control-C to exit it after a while. Look at the resulting 'tr' file and compare it to the attached compressed file tr.gz. Where does yours start acting differently? That will help us figure out the bug. [Kelly] strace step is not hang and I have tr generated. [Kelly] The difference of tr output start at: openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libc.so.6", O_RDONLY|O_CLOEXEC) = 3 ==> output from yours openat(AT_FDCWD, "/lib64/libc.so.6", O_RDONLY|O_CLOEXEC) = 3 ==> my output I attached a.out and tz, so is that mean the lib file that my machine used has problem?
a.out
Description: a.out
tr
Description: tr
