Re: [xml] New battle in Porting LibXML & LibXSLT to DJGPP: file read error


the recently introduced Windows path normalisation is what gives you headaches. You are right, every Windows path is being converted to an URI before processing. That alone is not a problem for you, but the fact that all paths are being slashified is the source of your pain.

'file://' URIs are not loaded via the sockets library, but via the C runtime IO, just like before. What your runtime sees now is "/D:/D/xml/test.xml", means slashes instead of backslashes. Windows C runtime doesn't care if it's a slash or a backslash, but yours on DOS appearantly does.

Modify the function xmlNormalizeWindowsPath in xmlIO.c and have it simply call xmlStrdup. Does that fix your problem?

Note that few other common cases will fail without the xmlNormalizeWindowsPath processing. For example, you cannot specify a relative path anymore:

  C:\> xsltproc ..\bar.xsl foo.xml

will not work without slashification, that is the reason why it was introduced.


Ben Decker wrote:

It appears that something has changed for the worse (when tring to build on DJGPP on MSDOS) with the latest sources (I downloaded the CVS release two days ago). The package built fine, but none of the programs run anymore (xmllint, xsltproc, etc)

They all return the same error:
warning: failed to load external entity "file:///D:/D/xml/test.xml"

... or similar.

I have tried a few tricks in the sources but nothing works. Seems that filenames are now converted to URL before reading. If it is then trying to do the actual URL loading via the local socket library, it will cause big problems on DJGPP. It looks like possible code rewrite?? The latest *working* LibXML on DJGPP I have is 20422. There might have been still many more since then, but I know that the newest CVS release has this new error.


BA flight sale now at
New York, £129 rtn. including tax, Friday, 2pm

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]