Обсуждение: About postgresql8.3.3 build in MS VS2005

Are you building with MS VS2005 Express? If so, it sounds like you have
not managed to install the Platform SDK properly.

//Magnus


iihero wrote:
> When I build pgsql via perl after run the command line env of VS2005,
> there are lots of following error:
>  
>  
> 
>       
> e:\learn\db_research\postgresql\source\postgresql-8.3.3\src\include\port
> .h(83): error C2146: syntax error : missing ')' before identifier 'hProcess'
>       
> e:\learn\db_research\postgresql\source\postgresql-8.3.3\src\include\port
> .h(83): error C2061: syntax error : identifier 'hProcess'
>       
> e:\learn\db_research\postgresql\source\postgresql-8.3.3\src\include\port
> .h(83): error C2059: syntax error : ')'
>       
> e:\learn\db_research\postgreSQL\source\postgresql-8.3.3\src\include\misc
> dmin.h(124): error C2061: syntax error : identifier 'PostmasterPid'
>       
> e:\learn\db_research\postgreSQL\source\postgresql-8.3.3\src\include\misc
>  
>  
> Any help?
>  
> The config.pl content under src\tools\msvc\  in my machine is like:
>  
> # Configuration arguments for vcbuild.
> use strict;
> use warnings;
> our $config = {
>     asserts=>0,   # --enable-cassert
>     integer_datetimes=>0,   # --enable-integer-datetimes
>     nls=>undef,    # --enable-nls=<path>
>     tcl=>undef, #'c:\tcl',  # --with-tls=<path>
>     perl=>'d:\tools\perl',    # --with-perl
>     python=>'D:\program\python235', # --with-python=<path>
>    
> krb5=>'E:\learn\db_research\postgreSQL\coding\depend\kfw-3-2-2-final', #
> --with-krb5=<path>
>     ldap=>1,   # --with-ldap
>     openssl=>'E:\learn\db_research\postgreSQL\coding\depend\openssl', #
> --with-ssl=<path>
>     uuid=>undef,
> #'E:\learn\db_research\postgreSQL\coding\depend\ossp-uuid',
> #--with-ossp-uuid
>     xml=>'E:\learn\db_research\postgreSQL\coding\depend\libxml2',
>     xslt=>'E:\learn\db_research\postgreSQL\coding\depend\libxslt',
>     iconv=>'E:\learn\db_research\postgreSQL\coding\depend\iconv',
>     zlib=>'E:\learn\db_research\postgreSQL\coding\depend\zlib'#
> --with-zlib=<path>
> };
> 1;

it could be. At first look ISTM that the error comes from not finding
the definition of HANDLE, which is certainly very central to the
Platform SDK.

//Magnus

iihero wrote:
> Thanks Magnus,
>  
> I've installed vs2005 standard edition.
> Do you mean the include order of Platform SDK possibly influenced the
> build result?
>  
> 
>  
> 2008/10/6 Magnus Hagander <magnus@hagander.net <mailto:magnus@hagander.net>>
> 
>     Are you building with MS VS2005 Express? If so, it sounds like you have
>     not managed to install the Platform SDK properly.
> 
>     //Magnus
> 
> 
>     iihero wrote:
>     > When I build pgsql via perl after run the command line env of VS2005,
>     > there are lots of following error:
>     >
>     >
>     >
>     >
>     >
>     e:\learn\db_research\postgresql\source\postgresql-8.3.3\src\include\port
>     > .h(83): error C2146: syntax error : missing ')' before identifier
>     'hProcess'
>     >
>     >
>     e:\learn\db_research\postgresql\source\postgresql-8.3.3\src\include\port
>     > .h(83): error C2061: syntax error : identifier 'hProcess'
>     >
>     >
>     e:\learn\db_research\postgresql\source\postgresql-8.3.3\src\include\port
>     > .h(83): error C2059: syntax error : ')'
>     >
>     >
>     e:\learn\db_research\postgreSQL\source\postgresql-8.3.3\src\include\misc
>     > dmin.h(124): error C2061: syntax error : identifier 'PostmasterPid'
>     >
>     >
>     e:\learn\db_research\postgreSQL\source\postgresql-8.3.3\src\include\misc
>     >
>     >
>     > Any help?
>     >
>     > The config.pl content under src\tools\msvc\  in my machine is like:
>     >
>     > # Configuration arguments for vcbuild.
>     > use strict;
>     > use warnings;
>     > our $config = {
>     >     asserts=>0,   # --enable-cassert
>     >     integer_datetimes=>0,   # --enable-integer-datetimes
>     >     nls=>undef,    # --enable-nls=<path>
>     >     tcl=>undef, #'c:\tcl',  # --with-tls=<path>
>     >     perl=>'d:\tools\perl',    # --with-perl
>     >     python=>'D:\program\python235', # --with-python=<path>
>     >
>     >
>     krb5=>'E:\learn\db_research\postgreSQL\coding\depend\kfw-3-2-2-final', #
>     > --with-krb5=<path>
>     >     ldap=>1,   # --with-ldap
>     >    
>     openssl=>'E:\learn\db_research\postgreSQL\coding\depend\openssl', #
>     > --with-ssl=<path>
>     >     uuid=>undef,
>     > #'E:\learn\db_research\postgreSQL\coding\depend\ossp-uuid',
>     > #--with-ossp-uuid
>     >     xml=>'E:\learn\db_research\postgreSQL\coding\depend\libxml2',
>     >     xslt=>'E:\learn\db_research\postgreSQL\coding\depend\libxslt',
>     >     iconv=>'E:\learn\db_research\postgreSQL\coding\depend\iconv',
>     >     zlib=>'E:\learn\db_research\postgreSQL\coding\depend\zlib'#
>     > --with-zlib=<path>
>     > };
>     > 1;
> 
> 

