Re: Errors building older versions of PostgreSQL

Thanks for the tips. It kind of worked. I got passed that point, but
then got to another set of errors.

I'm going to change my approach. I'm trying to locate some older
Linux ISOs that I can install in a vmware virtual environment and try
to build in there. Since all I want is to dump my data, I don't
really have that much of a worry about long-term performance within a
virtualized system.

We'll see how it goes. So far finding older ISOs has been more
difficult than I expected. It appears no one is seriously keeping an
archive of old Linux distros. This is too bad, because it can be non-
trivial to get older versions of software working on newer distros,
and that means data gathering dust in offline backups might not be
recoverable, especially if it is just data backups and not entire
systems (like I happen to be dealing with).

If this avenue fails, I'll post back with actual error messages. I do
appreciate your assistance.

Thanks,
Greg


On Jul 13, 2005, at 7:58 PM, Alvaro Herrera wrote:

> On Wed, Jul 13, 2005 at 04:29:41PM -0700, Gregory Youngblood wrote:
>
>
>> It gets through most of the make process, but then at the point where
>> it starts creating files like GNUmakefile, it returns:
>> sed: file conftest.sl line 35: unterminated `s' command
>>
>
> The problem is that GCC now gives a multiline string when given
> --version.  I think the easiest way out is to change the configure
> file,
> where it says
>
> CC_VERSION=`${CC} --version`
>
> to something like
>
> CC_VERSION=`${CC} --version | head -1`
>
> (Or change configure.in and rerun autoconf)
>
>
>> Second problem, this time is for 7.1.
>>
>> 7.1 is configured with:
>> ./configure --prefix=/export/storage/PostgreSQL/7.1 --pgport=5434
>>
>> It doesn't get as far as 7.0, but it does get to:
>> Checking types of arguments for accept() . . .
>>
>
> I think the easiest would be to take the
> config/ac_func_accept_argtypes.m4 file from a newer release, rerun
> autoconf, and rerun configure.
>
> --
> Alvaro Herrera (<alvherre[a]alvh.no-ip.org>)
> "In fact, the basic problem with Perl 5's subroutines is that
> they're not
> crufty enough, so the cruft leaks out into user-defined code
> instead, by
> the Conservation of Cruft Principle."  (Larry Wall, Apocalypse 6)
>
> ---------------------------(end of
> broadcast)---------------------------
> TIP 5: don't forget to increase your free space map settings
>