Postgres Archeology
In a previous post I have ported a Turing Machine (TM) in SQL down to Postgres 7.3.
I report here my fruitless attempts at running previous versions of Postgres on a Debian or Ubuntu Linux. They would not configure and/or compile, at least with the minimal effort I was ready to undergo: writing portable-to-the-future system-dependent C code does not work. Basically, the code from 15 years ago is lost unless you run it on a system from 15 years ago, which may require a hardware from 15 years ago as well, or maybe a VM.
Trying to compile old Postgres versions…
Here is a summary of failures encountered while trying to compile previous versions from available sources:
Postgres 7.2 (2002)
configure thinks that my flex 2.5.35 is flex 2.5.3 and reports an issue.
Then the compilation fails, possibly because of an include issue, on:
Trying again with an older Debian Lenny, it fails when linking postgres:
/usr/bin/ld: errno: TLS definition in /lib/libc.so.6 section .tbss mismatches non-TLS reference in commands/SUBSYS.o
/lib/libc.so.6: could not read symbols: Bad value
collect2: ld returned 1 exit status
Postgres 7.1 (2001)
configure fails, it does not recognize gcc 4.7.2. autoconf fails on m4
while processing configure.in.
Same result with the old Debian Lenny.
...
/usr/bin/m4:configure.in:930: non-numeric argument to builtin `_m4_divert_raw'
autom4te: /usr/bin/m4 failed with exit status: 1
Postgres 7.0 (2000) and 6.5 (1999)
configure fails, but autoconf works fine.
Fix manually string continuations in src/include/version.h.
ld fails in the end with a segfault while linking postgres:
Postgres 6.0 (1997)
Create src/Makefile.custom, then make.
Compilation fails, possibly because of include issues:
Same result on the old Debian Lenny.
Postgres95 1.08 (1996)
Edit src/Makefile.global, then make.
Compilation fails:
Conclusion
Although the sources of past versions of Postgres are available, having them up and running on a modern system is another story.