Thread

buglet in 7.1.4

Enrico Weigelt <weigelt@metux.de> — 2004-03-06T17:41:28Z

Hi folks,


I've found a little bug in version 7.1.3 in conjunction w/ the
new gcc, which prints our more than one line on --version. 
(simply added | head -n 1)

The problem is that the gcc --version output is copied into 
confdefs.h and so produces compile erros. 

This problem does not appear on current 7.4.1.

See attached patch.

cu
-- 
---------------------------------------------------------------------
 Enrico Weigelt    ==   metux IT services

  phone:     +49 36207 519931         www:       http://www.metux.de/
  fax:       +49 36207 519932         email:     contact@metux.de
  cellphone: +49 174 7066481
---------------------------------------------------------------------
   -- DSL-Zugang ab 0 Euro. -- statische IP -- UUCP -- Hosting --
---------------------------------------------------------------------

Re: buglet in 7.1.4

Bruce Momjian <pgman@candle.pha.pa.us> — 2004-03-08T17:53:40Z

Yea, we probably aren't releasing any more 7.1.X releases though.

---------------------------------------------------------------------------

Enrico Weigelt wrote:
> 
> Hi folks,
> 
> 
> I've found a little bug in version 7.1.3 in conjunction w/ the
> new gcc, which prints our more than one line on --version. 
> (simply added | head -n 1)
> 
> The problem is that the gcc --version output is copied into 
> confdefs.h and so produces compile erros. 
> 
> This problem does not appear on current 7.4.1.
> 
> See attached patch.
> 
> cu
> -- 
> ---------------------------------------------------------------------
>  Enrico Weigelt    ==   metux IT services
> 
>   phone:     +49 36207 519931         www:       http://www.metux.de/
>   fax:       +49 36207 519932         email:     contact@metux.de
>   cellphone: +49 174 7066481
> ---------------------------------------------------------------------
>    -- DSL-Zugang ab 0 Euro. -- statische IP -- UUCP -- Hosting --
> ---------------------------------------------------------------------

[ Attachment, skipping... ]

> 
> ---------------------------(end of broadcast)---------------------------
> TIP 5: Have you checked our extensive FAQ?
> 
>                http://www.postgresql.org/docs/faqs/FAQ.html

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Re: buglet in 7.1.4

Neil Conway <neilc@samurai.com> — 2004-03-09T14:29:20Z

Bruce Momjian wrote:
> Yea, we probably aren't releasing any more 7.1.X releases though.

Perhaps it is worth applying to the 7.1 CVS branch, at least?

BTW, I can't really see the harm in putting out 7.1.x and 7.2.x 
releases to fix compilation issues on modern systems. For example, I 
believe that 7.2.4 doesn't compile on RH9+, due to a minor infelicity 
in 'errno' usage in copy.c -- it is fixed in the 7.2 CVS branch, but 
hasn't been included in a 7.2.x release.

-Neil

Re: buglet in 7.1.4

Chris Browne <cbbrowne@acm.org> — 2004-03-09T15:28:01Z

Martha Stewart called it a Good Thing when neilc@samurai.com (Neil Conway) wrote:
> Bruce Momjian wrote:
>> Yea, we probably aren't releasing any more 7.1.X releases though.
>
> Perhaps it is worth applying to the 7.1 CVS branch, at least?
>
> BTW, I can't really see the harm in putting out 7.1.x and 7.2.x
> releases to fix compilation issues on modern systems. For example, I
> believe that 7.2.4 doesn't compile on RH9+, due to a minor
> infelicity in 'errno' usage in copy.c -- it is fixed in the 7.2 CVS
> branch, but hasn't been included in a 7.2.x release.

I recently found a similar "infelicity" with 7.1.4 on RH8, resulting
from the fact that modern versions of gcc generate multiple lines of
output from gcc -v, whereas the configure script expects only one.
This leads to quite spectacular breakage of the compile process, as
configure gets very confused...
-- 
output = reverse("gro.mca" "@" "enworbbc")
http://www3.sympatico.ca/cbbrowne/finances.html
"Put simply, the antitrust laws in this country are basically a joke,
protecting us just enough to not have to re-name our park service the
Phillip Morris National Park Service." 
-- Courtney Love, Salon.com, June 14, 2000

Re: buglet in 7.1.4

Tom Lane <tgl@sss.pgh.pa.us> — 2004-03-09T15:46:10Z

Neil Conway <neilc@samurai.com> writes:
> BTW, I can't really see the harm in putting out 7.1.x and 7.2.x 
> releases to fix compilation issues on modern systems.

