Okay, I dug thru the glibc 2.11 manual - there doesn't appear to be any problem here in the code itself.
The problem instead, I believe, is caused by your system not supporting pty's, yet you are trying to use them. In this case, tcgetattr will return errno 22 because the file descriptor is not pointing to a correct terminal. Try configuring with --disable-pty-support and see if that fixes the problem. BTW: what system are you running this on? On Mar 9, 2010, at 4:34 PM, Lasse Kliemann wrote: > Alas, I am by far no Glibc expert. I did a grep through the Glibc > changelog, but only found a reference to tcgetattr from 2006. > > Of course, I would also like to see a real solution here instead > of ignoring the error condition. > > * Message by -Ralph Castain- from Tue 2010-03-09: >> Ignoring an error doesn't seem like a good idea. The real >> question is why we are getting that error - it sounds like the >> newest Glibc release has changed the API?? Can you send us the >> revised one so we can put in a test and use the correct API for >> the installed version? >> >> >> On Mar 9, 2010, at 9:40 AM, Lasse Kliemann wrote: >> >>> $ mpirun -n 1 ls >>> -------------------------------------------------------------------------- >>> mpirun was unable to launch the specified application as it encountered an >>> error: >>> >>> Error: pipe function call failed when setting up I/O forwarding subsystem >>> Node: xxxxx.xxxxxxxxxx.xxxxxxxx.xx >>> >>> while attempting to start process rank 0. >>> -------------------------------------------------------------------------- >>> >>> I receive this error constantly. I tracked it down so far that it >>> appears now certain that the 'tcgetattr' and 'tcsetattr' calls in >>> 'orte/mca/iof/base/iof_base_setup.c' are responsible. 'errno' is >>> set to 22 each, which means 'invalid argument'. We can simply >>> ignore the return values of these calls and continue, as done in >>> the attached patch. Some simple tests suggest that everything >>> else is fine, but I haven't tested thoroughly yet. >>> >>> On another system, this problem is absent. The main difference >>> are GCC and Glibc versions. The problematic system uses GCC 4.3.4 >>> and Glibc 2.11.1 -- which is the newest Glibc release and maybe >>> untested yet with OpenMPI. >>> >>> Let me know which additional information I can provide to further >>> analyze this issue. > _______________________________________________ > users mailing list > us...@open-mpi.org > http://www.open-mpi.org/mailman/listinfo.cgi/users
