GNOME Bugzilla – Bug 462877
chunking on woe32 not working, Makefile and configuration buggy
Last modified: 2007-08-17 09:58:36 UTC
Please describe the problem: xsltproc when built from the win32 subdir fails whit chunking, i.e. missing directories are not created. Instead there is an IO error message like the following: runtime error: file file:///C%3A/Programme/boost-book/docbook-xsl-1.73.0/html/chunker.xsl line 225 element document xsltDocumentElem: unable to save to html/bbv2/tutorial/hierarchy.html Writing bbv2/tutorial/libs.html for section(bbv2.tutorial.libs) I/O error : No such file or directory I/O error : No such file or directory Steps to reproduce: Sorry, I have no easy to paste example at hand. Actual results: Expected results: Does this happen every time? Yes. Other information: Index: win32/configure.js =================================================================== --- win32/configure.js (revision 3647) +++ win32/configure.js (working copy) @@ -565,8 +565,8 @@ } dirSep = "\\"; -if (compiler == "mingw") - dirSep = "/"; +//if (compiler == "mingw") +// dirSep = "/"; if (buildBinPrefix == "") buildBinPrefix = "$(PREFIX)" + dirSep + "bin"; if (buildIncPrefix == "") Index: win32/Makefile.mingw =================================================================== --- win32/Makefile.mingw (revision 3647) +++ win32/Makefile.mingw (working copy) @@ -237,33 +237,33 @@ utils : $(UTILS) clean : - cmd.exe /C if exist $(XML_INTDIR) rmdir /S /Q $(XML_INTDIR) - cmd.exe /C if exist $(XML_INTDIR_A) rmdir /S /Q $(XML_INTDIR_A) - cmd.exe /C if exist $(UTILS_INTDIR) rmdir /S /Q $(UTILS_INTDIR) - cmd.exe /C if exist $(BINDIR) rmdir /S /Q $(BINDIR) - cmd.exe /C if exist depends.mingw del depends.mingw + cmd.exe /C "if exist $(XML_INTDIR) rmdir /S /Q $(XML_INTDIR)" + cmd.exe /C "if exist $(XML_INTDIR_A) rmdir /S /Q $(XML_INTDIR_A)" + cmd.exe /C "if exist $(UTILS_INTDIR) rmdir /S /Q $(UTILS_INTDIR)" + cmd.exe /C "if exist $(BINDIR) rmdir /S /Q $(BINDIR)" + cmd.exe /C "if exist depends.mingw del depends.mingw" distclean : clean - cmd.exe /C if exist config.* del config.* - cmd.exe /C if exist Makefile del Makefile + cmd.exe /C "if exist config.* del config.*" + cmd.exe /C "if exist Makefile del Makefile" rebuild : clean all install-libs : all - cmd.exe /C if not exist $(INCPREFIX)\libxml mkdir $(INCPREFIX)\libxml - cmd.exe /C if not exist $(BINPREFIX) mkdir $(BINPREFIX) - cmd.exe /C if not exist $(LIBPREFIX) mkdir $(LIBPREFIX) - cmd.exe /C copy $(XML_SRCDIR)\include\libxml\*.h $(INCPREFIX)\libxml - cmd.exe /C copy $(BINDIR)\$(XML_SO) $(SOPREFIX) - cmd.exe /C copy $(BINDIR)\$(XML_A) $(LIBPREFIX) - cmd.exe /C copy $(BINDIR)\$(XML_IMP) $(LIBPREFIX) - cmd.exe /C copy $(BINDIR)\xml*.exe $(BINPREFIX) + cmd.exe /C "if not exist $(INCPREFIX)\libxml mkdir $(INCPREFIX)\libxml" + cmd.exe /C "if not exist $(BINPREFIX) mkdir $(BINPREFIX)" + cmd.exe /C "if not exist $(LIBPREFIX) mkdir $(LIBPREFIX)" + cmd.exe /C "copy $(XML_SRCDIR)\include\libxml\*.h $(INCPREFIX)\libxml" + cmd.exe /C "copy $(BINDIR)\$(XML_SO) $(SOPREFIX)" + cmd.exe /C "copy $(BINDIR)\$(XML_A) $(LIBPREFIX)" + cmd.exe /C "copy $(BINDIR)\$(XML_IMP) $(LIBPREFIX)" + cmd.exe /C "copy $(BINDIR)\xml*.exe $(BINPREFIX)" install : install-libs - cmd.exe /C copy $(BINDIR)\*.exe $(BINPREFIX) + cmd.exe /C "copy $(BINDIR)\*.exe $(BINPREFIX)" install-dist : install-libs - cmd.exe /C copy $(BINDIR)\xml*.exe $(BINPREFIX) + cmd.exe /C "copy $(BINDIR)\xml*.exe $(BINPREFIX)" # This is a target for me, to make a binary distribution. Not for the public use, # keep your hands off :-) Index: xmlIO.c =================================================================== --- xmlIO.c (revision 3647) +++ xmlIO.c (working copy) @@ -3503,7 +3503,8 @@ xmlRegisterDefaultInputCallbacks(); if (filename == NULL) return(NULL); -#if defined(WIN32) && !defined(__CYGWIN__) + +#if defined(_WIN32) && !defined(__CYGWIN__) && !defined(__MINGW32__) sep = '\\'; #endif
I applied a patch that will resolve the problem, and also render the build functional as is described in the README. (some quoting stuff and and \/ issues.) Please note, it was not me who worked out a solution to this bug. The origianal author is Aleksey Gurtovoy. http://mail.gnome.org/archives/xslt/2004-November/msg00030.html
The first patch I've sent was a little too short sighted. On windows both directory separators are valid: '/' and '\\'. So I changed the patch to take care of that. I discovered the problem on windows, with xsltproc, which uses the xmlParserGetDirectory function to check for validity. It passes a path, that has been parsed with xmlParseURI. This function converts the path to slashes ('/'). Of course xsltproc could be rewritten to use its own xmlParserGetDirectory. But on the other hand since both separators are valid on windows, the function IMHO should be able to honor this fact. I have attached a second patch that fixes some minor issues in the build and configuration scripts in the win32 directory. Roland
Created attachment 93226 [details] [review] fix '/' and '\' in xmlParserGetDirectory
Created attachment 93228 [details] [review] fix win32 build and configure scripts
(In reply to comment #2) > The first patch I've sent was a little too short sighted. > On windows both directory separators are valid: '/' and '\\'. > So I changed the patch to take care of that. . . . > I have attached a second patch that fixes some minor issues in the build > and configuration scripts in the win32 directory. This second patch is better, though I am still testing its effects in my build. No problems as of yet. I also had hit a problem here, but if I still remember correctly, it was related to memory parsing and external entity loading when setting the directory on the context. For some reason I had needed to set the canonical form for the directory, and am trying to find a case to see if this would still be a problem or not.
Rob, as you know, I don't have any Win build environment, so I rely on you (or the mailing-list) to tell me when this is fine for commit. Actually, commit it yourself when ready :-) Daniel
Created attachment 93588 [details] [review] Don't go below drive letter on windows. I possibly posted the (improved) patch to the wrong place (xsltproc bug# 464432). So I am duplicating it here. This patch now will test for ':' in the 2'nd position and report this as root directory, not going below. Anyhow, the semantics of the overall function is somewhat questionable to me since it is not evident if one is allowed to pass '.', '..' also. Passing '..' will result in questionable directory anyways.
Previous patch was used (http://bugzilla.gnome.org/attachment.cgi?id=93226&action=view) as latest can cause infinite loop condition with invalid drive as well as it returns inconsistent paths (some with trailing slash and some without).
I might be blind, but I cannot see the infinite loop condition. Would you please be so kind to explain? The trailing slash problem I can see. This could be easily addressed with else if ((cur == dir+2)&&(dir[1]==':')) dir[2] = 0; Roland aka speedsnail
The trailing slash problem is resolved by not even including the check as the behavior is now consistent. The infinite loop condition would have been caused by usage of the function. For the path pass in something like W:\file.xml (using the libxslt bug associated with this one (http://bugzilla.gnome.org/show_bug.cgi?id=464432) where the machine doesn't have a W drive. The directory gets passed back as W:\ (with the trailing slash), xsltCheckFilename returns 0 causing W:\ to get passed to xmlParserGetDirectory again, returning W:\ again and thus the condition. While the example I used is limited in scope to libxslt (where logic could be changed), the change would have introduced a good possibility of breaking apps using that functionality.