Hi,
Thanks for your information. Very appreciated!
When I convert the file as encoded as UTF-8, there will be no errors.
For my understanding, if the file is encoded as UTF-8, the first 3 bytes will be "efbbbf".
Maybe the cvs get the file only as ASCII format.
Now, the 3rdpart libxml and libxslt, zlib,iconv can support the debug version building.
The latest openssl installation image seems to be built with vs2008.
So I downgraded the building with vc6.
Besides this, ossp-uuid seems very hard to find a win32 build version. Is there comment int the wiki?
2008/10/8 Magnus Hagander
<magnus@hagander.net>iihero wrote:
> Thanks. Now the header file include issues resolved. I fetch the latest
> code and no such issues.
>
> But I found new issues now. (the latest code from cvs)
> 1. file : contrib\fuzzystrmatch\dmetaphone.c,
> line: 1040 and line: 464, both look like as below,
> case '?:
> There is no the matched single quote, and the content is repeated.
> This cause build always failed for fuzzystrmatch.
Looks like an encoding error. I think that file has UTF-8 in it at that
location. but it's strange that it fails for you and not for any of the
machines on the buildfarm. Have you done "something strange" to this
file, like opened it up in a non-UTF8 text editor and saved it again?
If not, perhaps your cvs somehow broke it - try one of source snapshot
files from the ftp site to see if that makes a difference.
IIRC, Visual C++ compiles UTF8 source code just fine, so it should work.
> 2. I can't find the debug version libraries of libxml and libxslt, zlib,
> iconv. And failed to build it on windows platform respectively.
> Thus I can't build the debug version of postgresql8.4dev.
You should not need the debug version of these to build the debug
version of PostgreSQL.
> Could the depend libraries (release and debug version) and header files
> be tar balled in a place?
Well, we've left distribution of these parts off to the original
projects, so that we don't need to maintain even more stuff than we
already have to do around the Windows port. If someone volunteers to
maintain such a package I'm sure we can find a location to do it, though...
//Magnus
