Обсуждение: PGSQL 7.2.1 compile error on Red Hat 5.2 due to peercred
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)
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.
regards, tom lane
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 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
(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/>