08.04.0100 build error on Fedora 11

Hi,

I'm getting the message below on Fedora 11, which has unixODBC 2.2.14 and gcc 4.4.0:

===============================================================================================
/bin/sh ./libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I/usr/include -I/usr/include -Wall -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i386 -mtune=generic -fasynchronous-unwind-tables -MT odbcapi30.lo -MD -MP -MF .deps/odbcapi30.Tpo -c -o odbcapi30.lo odbcapi30.c
libtool: compile: gcc -DHAVE_CONFIG_H -I. -I/usr/include -I/usr/include -Wall -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i386 -mtune=generic -fasynchronous-unwind-tables -MT odbcapi30.lo -MD -MP -MF .deps/odbcapi30.Tpo -c odbcapi30.c -fPIC -DPIC -o .libs/odbcapi30.o
odbcapi30.c:115: error: conflicting types for 'SQLColAttribute'
/usr/include/sql.h:600: note: previous declaration of 'SQLColAttribute' was here
odbcapi30.c: In function 'SQLFetchScroll':
odbcapi30.c:198: warning: pointer targets in initialization differ in signedness
odbcapi30.c:223: warning: pointer targets in passing argument 4 of 'PGAPI_ExtendedFetch' differ in signedness
pgapifunc.h:186: note: expected 'SQLUINTEGER *' but argument is of type 'SQLINTEGER *'
make[2]: *** [odbcapi30.lo] Error 1
make[2]: Leaving directory `/home/devrim/rpm/BUILD/psqlodbc-08.04.0100'
make[1]: *** [all] Error 2
make[1]: Leaving directory `/home/devrim/rpm/BUILD/psqlodbc-08.04.0100'
error: Bad exit status from /var/tmp/rpm-tmp.4qU2Xs (%build)
===============================================================================================

Regards,

--
Devrim GÜNDÜZ, RHCE
Command Prompt - http://www.CommandPrompt.com
devrim~gunduz.org, devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr
http://www.gunduz.org

Hi Davrim-san.

Sorry very late reaction....

> Hi,
>
> I'm getting the message below on Fedora 11, which has unixODBC 2.2.14 and gcc 4.4.0:
>
> ===============================================================================================
> /bin/sh ./libtool --tag=CC --mode=compile
> gcc -DHAVE_CONFIG_H -I. -I/usr/include -I/usr/include -Wall -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2
> -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i386 -mtune=generic -fasynchronous-unwind-tables
> -MT odbcapi30.lo -MD -MP -MF .deps/odbcapi30.Tpo -c -o odbcapi30.lo odbcapi30.c
> libtool: compile:
> gcc -DHAVE_CONFIG_H -I. -I/usr/include -I/usr/include -Wall -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2
> -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i386 -mtune=generic -fasynchronous-unwind-tables
> -MT odbcapi30.lo -MD -MP -MF .deps/odbcapi30.Tpo -c odbcapi30.c -fPIC -DPIC -o .libs/odbcapi30.o
> odbcapi30.c:115: error: conflicting types for 'SQLColAttribute'
> /usr/include/sql.h:600: note: previous declaration of 'SQLColAttribute' was here
> odbcapi30.c: In function 'SQLFetchScroll':
> odbcapi30.c:198: warning: pointer targets in initialization differ in signedness
> odbcapi30.c:223: warning: pointer targets in passing argument 4 of 'PGAPI_ExtendedFetch' differ
> in
> signedness
> pgapifunc.h:186: note: expected 'SQLUINTEGER *' but argument is of type 'SQLINTEGER *'
> make[2]: *** [odbcapi30.lo] Error 1
> make[2]: Leaving directory `/home/devrim/rpm/BUILD/psqlodbc-08.04.0100'
> make[1]: *** [all] Error 2
> make[1]: Leaving directory `/home/devrim/rpm/BUILD/psqlodbc-08.04.0100'
> error: Bad exit status from /var/tmp/rpm-tmp.4qU2Xs (%build)
> ===============================================================================================
>
> Regards,
>
> --
> Devrim GÜNDÜZ, RHCE
> Command Prompt - http://www.CommandPrompt.com
> devrim~gunduz.org, devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr
> http://www.gunduz.org
>

Ummm, I was testing using 2.2.11 as a stable version....
As far as I know, 2.2.14 had some problems. Then, your problem is also one
of them. the following is the information. However, #if which put the mark on
the specific version may be desired. Probably, Inoue-san may have a good
idea. It desires to be adjusted for the following version.

== unixODBC-2.2.14 ==

SQLRETURN SQL_API SQLColAttribute(SQLHSTMT StatementHandle,
SQLUSMALLINT ColumnNumber, SQLUSMALLINT
FieldIdentifier,
SQLPOINTER CharacterAttribute, SQLSMALLI
NT BufferLength,
SQLSMALLINT *StringLength, SQLLEN *Numer
icAttribute

/* spec says (SQLPOINTER) not (SQLEN*) - PAH */ );

== unixODBC-2.2.11 ==

SQLRETURN SQL_API SQLColAttribute (SQLHSTMT StatementHandle,
SQLUSMALLINT ColumnNumber, SQLUSMALLINT
FieldIdentifier,
SQLPOINTER CharacterAttribute, SQLSMALLI
NT BufferLength,
SQLSMALLINT *StringLength, SQLPOINTER Nu
mericAttribute /* spec says (SQLPOINTER) not (SQLEN*) - PAH */ );

== unixODBC ==

#elif defined(WITH_UNIXODBC) || defined(WIN32)
SQLPOINTER NumericAttribute
#else
SQLLEN *NumericAttribute
#endif

==/

Regards,
Hiroshi Saito

On Thu, 2009-07-30 at 12:59 +0900, Hiroshi Saito wrote:
>
> Ummm, I was testing using 2.2.11 as a stable version....
> As far as I know, 2.2.14 had some problems. Then, your problem is also
> one of them. the following is the information. However, #if which put
> the mark on the specific version may be desired. Probably, Inoue-san
> may have a good idea. It desires to be adjusted for the following
> version.

Was this issue addressed?

--
Devrim GÜNDÜZ, RHCE
Command Prompt - http://www.CommandPrompt.com
devrim~gunduz.org, devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr
http://www.gunduz.org

Hi Devrim-san.

I propose this after some tests. then, I will want to apply it, if someone do not
have an objection in this ptach, either and if your condition is good.

Regards,
Hiroshi Saito

----- Original Message -----
From: "Devrim GÜNDÜZ" <devrim(at)gunduz(dot)org>

>> Ummm, I was testing using 2.2.11 as a stable version....
>> As far as I know, 2.2.14 had some problems. Then, your problem is also
>> one of them. the following is the information. However, #if which put
>> the mark on the specific version may be desired. Probably, Inoue-san
>> may have a good idea. It desires to be adjusted for the following
>> version.
>
> Was this issue addressed?