Apache OpenOffice (AOO) Bugzilla – Issue 47135
[PATCH] Provide sensible _POSIX_NAME_MAX value for Win32
Last modified: 2013-08-07 15:34:52 UTC
The current dmake in cws_src680_dmake43p01 doesn't quite build perl out-of-the-box on Win32. The build falls over on the file ext/B/Disassembler.pm because the filename length there exceeds dmake's value of _POSIX_NAME_MAX (12). The patch below uses the value _MAX_FNAME instead, which is defined as 256 in <stdlib.h> in MSVC++: diff -ruN dmake.orig/win95/microsft/sysintf.h dmake/win95/microsft/sysintf.h --- dmake.orig/win95/microsft/sysintf.h 2000-09-22 16:33:38.000000000 +0100 +++ dmake/win95/microsft/sysintf.h 2005-04-11 09:46:05.050169100 +0100 @@ -50,7 +50,7 @@ #ifdef _POSIX_NAME_MAX #undef _POSIX_NAME_MAX #endif -#define _POSIX_NAME_MAX 12 +#define _POSIX_NAME_MAX _MAX_FNAME #ifdef _POSIX_PATH_MAX #undef _POSIX_PATH_MAX End of Patch. The patch only changes the value in the one file involved when building via "make win95-vpp40". The following other files also define _POSIX_NAME_MAX to 12, and it may be appropriate to change them in some way too, but I am unable to verify that _MAX_FNAME is available in all the build targets concerned: dmake/msdos/sysintf.h dmake/os2/sysintf.h dmake/win95/borland/sysintf.h dmake/winnt/borland/sysintf.h dmake/winnt/microsft/sysintf.h dmake/winnt/mingw/sysintf.h dmake/winnt/msvc6/sysintf.h
Created attachment 24959 [details] Improved patch affecting _POSIX_PATH_MAX too, and for four different targets
The previous patch uses _MAX_PATH for _POSIX_PATH_MAX too, and applies the changes for four different OS's, as per issue 47137. This definitely works fine using VC++ (6.0), and I believe that Borland also has these constants because a previous binary build of dmake that was put on CPAN made use of them and was built using Borland (http://search.cpan.org/~gsar/dmake-4.1pl1-win32/).
I'm really surprised that the OOo build didn't trigger this error!
I was curious and tried to reproduce the problem, but I couldn't. You can actually set the NAMEMAX macro (not .NAMEMAX macro as the man page says) to a very small value and provoke the problem. But besides that if you switch off the .DIRCACHE a file that is longer than NAMEMAX is treated as having timestamp 0 (old) and therefore always build I couldn't produce something that really fails. Can you give an example? P.S.: I'm going to commit your patch, but I'm curious to see what might fail.
I just found this change in the OOo dmake sources: <http://tools.openoffice.org/source/browse/tools/dmake/posix.h?r1=1.1.1.1&r2=1.1.1.1.30.1> I must say that looks like a big hammer ;) for a small problem, but it is there since over two years, so it must have solved the problem for you. I committed your patch, but I'm still curious about the problem. Can you give me an example of the problem? For the OOo dmake version you can achieve the effect of a to small value of _POSIX_NAME_MAX by setting NAMEMAX:=5 or so in your startup.mk. P.S.: For windows builds the value of .DIRCACHE or the -d flag are practically ignored, but if the directory cache is "enabled" that basically means that the check if the filename is longer than NameMax is disabled in sysintf.c.
Created attachment 25188 [details] Warn it NAMEMAX is to small
Sorry for the delay in replying to this issue. I've been trying to reproduce the error which originally caused me to suggest these changes, but I've been unable to do so :( I didn't dream it up: I distinctly recall the perl build falling over on ext/B/Disassembler.pm, then changing _POSIX_NAME_MAX and retrying (with success), but I can't make it happen now. The posix.h change that you found may very well have fixed it, in which case all I can think is that maybe I was using the old dmake 4.1 code (not from OOo) when I experienced the error. The main thing is that it's all working now :)
Added a comment about the clobbering in posix.h.
iz47135.diff was also committed. vq->hjs: Please verify.
.