Thread: Port report: Fedora Core 3 x86_64
All went mainly well - but a couple of gotchas on the build (these may be Fedora bugs rather than PG ones). This install is pretty much brand new (2 days old) with very little local configuration, so should represent an FC3 out of the box. 1. com_err.h is in /usr/include/et/com_err.h and isn't found by configure. Symbolic link to /usr/include fixed this. I notice this is complained about widely. 2. If tcl binaries and libs are installed, but not tcl-devel packages, the compile stops on pltcl.c when it can't load tcl.h. This case possibly merits detection at configure time? I was doing a vpath build, but otherwise configure command line exactly as listed by Peter E. uname -a: Linux adzuki 2.6.9-1.681_FC3 #1 Thu Nov 18 15:13:22 EST 2004 x86_64 x86_64 x86_64 GNU/Linux ======================All 96 tests passed. ====================== template1=# select version(); version -----------------------------------------------------------------------------------------------------------------PostgreSQL 8.0.0rc1on x86_64-unknown-linux-gnu, compiled by GCC gcc (GCC) 3.4.2 20041017 (Red Hat 3.4.2-6.fc3) Regards John
John Gray said: > All went mainly well - but a couple of gotchas on the build (these may > be Fedora bugs rather than PG ones). This install is pretty much brand > new (2 days old) with very little local configuration, so should > represent an FC3 out of the box. > > 1. com_err.h is in /usr/include/et/com_err.h and isn't found by > configure. Symbolic link to /usr/include fixed this. I notice this is > complained about widely. Instead of doing that, do: --with-includes=/usr/include/et cheers andrew
"Andrew Dunstan" <andrew@dunslane.net> writes:
> Instead of doing that, do:
> --with-includes=/usr/include/et
This same workaround is in the RPMs. I wonder if it would be worthwhile
for configure to assume the above when --with-krb5 is mentioned. I
don't know how widespread this particular file layout is ...
regards, tom lane
Tom Lane wrote: > "Andrew Dunstan" <andrew@dunslane.net> writes: > > Instead of doing that, do: > > --with-includes=/usr/include/et > > This same workaround is in the RPMs. I wonder if it would be > worthwhile for configure to assume the above when --with-krb5 is > mentioned. I don't know how widespread this particular file layout > is ... I have never seen it before. I've never had to add any paths to compile with Kerberos support, at least since they moved it out of /usr/kerberos. -- Peter Eisentraut http://developer.postgresql.org/~petere/
--On Montag, Dezember 13, 2004 17:23:06 +0100 Peter Eisentraut <peter_e@gmx.net> wrote: > Tom Lane wrote: >> "Andrew Dunstan" <andrew@dunslane.net> writes: >> > Instead of doing that, do: >> > --with-includes=/usr/include/et >> >> This same workaround is in the RPMs. I wonder if it would be >> worthwhile for configure to assume the above when --with-krb5 is >> mentioned. I don't know how widespread this particular file layout >> is ... > > I have never seen it before. I've never had to add any paths to compile > with Kerberos support, at least since they moved it out > of /usr/kerberos. FYI, i had the same issue here on Mandrake Linux 10.0/10.1 (32Bit), Community Edition and Official. -- Bernd
Bernd Helmle <mailings@oopsware.de> writes:
> Peter Eisentraut <peter_e@gmx.net> wrote:
>> Tom Lane wrote:
>>> "Andrew Dunstan" <andrew@dunslane.net> writes:
>>>> Instead of doing that, do:
>>>> --with-includes=/usr/include/et
>>> This same workaround is in the RPMs. I wonder if it would be
>>> worthwhile for configure to assume the above when --with-krb5 is
>>> mentioned. I don't know how widespread this particular file layout
>>> is ...
>> I have never seen it before. I've never had to add any paths to compile
>> with Kerberos support, at least since they moved it out
>> of /usr/kerberos.
> FYI, i had the same issue here on Mandrake Linux 10.0/10.1 (32Bit),
> Community Edition and Official.
Actually, I'm wondering why we directly include com_err.h at all. At
least in the version of <krb5.h> I have here, that file is included by
krb5.h; so both backend/libpq/auth.c and interfaces/libpq/fe-auth.c
compile just fine with #include <com_err.h> diked out. I suspect that
our problems in this area all stem from trying to include something
we are not supposed to include to begin with.
It's possible that com_err.h was considered an exported file in old
krb5 releases but no longer is. So perhaps what we should do is make
the C code read#ifdef HAVE_COM_ERR_H#include <com_err.h>#endif
and adjust configure to generate that symbol, but not require the header
to be found.
Comments?
regards, tom lane
I wrote:
>> [ concerning a discussion about Kerberos' com_err.h being in
>> /usr/include/et/ on some systems ]
> Actually, I'm wondering why we directly include com_err.h at all. At
> least in the version of <krb5.h> I have here, that file is included by
> krb5.h; so both backend/libpq/auth.c and interfaces/libpq/fe-auth.c
> compile just fine with #include <com_err.h> diked out.
After some digging in dusty old tarballs, I have learned that Kerberos 5
releases 1.0.* did indeed require a separate #include of com_err.h, but
in releases 1.1 and later krb5.h itself includes com_err.h and so
there's no need for a separate #include.
Kerberos 5 1.0.* includes serious known, never-patched vulnerabilities.
I can't believe that anyone is going to build PG 8.0 with krb5 1.0,
or that we need to be complicit in their trying to do so.
Accordingly, I think we should just avoid the whole problem of exactly
where com_err.h lives by removing the #includes for it as well as the
configure test for it.
regards, tom lane
Tom Lane said: > I wrote: >>> [ concerning a discussion about Kerberos' com_err.h being in >>> /usr/include/et/ on some systems ] > >> Actually, I'm wondering why we directly include com_err.h at all. At >> least in the version of <krb5.h> I have here, that file is included by >> krb5.h; so both backend/libpq/auth.c and interfaces/libpq/fe-auth.c >> compile just fine with #include <com_err.h> diked out. > > After some digging in dusty old tarballs, I have learned that Kerberos > 5 releases 1.0.* did indeed require a separate #include of com_err.h, > but in releases 1.1 and later krb5.h itself includes com_err.h and so > there's no need for a separate #include. > > Kerberos 5 1.0.* includes serious known, never-patched vulnerabilities. > I can't believe that anyone is going to build PG 8.0 with krb5 1.0, or > that we need to be complicit in their trying to do so. > > Accordingly, I think we should just avoid the whole problem of exactly > where com_err.h lives by removing the #includes for it as well as the > configure test for it. > Works for me. I'm not sure why the reasoning only applies to 8.0 - is it a case of the 'only fix serious bugs in stable releases' rule? cheers andrew
"Andrew Dunstan" <andrew@dunslane.net> writes:
> Tom Lane said:
>> Accordingly, I think we should just avoid the whole problem of exactly
>> where com_err.h lives by removing the #includes for it as well as the
>> configure test for it.
> Works for me. I'm not sure why the reasoning only applies to 8.0 - is it a
> case of the 'only fix serious bugs in stable releases' rule?
Pretty much. All this is really saving is the need to specify a
--with-includes option for Kerberos builds on some platforms, so
I'd classify it as a minor improvement and not a bug fix.
regards, tom lane