strerror_r int and char* return type mixup on FC2
Hi,
I noticed that there where strange symbols in the error message when I
can't connect to a database.
This happends in PHP and pgsql and in the 7.4.x and 8.0 version of
postgesql
in pqStrError there is a 'if def' for 'char*' and 'int' return type
strerror_r.
I'm have FC2 linux. This version has a 'int' return type strerror_r and
not char*
I think the build system doesn't detect the return type of strerror_r
correctly and is not using
the STRERROR_R_INT but the 'char*' part.
This happends in 7.4.x(wich is the offical FC2 release) and mine own
build 8.0. The libc
version is the default 2.3.3
Is this problem known?
According config.log i have build 8.0 with the following swiches:
./configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --enable-shared --enable-thre
ads=posix --disable-checking --disable-libunwind-exceptions
--with-system-zlib --enable-__cxa_atexit --host=i386-redhat-linux
Regards
Jeroen
Jeroen van Iddekinge wrote:
Hi,
I noticed that there where strange symbols in the error message when I
can't connect to a database.
This happends in PHP and pgsql and in the 7.4.x and 8.0 version of
postgesqlin pqStrError there is a 'if def' for 'char*' and 'int' return type
strerror_r.
I'm have FC2 linux. This version has a 'int' return type strerror_r and
not char*
I think the build system doesn't detect the return type of strerror_r
correctly and is not using
the STRERROR_R_INT but the 'char*' part.This happends in 7.4.x(wich is the offical FC2 release) and mine own
build 8.0. The libc
version is the default 2.3.3
Is this problem known?According config.log i have build 8.0 with the following swiches:
./configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --enable-shared --enable-thre
ads=posix --disable-checking --disable-libunwind-exceptions
--with-system-zlib --enable-__cxa_atexit --host=i386-redhat-linux
Uh, I don't think that is a PostgreSQL config build. I don't recognize
many of those flags but I know you can pass flags it doesn't understand
so maybe it is.
The problem you are seeing is generated by the client libpq library, not
by the server. Are you testing against an 8.0 server or client? You
need to use an 8.0 client libpq library. You are correct the 7.4.X
libpq client didn't handle the case you describe.
If you are using an 8.0 client library, check the three STRERROR defines
in src/include/pg_config.h after you run configure. Particularly your
STRERROR_R_INT should be defined and not undefined.
Please report back. Thanks.
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
Jeroen van Iddekinge wrote:
Thanks for the reply,
I have 7.4.7 and 8.0.0 both installed , so I din't noticed that i was
using 7.4.7 client.
8.0.0 works fine
OK, thanks for the report.
---------------------------------------------------------------------------
Thanks
Jeroen
Jeroen van Iddekinge wrote:
Hi,
I noticed that there where strange symbols in the error message when I
can't connect to a database.
This happends in PHP and pgsql and in the 7.4.x and 8.0 version of
postgesqlin pqStrError there is a 'if def' for 'char*' and 'int' return type
strerror_r.
I'm have FC2 linux. This version has a 'int' return type strerror_r and
not char*
I think the build system doesn't detect the return type of strerror_r
correctly and is not using
the STRERROR_R_INT but the 'char*' part.This happends in 7.4.x(wich is the offical FC2 release) and mine own
build 8.0. The libc
version is the default 2.3.3
Is this problem known?According config.log i have build 8.0 with the following swiches:
./configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --enable-shared --enable-thre
ads=posix --disable-checking --disable-libunwind-exceptions
--with-system-zlib --enable-__cxa_atexit --host=i386-redhat-linuxUh, I don't think that is a PostgreSQL config build. I don't recognize
many of those flags but I know you can pass flags it doesn't understand
so maybe it is.The problem you are seeing is generated by the client libpq library, not
by the server. Are you testing against an 8.0 server or client? You
need to use an 8.0 client libpq library. You are correct the 7.4.X
libpq client didn't handle the case you describe.If you are using an 8.0 client library, check the three STRERROR defines
in src/include/pg_config.h after you run configure. Particularly your
STRERROR_R_INT should be defined and not undefined.Please report back. Thanks.
---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
Import Notes
Reply to msg id not found: 420F9A10.8060405@lycos.com | Resolved by subject fallback
Thanks for the reply,
I have 7.4.7 and 8.0.0 both installed , so I din't noticed that i was
using 7.4.7 client.
8.0.0 works fine
Thanks
Jeroen
Show quoted text
Jeroen van Iddekinge wrote:
Hi,
I noticed that there where strange symbols in the error message when I
can't connect to a database.
This happends in PHP and pgsql and in the 7.4.x and 8.0 version of
postgesqlin pqStrError there is a 'if def' for 'char*' and 'int' return type
strerror_r.
I'm have FC2 linux. This version has a 'int' return type strerror_r and
not char*
I think the build system doesn't detect the return type of strerror_r
correctly and is not using
the STRERROR_R_INT but the 'char*' part.This happends in 7.4.x(wich is the offical FC2 release) and mine own
build 8.0. The libc
version is the default 2.3.3
Is this problem known?According config.log i have build 8.0 with the following swiches:
./configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --enable-shared --enable-thre
ads=posix --disable-checking --disable-libunwind-exceptions
--with-system-zlib --enable-__cxa_atexit --host=i386-redhat-linuxUh, I don't think that is a PostgreSQL config build. I don't recognize
many of those flags but I know you can pass flags it doesn't understand
so maybe it is.The problem you are seeing is generated by the client libpq library, not
by the server. Are you testing against an 8.0 server or client? You
need to use an 8.0 client libpq library. You are correct the 7.4.X
libpq client didn't handle the case you describe.If you are using an 8.0 client library, check the three STRERROR defines
in src/include/pg_config.h after you run configure. Particularly your
STRERROR_R_INT should be defined and not undefined.Please report back. Thanks.