Thread: 7.4 include file conflict
Hello, I saw another post on this list about some conflicts on building an rpm on redhat that seemed similar. I wanted to add that I was building PHP with the individual directory flags, (./configure --with-iodbc=/usr --with-pgsql=/usr/local ) and the compiler still choked (see below). Not sure if just moving the file sqltypes.h will fix this. Copied my message from another list to this one also. Thanks. Ray A. > >Hello, > >I have a question regarding the 7.4 library include file called >/usr/local/pgsql/include/sqltypes.h > >It seems to only include supplementary type defs. > >The problem is that I installed the client libraries on a Mac XSERVE >10.3 server that comes with iODBC libraries in /usr/include. I was >compiling PHP with iODBC support as well as with PgSQL support and >it kept dying with syntax errors on the iODBC make. > >I found that the compiler was looking in the pgsql include directory >first and found its version of sqltypes.h > >I was able to get around the errors by renaming the pg header file >to something else, but I still have not checked if that had some >impact on the pg functionality that was built. > >Is it necessary to have this include file named this or could it be >renamed to something more specific to like pgsqltypes.h > >More info on this file would be appreciated. > >Thanks much. > >Ray A.
Where are we going on the pgsql/include file conflicts? sqltypes.h is very common on Win32, and decimal.h might be a problem too. We even have compatlib.h. We can tell them to adjust the include path, but what do we do about win32 system includes that want the system sqltypes.h? --------------------------------------------------------------------------- Ray Aspeitia wrote: > Hello, > > I saw another post on this list about some conflicts on building an > rpm on redhat that seemed similar. > > I wanted to add that I was building PHP with the individual directory > flags, (./configure --with-iodbc=/usr --with-pgsql=/usr/local ) and > the compiler still choked (see below). > > Not sure if just moving the file sqltypes.h will fix this. > > Copied my message from another list to this one also. > > Thanks. > > Ray A. > > > > >Hello, > > > >I have a question regarding the 7.4 library include file called > >/usr/local/pgsql/include/sqltypes.h > > > >It seems to only include supplementary type defs. > > > >The problem is that I installed the client libraries on a Mac XSERVE > >10.3 server that comes with iODBC libraries in /usr/include. I was > >compiling PHP with iODBC support as well as with PgSQL support and > >it kept dying with syntax errors on the iODBC make. > > > >I found that the compiler was looking in the pgsql include directory > >first and found its version of sqltypes.h > > > >I was able to get around the errors by renaming the pg header file > >to something else, but I still have not checked if that had some > >impact on the pg functionality that was built. > > > >Is it necessary to have this include file named this or could it be > >renamed to something more specific to like pgsqltypes.h > > > >More info on this file would be appreciated. > > > >Thanks much. > > > >Ray A. > > > ---------------------------(end of broadcast)--------------------------- > TIP 4: Don't 'kill -9' the postmaster > -- 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, Pennsylvania19073
> -----Original Message----- > From: Bruce Momjian [mailto:pgman@candle.pha.pa.us] > Sent: 16 December 2003 01:17 > To: Ray Aspeitia > Cc: pgsql-hackers@postgresql.org > Subject: Re: [HACKERS] 7.4 include file conflict > > > Where are we going on the pgsql/include file conflicts? > sqltypes.h is very common on Win32, and decimal.h might be a > problem too. We even have compatlib.h. > > We can tell them to adjust the include path, but what do we do about > win32 system includes that want the system sqltypes.h? We could prefix the names as Ray suggested <pgsqltypes.h>, or move them into a pg subdirectory and change the includes to <pg/sqltypes.h>. The former is probably less work I'd guess. Regards, Dave.
Dave Page writes: > We could prefix the names as Ray suggested <pgsqltypes.h>, or move them > into a pg subdirectory and change the includes to <pg/sqltypes.h>. But the file has to be called sqltypes.h or it won't work.
> -----Original Message----- > From: Peter Eisentraut [mailto:peter_e@gmx.net] > Sent: 16 December 2003 09:09 > To: Dave Page > Cc: pgman@candle.pha.pa.us; aspeitia@sells.com; > pgsql-hackers@postgresql.org > Subject: Re: [HACKERS] 7.4 include file conflict > > Dave Page writes: > > We could prefix the names as Ray suggested <pgsqltypes.h>, or move > > them into a pg subdirectory and change the includes to > <pg/sqltypes.h>. > > But the file has to be called sqltypes.h or it won't work. Why, is it used directly by user code? (I never used ecpg) Regards, Dave
On Tue, Dec 16, 2003 at 10:38:00AM -0000, Dave Page wrote: > > But the file has to be called sqltypes.h or it won't work. > > Why, is it used directly by user code? (I never used ecpg) Well, it is not really an ecpg file, but one needed for compatibility. And, yes, Peter is correct, this file may be included directly by some apps. Michael -- Michael Meskes Email: Michael at Fam-Meskes dot De ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: meskes@jabber.org Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL!
Michael Meskes <meskes@postgresql.org> writes:
> Well, it is not really an ecpg file, but one needed for compatibility.
> And, yes, Peter is correct, this file may be included directly by some
> apps.
I was under the impression that this issue had already been resolved
among you, Lamar, and the Red Hat packaging people. Aren't we going to
install ecpg's headers into $(includedir)/ecpg instead of $(includedir)?
regards, tom lane
Tom Lane wrote: > Michael Meskes <meskes@postgresql.org> writes: > > Well, it is not really an ecpg file, but one needed for compatibility. > > And, yes, Peter is correct, this file may be included directly by some > > apps. > > I was under the impression that this issue had already been resolved > among you, Lamar, and the Red Hat packaging people. Aren't we going to > install ecpg's headers into $(includedir)/ecpg instead of $(includedir)? Maybe that fixes the Red Hat issue, but we have the Cygwin issue with Win32's sqltypes.h, and there is the issue for other platforms, no? Is that install change going to be for all platforms? -- 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, Pennsylvania19073
On Tue, Dec 16, 2003 at 02:01:51PM -0500, Bruce Momjian wrote: > Maybe that fixes the Red Hat issue, but we have the Cygwin issue with > Win32's sqltypes.h, and there is the issue for other platforms, no? Is > that install change going to be for all platforms? The problem as I see it is that some software installs an include file with the same name into /usr/include. So if you specify -I /usr/include/pgsql/ecpg you still essantially override this file. Now the question is whether anyone would have to use the ecpg sqltypes.h and the other one, be it a windows file or th unixodbc or the iodbc one. Does anyone know how Informix, where this file comes from, handles this? Would it be a solution to just move the compat headers out of the main include dir? michael -- Michael Meskes Email: Michael at Fam-Meskes dot De ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: meskes@jabber.org Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL!
Michael Meskes wrote: > On Tue, Dec 16, 2003 at 02:01:51PM -0500, Bruce Momjian wrote: > > Maybe that fixes the Red Hat issue, but we have the Cygwin issue with > > Win32's sqltypes.h, and there is the issue for other platforms, no? Is > > that install change going to be for all platforms? > > The problem as I see it is that some software installs an include file > with the same name into /usr/include. So if you specify -I > /usr/include/pgsql/ecpg you still essantially override this file. Now > the question is whether anyone would have to use the ecpg sqltypes.h and > the other one, be it a windows file or th unixodbc or the iodbc one. Are you saying some programs will look in /usr/include before looking in -I specified directories, and that is the whole problem? If so, that is 100% wrong and we don't have to fix our files to workaround this. -- 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, Pennsylvania19073
On Tue, Dec 16, 2003 at 07:00:25PM -0500, Bruce Momjian wrote: > Are you saying some programs will look in /usr/include before looking in > -I specified directories, and that is the whole problem? If so, that is > 100% wrong and we don't have to fix our files to workaround this. No I meant to say that you will alsways get our file and not the one in /usr/include. That means you must not specify our -I option if you need the file in /usr/include. Since this file may be needed together with pgsql The best way seems to be moving just the compat headers IMO. Michael -- Michael Meskes Email: Michael at Fam-Meskes dot De ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: meskes@jabber.org Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL!
Michael Meskes wrote: > On Tue, Dec 16, 2003 at 07:00:25PM -0500, Bruce Momjian wrote: > > Are you saying some programs will look in /usr/include before looking in > > -I specified directories, and that is the whole problem? If so, that is > > 100% wrong and we don't have to fix our files to workaround this. > > No I meant to say that you will always get our file and not the one in > /usr/include. That means you must not specify our -I option if you need > the file in /usr/include. Since this file may be needed together with > pgsql The best way seems to be moving just the compat headers IMO. Yes, that's what I was afraid of. Once you add -I, there is no way to access the /usr/include files matching names that are also in the -I path. You could use #include "/usr/include/xxx.h", but no one does that, and I can imagine including a system include that itself wants to include one of those /usr/include files rather than the pgsql file. Are you suggesting moving the ecpg files into pgsql/include/ecpg? Do we know that no one using ecpg is going to be including a /usr/include file that needs /usr/include/xxx.h? -- 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, Pennsylvania19073
On Wed, Dec 17, 2003 at 10:27:19AM -0500, Bruce Momjian wrote: > Are you suggesting moving the ecpg files into pgsql/include/ecpg? Do we > know that no one using ecpg is going to be including a /usr/include file > that needs /usr/include/xxx.h? No, just the files needed for Informix compatibility. Peter is preparing a patch that dave can test for us, so we hopefully get this into CVS until Friday. michael -- Michael Meskes Email: Michael at Fam-Meskes dot De ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: meskes@jabber.org Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL!
> Does anyone know how Informix, where this file comes from, > handles this? Informix puts those files in $INFORMIXDIR/incl/esql (e.g. /usr/informix/incl/esql), so imho a /usr/postgres installation could have them somewhere under /usr/postgres Andreas
Michael Meskes wrote: > On Wed, Dec 17, 2003 at 10:27:19AM -0500, Bruce Momjian wrote: > > Are you suggesting moving the ecpg files into pgsql/include/ecpg? > > Do we know that no one using ecpg is going to be including a > > /usr/include file that needs /usr/include/xxx.h? > > No, just the files needed for Informix compatibility. Peter is > preparing a patch that dave can test for us, so we hopefully get this > into CVS until Friday. Patch installed.
I would like to mention that I am on MacOS 10.3 and have this issue when compiling PHP with both iODBC support and Postgres support at the same time. I have to specify the -I/usr/include and the -I/usr/local/pgsql/include in order for the build scripts to run correctly. the problem is that at build time when building iODBC it may or may not look in /usr/include first depending on when the flags were placed. Moving the file to ecpg/sqltypes.h should do the trick because anything other than postgres should not traverse into ecpg/ unless specifically looking for it. Not sure if that breaks any user programs as someone else noted. Thanks. Ray A. At 9:39 AM +0100 12/17/03, Michael Meskes wrote: >On Tue, Dec 16, 2003 at 07:00:25PM -0500, Bruce Momjian wrote: >> Are you saying some programs will look in /usr/include before looking in >> -I specified directories, and that is the whole problem? If so, that is >> 100% wrong and we don't have to fix our files to workaround this. > >No I meant to say that you will alsways get our file and not the one in >/usr/include. That means you must not specify our -I option if you need >the file in /usr/include. Since this file may be needed together with >pgsql The best way seems to be moving just the compat headers IMO. > >Michael >-- >Michael Meskes >Email: Michael at Fam-Meskes dot De >ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: meskes@jabber.org >Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL!