FAQ
On attempts the last two weekends to compile first PostgreSQL 7.2,
then 7.2.1, I've run into the same error.

The machine is an i586 with a Linux on it that is ancestrally Red
Hat 5.2, kernel 2.3.2, but that has been hacked since and may since
have had another Linux installed over it (I'm not sure). I do know
that I ran into trouble trying to install Perl 5.005_03 on it; that
it now has an installation of Perl 5.004_04 which may or may not be
later (I didn't put it there); that I have successfully installed
trn 4.0-something on it. So in other words it may be a broken OS,
but isn't totally broken. The error with Perl had something to do
with SysV IPCs.

The error occurs, after a successful run of configure, when gmake
reaches src/backend/libpq/hba.c. It goes like this:

gcc -O2 -g -Wall -Wmissing-prototypes -Wmissing-declarations -I../../../src/incl ude -I/opt/include -I/usr/local/ssl/include -c hba.c -o hba.o
hba.c: In function `ident_unix':
hba.c:885: storage size of `peercred' isn't known
hba.c:885: warning: unused variable `peercred'
gmake[3]: *** [hba.o] Error 1
gmake[3]: Leaving directory
`/home/joe/postgresql-7.2.1/src/backend/libpq'
gmake[2]: *** [libpq-recursive] Error 2
gmake[2]: Leaving directory `/home/joe/postgresql-7.2.1/src/backend'
gmake[1]: *** [all] Error 2
gmake[1]: Leaving directory `/home/joe/postgresql-7.2.1/src'
gmake: *** [all] Error 2

I looked at hba.c. I have never been good at C, and haven't looked at
it much at all since 1984, but it *looks* to me like the code there is
assuming that something will be implemented Just So, which obviously
isn't implemented Just So on this machine. (Looking more carefully,
I see that there's an include earlier for a ucred.h, which is not
present in /usr/include/sys on this machine, or anywhere else that
whereis knows about. I assume this is relevant since peercred is
declared as a struct of type ucred.)

I looked in Google. It appears that the recent addition of peercred
for authentication was meant to make ident authentication work in Linux
machines. I hadn't actually planned to use ident authentication at all
(but did see the posts saying that without it you can't run VACUUM; if
that's true, why didn't the manual say so?). It also appears that
peercred is not the only way to make ident authentication work on Linux;
it seems to be the preferred one, but I have the impression there
may even be other ways in the shipped source, let alone possible ways
not included there.

But I don't know C well, and certainly don't know how gcc works or
how I can convince it not to care about something it considers bad
code... on this machine, anyway.

So look: Is whatever may or may not be wrong with this machine
concerning peercred so catastrophically wrong that I Must Not attempt
to run PostgreSQL? If this is not the case, I'd really appreciate some
advice as to how I can change what to get the program to compile.

I have full logs of the configure and gmake runs, in case you need to
know anything more.

Thanks

Joe Bernstein
joe@sfbooks.com
http://these-survive.postilion.org/ (which indicates why I'm trying to
compile PostgreSQL, by the way)