Magnus Hagander <magnus@hagander.net> writes:
>> Do you mean the include order of Platform SDK possibly influenced the
>> build result?

> it could be. At first look ISTM that the error comes from not finding
> the definition of HANDLE, which is certainly very central to the
> Platform SDK.

You should be looking at the first few errors.  I'm suspicious that a
system include file isn't being found where expected.  Some compilers
will bull ahead anyway, but a huge number of consequent errors can be
expected if the needed declarations haven't been read ...
        regards, tom lane

iihero <iihero@gmail.com> writes:
> 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.

Huh, interesting.  Looking at these lines in a strict-C-locale editor,
I see
        case '\307':        case '\321':

(Emacs is rendering single-byte characters as backslash sequences.)
It appears to me that the code author was using Latin-1 and that these
characters are meant to be C-with-cedilla and N-with-tilde respectively.
It's not entirely surprising that a C compiler thinking the source file
was in UTF-8 would spit up.

We could trivially change the code to be more portable by spelling out
the characters as backslash escapes (ie, make it as I wrote above rather
than what's really there).  But that's just ignoring the real problem,
which is that this code is completely broken in any database encoding
other than Latin-1.  Not sure what to do about that.  It doesn't look
like it'd be easy to adapt the code for multibyte operation ... and
personally I don't care enough about metaphone to put much work into it.
Anyone want to have a stab at it?
        regards, tom lane

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

Magnus Hagander <magnus@hagander.net> writes:
> IIRC, Visual C++ compiles UTF8 source code just fine, so it should work.

The problem is that what's in our CVS is Latin-1.  I'm not quite sure
why the OP's compiler is expecting it to be UTF-8, but it's pretty
obvious what's going to happen if it does expect that.
        regards, tom lane

iihero wrote:
> 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".

No, this is not necessary. That's the BOM (Byte Order Mark), but it's
not mandatory. Many editors on Windows put it there, most (I think)
editors on other platforms don't.

> Besides this, ossp-uuid seems very hard to find a win32 build version.
> Is there comment int the wiki?
> I just find one in the mail list, which says that there is one at
> 
> http://winpg.jp/~saito/pg_work/OSSP_win32/

There has been a lot of issues with that one. I don't know if there has
been a release of the fixed version - I know Hiroshi Saito worked with
them to get the fix into their tree, just not if it's been released yet.

//Magnus

Hiroshi's ossp-uuid build is the latest win32 build, and what we
shipped with 8.3.4.

On 10/11/08, Magnus Hagander <magnus@hagander.net> wrote:
> iihero wrote:
>> 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".
>
> No, this is not necessary. That's the BOM (Byte Order Mark), but it's
> not mandatory. Many editors on Windows put it there, most (I think)
> editors on other platforms don't.
>
>> Besides this, ossp-uuid seems very hard to find a win32 build version.
>> Is there comment int the wiki?
>> I just find one in the mail list, which says that there is one at
>>
>> http://winpg.jp/~saito/pg_work/OSSP_win32/
>
> There has been a lot of issues with that one. I don't know if there has
> been a release of the fixed version - I know Hiroshi Saito worked with
> them to get the fix into their tree, just not if it's been released yet.
>
> //Magnus
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>


-- 
Dave Page
EnterpriseDB UK:   http://www.enterprisedb.com