Обсуждение: buglet in 7.1.4
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 -- ---------------------------------------------------------------------
Вложения
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
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
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
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
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
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
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
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
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