Search Discussions

  • Tom Lane at Apr 15, 2002 at 2:54 pm

    Joe Bernstein writes:
    So look: Is whatever may or may not be wrong with this machine
    concerning peercred so catastrophically wrong that I Must Not attempt
    to run PostgreSQL?
    Just disable the code that tries to support peercred; it's certainly
    not a necessary feature. (Change "#if defined(SO_PEERCRED)" to #if 0.)

    This does indicate that assuming SO_PEERCRED exists means struct ucred
    exists is Wrong. Probably there should be a direct configure check for
    HAVE_STRUCT_UCRED.

    regards, tom lane
  • Bruce Momjian at Apr 15, 2002 at 7:40 pm

    Tom Lane wrote:
    Joe Bernstein <joe@sfbooks.com> writes:
    So look: Is whatever may or may not be wrong with this machine
    concerning peercred so catastrophically wrong that I Must Not attempt
    to run PostgreSQL?
    Just disable the code that tries to support peercred; it's certainly
    not a necessary feature. (Change "#if defined(SO_PEERCRED)" to #if 0.)

    This does indicate that assuming SO_PEERCRED exists means struct ucred
    exists is Wrong. Probably there should be a direct configure check for
    HAVE_STRUCT_UCRED.
    That is interesting. My guess is that indeed it is a mixed OS version
    installed:
    The machine is an i586 with a Linux on it that is ancestrally Red
    Hat 5.2, kernel 2.3.2, but that has been hacked since and may since
    have had another Linux installed over it (I'm not sure). I do know
    This is the first compile failure we have heard about and it is hard to
    imagine you have SO_PEERCRED defined but no ucred. My guess is that
    some of the system includes where updated, but not all.

    --
    Bruce Momjian | http://candle.pha.pa.us
    pgman@candle.pha.pa.us | (610) 853-3000
    + If your life is a hard drive, | 830 Blythe Avenue
    + Christ can be your backup. | Drexel Hill, Pennsylvania 19026
  • Joe Bernstein at Apr 16, 2002 at 12:30 am
    (Apologies to Bruce Momjian for double-sending. If it's a real
    annoyance, tell me so and I won't again; but I'm not subscribed
    to pgsql-ports so not sure...)
    On Mon, Apr 15, 2002 at 03:40:36PM -0400, Bruce Momjian wrote:

    Tom Lane wrote:
    Joe Bernstein <joe@sfbooks.com> writes:
    So look: Is whatever may or may not be wrong with this machine
    concerning peercred so catastrophically wrong that I Must Not attempt
    to run PostgreSQL?
    Just disable the code that tries to support peercred; it's certainly
    not a necessary feature. (Change "#if defined(SO_PEERCRED)" to #if 0.)
    Thanks! Duh!

    (I recognise Tom Lane's name, but will wait to do this, partly to do my
    taxes, and partly to see if anyone else screams "NO! NO!" But it sure
    *looks* like that's all I need, so thanks!)
    This does indicate that assuming SO_PEERCRED exists means struct ucred
    exists is Wrong. Probably there should be a direct configure check for
    HAVE_STRUCT_UCRED.
    That is interesting. My guess is that indeed it is a mixed OS version
    installed:
    The machine is an i586 with a Linux on it that is ancestrally Red
    Hat 5.2, kernel 2.3.2, but that has been hacked since and may since
    have had another Linux installed over it (I'm not sure). I do know
    This is the first compile failure we have heard about and it is hard to
    imagine you have SO_PEERCRED defined but no ucred. My guess is that
    some of the system includes where updated, but not all.
    When I wrote "hacked", by the way, I meant the good old-fashioned
    meaning of "hacked, i.e., messed with by its owner. He's never clearly
    explained to me what he did, and he was admittedly baffled by the SysV
    IPC problem that stonkered Perl, but anyway, I didn't mean there had
    been extensive redecoration by vandals. (Some exploits have happened,
    I gather, but nothing like that.)

    I have no clue what happened as regards ucred. I do know that he's done
    (on his two Linux boxes) installs of bought Linuxen out of the box, and
    he's also done highly customised installs of downloaded Linuxen; he's
    also "hacked the kernel". So really, anything goes.

    My own take on this was that SO_PEERCRED must be some sort of internal
    PgSQL flag for "This is a Linux box, so it must have peercred support"
    or some such; the discussion of peercred that I found at Google didn't
    really suggest anything else, but I didn't actually locate any evidence
    for this view. If SO_PEERCRED is some sort of pre-existing environment
    variable, then yes, that would imply that the problem was unique to this
    machine.

    Anyway, unless there are screams about what Tom Lane suggested, it looks
    like this should solve this problem. I'll be sure to let you know if
    there are more surprises in the compile process...

    Joe Bernstein
    joe@sfbooks.com
    <http://these-survive.postilion.org/>
  • Bruce Momjian at Apr 16, 2002 at 12:43 am

    Joe Bernstein wrote:
    (Apologies to Bruce Momjian for double-sending. If it's a real
    annoyance, tell me so and I won't again; but I'm not subscribed
    to pgsql-ports so not sure...)
    On Mon, Apr 15, 2002 at 03:40:36PM -0400, Bruce Momjian wrote:

    Tom Lane wrote:
    Joe Bernstein <joe@sfbooks.com> writes:
    So look: Is whatever may or may not be wrong with this machine
    concerning peercred so catastrophically wrong that I Must Not attempt
    to run PostgreSQL?
    Just disable the code that tries to support peercred; it's certainly
    not a necessary feature. (Change "#if defined(SO_PEERCRED)" to #if 0.)
    Thanks! Duh!

    (I recognise Tom Lane's name, but will wait to do this, partly to do my
    taxes, and partly to see if anyone else screams "NO! NO!" But it sure
    *looks* like that's all I need, so thanks!)
    I added the SO_PEERCRED code. It is only enabled when you use 'local'
    and 'ident' in pg_hba.conf. If you don't enable that, removing this has
    no effect, and it is not enabled by default. If you do enable it, it
    will not work.

    --
    Bruce Momjian | http://candle.pha.pa.us
    pgman@candle.pha.pa.us | (610) 853-3000
    + If your life is a hard drive, | 830 Blythe Avenue
    + Christ can be your backup. | Drexel Hill, Pennsylvania 19026

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppgsql-ports @
categoriespostgresql
postedApr 14, '02 at 2:28a
activeApr 16, '02 at 12:43a
posts5
users4
websitepostgresql.org
irc#postgresql

People

Translate

site design / logo © 2022 Grokbase