Re: ecpg hackery to get ecpg to compile from FreeBSD ports...
От | Sean Chittenden |
---|---|
Тема | Re: ecpg hackery to get ecpg to compile from FreeBSD ports... |
Дата | |
Msg-id | 20020909192757.GC26147@ninja1.internal обсуждение исходный текст |
Ответ на | Re: ecpg hackery to get ecpg to compile from FreeBSD ports... (Sean Chittenden <sean@chittenden.org>) |
Ответы |
Re: ecpg hackery to get ecpg to compile from FreeBSD ports...
|
Список | pgsql-bugs |
> > > 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
В списке pgsql-bugs по дате отправления: