Thread: Re: Error compiling PostgreSQL 7.4 for Fedora Core 1
Jonathan Gardner <jgardner@jonathangardner.net> writes:
> On Sunday 07 December 2003 12:48 am, Tom Lane wrote:
>> Hmmm ... this is evidently a variant of ye olde "Gen_fmgrtab.sh script
>> failed" problem,
> So far, this is what I have. I'm attaching fmgroids.h and fmgrtab.c ( I kno=
> w=20
> these are fairly sizable...)
That's really bizarre. For awhile I thought you might have fmgroids.h
and fmgrtab.c generated from some pre-7.4-release version of pg_proc.h,
but that theory doesn't seem to hold water --- for instance your files
include box_send() but not box_recv(), which were added in the same
commit. I don't see a pattern to the functions you are missing. Anyone
have a theory?
In the absence of any brilliant insight, I'd suggest slogging through
Gen_fmgrtab.sh to try to narrow down where functions are getting lost
--- add code to save the various intermediate files, and see what's in
'em. If we knew exactly which step was losing the functions it'd be a
leg up.
> Unfortunately, I am not familiar with the internals of awk and sed. If I=20
> were hired to fix this for my platform (Fedora Core 1), I would probably=20
> rewrite Gen_fmgrtab.sh in perl.
I can't see that as a plausible answer. With all due respect to Perl,
it's neither more portable nor more bug-free than awk/sed.
> The only other option I see is to distribute the pre-generated fmgroids.h
> and fmgrtab.c with the distribution.
We could fall back in that direction if we had to. But I'd like to
understand why we have to, first. Gen_fmgrtab.sh has worked on all our
supported platforms for a long time, and I'm disinclined to assume that
it's suddenly broken ... especially on what's presumably a modern
platform. I'm having a real problem with the idea that Fedora
incorporates a broken awk or sed.
regards, tom lane
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Monday 08 December 2003 9:33 pm, Tom Lane wrote: > In the absence of any brilliant insight, I'd suggest slogging through > Gen_fmgrtab.sh to try to narrow down where functions are getting lost > --- add code to save the various intermediate files, and see what's in > 'em. If we knew exactly which step was losing the functions it'd be a > leg up. > I just did this. I am no awk or sed expert. I can't see any faults in the= =20 script other than it is difficult to read. My only thought is that some of= =20 the regex behavior has changed, but I can't identify anything. The regexes= =20 used here are very standard. Unfortunately, in testing the bugger, it accidentally worked. I find this= =20 most disturbing. However, I was pleasantly surprised that it failed at=20 least one more time before working properly. Chalk the cause of this bug up as high-energy particles striking the memory= =20 chip in just the right place at just the right time. The only other thing I think might affect it is the fact that I was=20 simultaneously compiling PostgreSQL 7.3.4, reading email, and downloading= =20 stuff. Perhaps there is a strange race condition in the make process. Of=20 course, the recent power outage in the area (that didn't affect us)=20 might've been a cause as well. I apologize that I couldn't ease your pain, Tom. I know how it feels to see= =20 the same bug pop up occasionally, only to be solved by hitting the "Redo"= =20 key. - --=20 Jonathan Gardner jgardner@jonathangardner.net Live Free, Use Linux! -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/1XQJWgwF3QvpWNwRAi0FAKCkPV+yn0y3kNT3AoHy5TX9a0v6NACaA7qI PlIJfFguW4LNr+4RL535rIM=3D =3DwWkP -----END PGP SIGNATURE-----
Tom Lane wrote: > We could fall back in that direction if we had to. But I'd like to > understand why we have to, first. Gen_fmgrtab.sh has worked on all our > supported platforms for a long time, and I'm disinclined to assume that > it's suddenly broken ... especially on what's presumably a modern > platform. I'm having a real problem with the idea that Fedora > incorporates a broken awk or sed. I was able to rebuild from source rpm on a Fedora machine without any problem, so I don't think it's a case of wholesale breakage. It's not my normal development machine, but I'll try compiling from source [...tries...] Yup, I got a clean build from source with the following configure line: ./configure \ --prefix=/usr/local/pgsql-7.4 \ --with-pgport=55434 \ --with-perl \ --with-tcl \ --with-tclconfig=/usr/lib \ --without-tk \ --with-python \ --enable-nls \ --enable-debug \ --enable-cassert \ --enable-depend \ --with-openssl \ --with-pam \ --enable-integer-datetimes \ --with-krb5=/usr/kerberos \ --with-includes=/usr/include/et/ The only adjustment from my RH9 box was the last line. Without it com_err.h wasn't being found. Joe
Jonathan Gardner <jgardner@jonathangardner.net> writes:
> Unfortunately, in testing the bugger, it accidentally worked. I find this
> most disturbing. However, I was pleasantly surprised that it failed at
> least one more time before working properly.
Weird; there's no obvious reason for the script to be nondeterministic.
The only idea I can think of is that you were almost out of /tmp space
and the missing data got lost because of lack of space to put it. I'm
not sure whether awk/sed/etc would detect write failures on stdout.
regards, tom lane