"Simon Wing-Tang" <[EMAIL PROTECTED]> writes: > I've just completed a test after altering one part of the source > code for tempname.c ( lib/tempname.c ) as follows.... > Original: ... > 271 case __GT_FILE: > 272 fd = __open (tmpl, O_RDWR | O_CREAT | O_EXCL, S_IRUSR | > S_IWUSR); > ... > Modified: ... > 271 case __GT_FILE: > 272 fd = __open64 (tmpl, O_RDWR | O_CREAT | O_EXCL, S_IRUSR | > S_IWUSR);
> After a recompile the sort worked Thanks for the bug report and the detailed investigation. However, I don't understand why your fix worked, because the lines that you mentioned are preceded by these lines in tempname.c: 75 # define __open open 76 # define __open64 open so it should make no difference on your platform whether __open or __open64 is used. Since I don't know why your change worked, I'm not convinced that we actually understand the bug yet. It could well be that the bug will come up again in some other 'sort' run. Can you please investigate why the #define's did not work as one would expect? For example, what is the preprocessor output (cc -E) for tempname.c? Are the symbols __open and/or __open64 defined in HP-UX's headers? Also, can you please investigate why coreutils is compiling tempname.c at all? Coreutils does so only if it concludes that the system mkstemp has stupid limitations (e.g., mkstemp cannot create more than 26 files from a given template). HP-UX 10.20 had such a problem, but is this limitation still present in HP-UX 11.11i? If not, we need to fix m4/mkstemp.m4 so that it no longer builds a substitute mkstemp on your platform. You can look at config.log to see why the build decided that mkstemp was broken. Thanks. _______________________________________________ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