The "harm" is the developer time spent on doing so.  Releasing back
versions takes nontrivial effort (witness what it took to get 7.3.6
out the door :-().

Also, quite frankly, I don't want to encourage people to keep using
such old releases.  If they are installing on a new machine they should
update to something newer and less buggy.

			regards, tom lane

Re: buglet in 7.1.4

Lamar Owen <lowen@pari.edu> — 2004-03-09T15:57:12Z

On Tuesday 09 March 2004 10:46 am, Tom Lane wrote:
> Neil Conway <neilc@samurai.com> writes:
> > BTW, I can't really see the harm in putting out 7.1.x and 7.2.x
> > releases to fix compilation issues on modern systems.
> Also, quite frankly, I don't want to encourage people to keep using
> such old releases.  If they are installing on a new machine they should
> update to something newer and less buggy.

We need the older versions to be compilable on newer systems to ease in 
version upgrades and migration.
-- 
Lamar Owen
Director of Information Technology
Pisgah Astronomical Research Institute
1 PARI Drive
Rosman, NC  28772
(828)862-5554
www.pari.edu

Re: buglet in 7.1.4

Mike Mascari <mascarm@mascari.com> — 2004-03-09T16:40:14Z

Lamar Owen wrote:

> On Tuesday 09 March 2004 10:46 am, Tom Lane wrote:
> 
>>Neil Conway <neilc@samurai.com> writes:
>>
>>>BTW, I can't really see the harm in putting out 7.1.x and 7.2.x
>>>releases to fix compilation issues on modern systems.
>>
>>Also, quite frankly, I don't want to encourage people to keep using
>>such old releases.  If they are installing on a new machine they should
>>update to something newer and less buggy.
> 
> We need the older versions to be compilable on newer systems to ease in 
> version upgrades and migration.

How could they find themselves in a situation where they have a 7.1 
installation that requires dumping for migration, but no binaries 
due to compilation errors? Isn't that a rather low-probability scenario?

Mike Mascari

Re: buglet in 7.1.4

Chris Browne <cbbrowne@acm.org> — 2004-03-09T20:52:12Z

A long time ago, in a galaxy far, far away, mascarm@mascari.com (Mike Mascari) wrote:
> Lamar Owen wrote:
>
>> On Tuesday 09 March 2004 10:46 am, Tom Lane wrote:
>>
>>>Neil Conway <neilc@samurai.com> writes:
>>>
>>>>BTW, I can't really see the harm in putting out 7.1.x and 7.2.x
>>>>releases to fix compilation issues on modern systems.
>>>
>>>Also, quite frankly, I don't want to encourage people to keep using
>>>such old releases.  If they are installing on a new machine they should
>>>update to something newer and less buggy.
>> We need the older versions to be compilable on newer systems to ease
>> in version upgrades and migration.
>
> How could they find themselves in a situation where they have a 7.1
> installation that requires dumping for migration, but no binaries due
> to compilation errors? Isn't that a rather low-probability scenario?

The problem isn't so much that of "complete inability" to get
binaries, but rather of it becoming significantly inconvenient to get
those binaries.

What if we had a RHAT 6.3 system running PG 7.1, and the "system"
partition got dumped on?  We have the data directory; we'd like to
mount it on a spicy new RHAT 8.0 system, and recover it.

If I rummage around looking for tips, I can doubtless discover the set
of things that need to get patched in order to recompile on RHAT 8.0;
it sure would be nice to not have to rummage round for them.
-- 
wm(X,Y):-write(X),write('@'),write(Y). wm('cbbrowne','cbbrowne.com').
http://www3.sympatico.ca/cbbrowne/sgml.html
"The beginning of wisdom for a [software engineer] is to recognize the
difference between getting a program  to work, and getting it  right."
-- M A Jackson, 1975

Re: buglet in 7.1.4

Neil Conway <neilc@samurai.com> — 2004-03-09T22:30:31Z

Tom Lane wrote:
> The "harm" is the developer time spent on doing so.  Releasing back
> versions takes nontrivial effort (witness what it took to get 7.3.6
> out the door :-().

True; that said, much of this overhead is (IMHO) avoidable. There 
should be little or no manual intervention needed in the release 
process, so if the code in the REL7_1_STABLE branch is 'release 
quality', there shouldn't be that much work needed to issue an 
additional release.

But yes, I agree: developer time is finite, and we should focus most 
of it on 7.4.x and 7.5

> Also, quite frankly, I don't want to encourage people to keep using
> such old releases.  If they are installing on a new machine they should
> update to something newer and less buggy.

I agree, but there are some plausible uses for installing old releases 
on new machines. For example, there are probably commercial or 
unmaintained legacy applications that will only work smoothly with 7.1 
(or some other old release). Similarly, an application developer may 
wish to ensure that their application is portable among the most 
recent 'x' Postgres releases, and want to install copies of them for 
testing. Or a production environment may wish to install an identical 
version of PG on all their machines, so they might be forced to run a 
fairly old release on newly-purchased machines.

So I think there are legitimate, albeit somewhat obscure, reasons for 
running an old release on a relatively modern system.

-Neil

Re: buglet in 7.1.4

Tom Lane <tgl@sss.pgh.pa.us> — 2004-03-09T22:44:18Z

Neil Conway <neilc@samurai.com> writes:
> Tom Lane wrote:
>> The "harm" is the developer time spent on doing so.  Releasing back
>> versions takes nontrivial effort (witness what it took to get 7.3.6
>> out the door :-().

> True; that said, much of this overhead is (IMHO) avoidable. There 
> should be little or no manual intervention needed in the release 
> process, so if the code in the REL7_1_STABLE branch is 'release 
> quality', there shouldn't be that much work needed to issue an 
> additional release.

That's the theory, but reality is different.  Sure, the bits in CVS are
static, but the environment in which the release package gets built
isn't so static.  (I believe that's what bit us for 7.3.6.)  Outfits
that maintain back versions spend large amounts of money and manpower
on making sure they can reproduce old build environments.  We don't have
that kind of infrastructure.

Basically my feeling about this is that PGDG is a *development*
community, and that's what we ought to focus our effort on doing.  There
are other groups (Red Hat, Mammoth, possibly SRA) that are better suited
to handle maintenance of old versions.  And yes, they charge money for
what they do.  That's because there are very real costs involved.
I don't want to see PGDG putting our limited developer manpower into it.

			regards, tom lane