Thread: Re: [BUGS] WIN32 Non Blocking
> I think we are in great shape now. Thanks. The elog() problem was > because they didn't define FRONTEND in the compile. > > -- > Bruce Momjian | http://candle.pha.pa.us > pgman@candle.pha.pa.us | (610) 853-3000 > + If your life is a hard drive, | 830 Blythe Avenue > + Christ can be your backup. | Drexel Hill, Pennsylvania 19026 I start to dig little bit further and tried to compile WIN32 with MULTIBYTE support. There are also a few simple problems. In src/include/miscadmin.h there is declared external function GetUserName. Under WIN32 there is already declared that function in winbase.h Description from MSDN: BOOL GetUserName( LPTSTR lpBuffer, // address of name buffer LPDWORD nSize // address of size of name buffer ); The GetUserName function retrieves the user name of the current thread. This is the name of the user currently logged onto the system. Fortunately Compiler reports error because function arguments are not the same. These two functions are not the same at all !!! I think that this header should not be imported in libpq at all, or should be imported only some parts, I'm not for shore yet. Just to make it work I only disabled GetUserName using WIN32 compiler constant. Is there maybe some other compiler constant that means that we are compiling client library, or should I use FRONTEND compiler constant ? Compilation after this, and few corrections in win32.h and win32.mak passed ok, but now I have another problem. When I tried to test libpq.dll by setting client encoding, I end up with this error message from server : "Client Encoding LATIN1 is not supported !" I think that my server is compiled without MULTIBYTE, because it also reports error when I try to CREATE DATABASE WITH ENCODING. Should I be shamed to confess that I do not know how to re-compile under Linux ? So, I first must read the installation manuals or wait for our "Linux-Man" that returns to work in Monday ! However I'll send you a note as soon as some testing is done ! Darko.Prenosil@finteh.hr _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com
Do we have a fix for this? It is a WIN32/libpq/multibyte problem. > > > I think we are in great shape now. Thanks. The elog() problem was > > because they didn't define FRONTEND in the compile. > > > > -- > > Bruce Momjian | http://candle.pha.pa.us > > pgman@candle.pha.pa.us | (610) 853-3000 > > + If your life is a hard drive, | 830 Blythe Avenue > > + Christ can be your backup. | Drexel Hill, Pennsylvania 19026 > > I start to dig little bit further and tried to compile WIN32 with MULTIBYTE > support. > There are also a few simple problems. > In src/include/miscadmin.h there is declared external function GetUserName. > > Under WIN32 there is already declared that function in winbase.h > > Description from MSDN: > > BOOL GetUserName( > LPTSTR lpBuffer, // address of name buffer > LPDWORD nSize // address of size of name buffer > ); > The GetUserName function retrieves the user name of the current thread. This > is the name of the user currently logged onto the system. > > > Fortunately Compiler reports error because function arguments are not the > same. > These two functions are not the same at all !!! > I think that this header should not be imported in libpq at all, or should > be > imported only some parts, I'm not for shore yet. > Just to make it work I only disabled GetUserName using WIN32 compiler > constant. > Is there maybe some other compiler constant that means that we are compiling > client library, or should I use FRONTEND compiler constant ? > > Compilation after this, and few corrections in win32.h and win32.mak passed > ok, > but now I have another problem. When I tried to test libpq.dll by setting > client encoding, I end up with this error message from server : > > "Client Encoding LATIN1 is not supported !" > > I think that my server is compiled without MULTIBYTE, because it also > reports error > when I try to CREATE DATABASE WITH ENCODING. > Should I be shamed to confess that I do not know how to re-compile under > Linux ? > So, I first must read the installation manuals or wait for our "Linux-Man" > that returns to work in Monday ! > > However I'll send you a note as soon as some testing is done ! > > Darko.Prenosil@finteh.hr > > > > _________________________________________________________ > Do You Yahoo!? > Get your free @yahoo.com address at http://mail.yahoo.com > > -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Do we have a fix for this? It is a WIN32/libpq/multibyte problem.
AFAIK it's all fixed (barring new bug reports ;-)). The main problems
were (a) win32.mak hadn't gotten updated when we changed the set of
backend source files that are included into libpq for MULTIBYTE;
(b) win32.mak failed to define FRONTEND, (c) someone had incorrectly
added
#ifndef WIN32
int optval;
#else
char optval;
#endif
upon noting that his Windows compiler griped about
if (getsockopt(conn->sock, SOL_SOCKET, SO_ERROR,
&optval, &optlen) == -1)
instead of realizing that the correct fix is
if (getsockopt(conn->sock, SOL_SOCKET, SO_ERROR,
(char *) &optval, &optlen) == -1)
(a) is new in 7.1 but the other bugs go back at least to 7.0.
regards, tom lane
Great. Glad to have these Win32 things done. > Bruce Momjian <pgman@candle.pha.pa.us> writes: > > Do we have a fix for this? It is a WIN32/libpq/multibyte problem. > > AFAIK it's all fixed (barring new bug reports ;-)). The main problems > were (a) win32.mak hadn't gotten updated when we changed the set of > backend source files that are included into libpq for MULTIBYTE; > (b) win32.mak failed to define FRONTEND, (c) someone had incorrectly > added > > #ifndef WIN32 > int optval; > #else > char optval; > #endif > > upon noting that his Windows compiler griped about > > if (getsockopt(conn->sock, SOL_SOCKET, SO_ERROR, > &optval, &optlen) == -1) > > instead of realizing that the correct fix is > > if (getsockopt(conn->sock, SOL_SOCKET, SO_ERROR, > (char *) &optval, &optlen) == -1) > > (a) is new in 7.1 but the other bugs go back at least to 7.0. > > regards, tom lane > -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026