Обсуждение: ecpg hackery to get ecpg to compile from FreeBSD ports...

Different bogon that I ran across:

2:35pm sean@mat:ecpg/lib > gmake
cc -O -pipe -g -O  -I/usr/local/include -Wall -Wmissing-prototypes -Wmissin=
g-declarations -fpic -DPIC -I../../../../src/interfaces/ecpg/include -I../.=
./../../src/interfaces/libpq -I../../../../src/include -I/usr/local/include=
 -I/usr/local/include  -c -o connect.o connect.c
connect.c: In function `ECPGnoticeProcessor':
connect.c:148: `ECPG_WARNING_UNRECOGNIZED' undeclared (first use in this fu=
nction)
connect.c:148: (Each undeclared identifier is reported only once
connect.c:148: for each function it appears in.)
connect.c:166: `ECPG_WARNING_QUERY_IGNORED' undeclared (first use in this f=
unction)
connect.c:175: `ECPG_WARNING_UNKNOWN_PORTAL' undeclared (first use in this =
function)
connect.c:182: `ECPG_WARNING_IN_TRANSACTION' undeclared (first use in this =
function)
connect.c:193: `ECPG_WARNING_NO_TRANSACTION' undeclared (first use in this =
function)
connect.c:201: `ECPG_WARNING_PORTAL_EXISTS' undeclared (first use in this f=
unction)
gmake: *** [connect.o] Error 1
2:35pm sean@mat:ecpg/lib > pwd
/usr/ports/databases/postgresql7-beta/work/postgresql-7.3b1/src/interfaces/=
ecpg/lib


This works:
cc -O -pipe -g -O -I../../../../src/interfaces/ecpg/include -I/usr/local/in=
clude -Wall -Wmissing-prototypes -Wmissing-declarations -fpic -DPIC -I../..=
/../../src/interfaces/libpq -I../../../../src/include -I/usr/local/include =
-I/usr/local/include -c -o connect.o connect.c

This doesn't:
cc -O -pipe -g -O -I/usr/local/include -I../../../../src/interfaces/ecpg/in=
clude -Wall -Wmissing-prototypes -Wmissing-declarations -fpic -DPIC -I../..=
/../../src/interfaces/libpq -I../../../../src/include -I/usr/local/include =
-I/usr/local/include -c -o connect.o connect.c

I've got an older ecpgerrno.h in /usr/local/include that doesn't seem
to have these defined.  Two quick suggestions:

*) Prepend the CPPFLAGS to the CFLAGS (works, but is hackish)
*) Alter the #ifndef

This strikes me as an upgrade problem for folks that others are going
to run across.  -sc

--=20
Sean Chittenden

Sean Chittenden writes:

> Different bogon that I ran across:
>
> 2:35pm sean@mat:ecpg/lib > gmake
> cc -O -pipe -g -O  -I/usr/local/include -Wall -Wmissing-prototypes -Wmissing-declarations -fpic -DPIC
-I../../../../src/interfaces/ecpg/include-I../../../../src/interfaces/libpq -I../../../../src/include
-I/usr/local/include-I/usr/local/include  -c -o connect.o connect.c 

Apparently you somehow put -I/usr/local/include into CFLAGS.  Don't do
that.

--
Peter Eisentraut   peter_e@gmx.net

> > Different bogon that I ran across:
> >
> > 2:35pm sean@mat:ecpg/lib > gmake
> > cc -O -pipe -g -O  -I/usr/local/include -Wall -Wmissing-prototypes -Wmissing-declarations -fpic -DPIC
-I../../../../src/interfaces/ecpg/include-I../../../../src/interfaces/libpq -I../../../../src/include
-I/usr/local/include-I/usr/local/include  -c -o connect.o connect.c 
>
> Apparently you somehow put -I/usr/local/include into CFLAGS.  Don't do
> that.

Easier said than done...  /usr/local/include is propagated throughout
the build to catch local package installations
(getopt/readline)... I'll see if I can't figure out the correct fix
for this though.  Thanks for the info though.  -sc

--
Sean Chittenden

> > > Different bogon that I ran across:
> > >
> > > 2:35pm sean@mat:ecpg/lib > gmake
> > > cc -O -pipe -g -O  -I/usr/local/include -Wall -Wmissing-prototypes -Wmissing-declarations -fpic -DPIC
-I../../../../src/interfaces/ecpg/include-I../../../../src/interfaces/libpq -I../../../../src/include
-I/usr/local/include-I/usr/local/include  -c -o connect.o connect.c 
> >
> > Apparently you somehow put -I/usr/local/include into CFLAGS.  Don't do
> > that.
>
> Easier said than done...  /usr/local/include is propagated
> throughout the build to catch local package installations
> (getopt/readline)... I'll see if I can't figure out the correct fix
> for this though.  Thanks for the info though.  -sc

This is anecdotal for the archives, but the problem was that when
building with krb5, I had (wrongly?) appended krb5-config's --cflags
output to the CFLAGS for the build...  which, nine times out of ten,
was exactly the same as what was used with the --with-includes.  If
they're different, the person's horked, but that should be a minority
of the time.  Anyway, just an FYI.

-sc

--
Sean Chittenden

Sean Chittenden writes:

> This is anecdotal for the archives, but the problem was that when
> building with krb5, I had (wrongly?) appended krb5-config's --cflags
> output to the CFLAGS for the build...  which, nine times out of ten,
> was exactly the same as what was used with the --with-includes.  If
> they're different, the person's horked, but that should be a minority
> of the time.  Anyway, just an FYI.

The foo-config scripts are invariably bogus[*] -- don't use them.
Especially if you're building in a predictable environment such as the
ports tree you don't even need it since the location is known.

[*] at least those that claim to give you the full CFLAGS, unlike
pg_config

--
Peter Eisentraut   peter_e@gmx.net