Thread: Fast request for version checking....
Folks, if you go to the root of your postgresql distro and type ./configure --version what version of AutoConf was used? thanks! --Ross
"Mohan, Ross" <RMohan@arbinet.com> writes:
> if you go to the root of your postgresql distro
> and type
> ./configure --version
> what version of AutoConf was used?
For any reasonably recent PG release, it will be 2.53 if built from
source. Some RPM distributions may have re-autoconf'd though (I think
Red Hat is currently using 2.59, for instance).
regards, tom lane
I have 2.53, yes.
But, I am going to rebuild and re-AC this, so need
to build m4 (1.4.3) in order to get to 2.59 of AConf.
Any reasons to strongly advocate or avoid forcing
compiler into strict ANSI/C99 or ISO C mode? I had
to do that to get m4 to compile. I'd like to stay
on a single track (ANSI compliant or not) with all
builds.
An RTFM pointer to a doc would be more than ample,
if such explanation already exists!
Thanks!!
-----Original Message-----
From: Tom Lane [mailto:tgl@sss.pgh.pa.us]
Sent: Fri 27-May-05 8:35 PM
To: Mohan, Ross
Cc: pgsql-general@postgresql.org
Subject: Re: [GENERAL] Fast request for version checking....
"Mohan, Ross" <RMohan@arbinet.com> writes:
> if you go to the root of your postgresql distro
> and type
> ./configure --version
> what version of AutoConf was used?
For any reasonably recent PG release, it will be 2.53 if built from
source. Some RPM distributions may have re-autoconf'd though (I think
Red Hat is currently using 2.59, for instance).
regards, tom lane
Mohan, Ross wrote: > Any reasons to strongly advocate or avoid forcing > compiler into strict ANSI/C99 or ISO C mode? I had > to do that to get m4 to compile. I'd like to stay > on a single track (ANSI compliant or not) with all > builds. If you need to build m4 then you should ask there on how to do that. We have absolutely nothing to do with that. -- Peter Eisentraut http://developer.postgresql.org/~petere/
Oops! RMohan@arbinet.com ("Mohan, Ross") was seen spray-painting on a wall:
> I have 2.53, yes.
>
> But, I am going to rebuild and re-AC this, so need
> to build m4 (1.4.3) in order to get to 2.59 of AConf.
>
> Any reasons to strongly advocate or avoid forcing
> compiler into strict ANSI/C99 or ISO C mode? I had
> to do that to get m4 to compile. I'd like to stay
> on a single track (ANSI compliant or not) with all
> builds.
>
> An RTFM pointer to a doc would be more than ample,
> if such explanation already exists!
There is no such explanation/document to be found, as the different
pieces of software you are building are managed by completely
independent groups of people.
PGDG (the folks responsible for PostgreSQL) are, at least at the Core
level, a disjoint set from the set of developers associated with FSF
m4.
There is little reason to expect any comprehensive sort of consistency
of the manner you suggest, nor that it is particularly useful, either.
- When you're looking at something like PostgreSQL, where there needs
to be some intimacy with system level details, it's quite likely
that there will need to be some weird things turned on.
For instance, you're liable to find a need to enable thread safety
on platforms like AIX and Solaris, even though that can Lead To
Certain Complications.
- In contrast, m4 is being used for relatively simple purposes, during
the build process, so that "weirdities" like threading are pretty
well irrelevant to compiling m4.
Indeed, it would be quite appropriate for an m4 build to use pretty
"anal-retentively" standards-compliant options, and it might even be
appropriate to ignore platform-specific stuff like optimization.
After all, the m4 code only runs at compile time, and if that slows
down a bit, or even a lot, that will not have any effect on the
efficiency of the resulting PostgreSQL binaries.
While it would be convenient if all software projects played by
exactly the same set of "how to use compiler options" rules, it is
completely unrealistic to expect this.
--
let name="cbbrowne" and tld="gmail.com" in String.concat "@" [name;tld];;
http://linuxdatabases.info/info/slony.html
And me, with this terrible pain in all the diodes down my left side...
-- Marvin the Paranoid Android
Chris,
Thanks for taking the time for a thoughtful response. Once
again, I am educated on this list....
I was a bit unclear in original post -- while I *am* planning
on stabilizing my build environment (updating m4, autoconf,
compiler, discovering c/cpp/ld flags, etc) my final goal
is a (re-)buildable, maintainable PG8.* on AIX5.3
This is a lot of fun, but "stumbly" work for me, because I
have never been a C programmer (or anything but PL/SQL
for oracle, really) and while fascinated by compiler
theory, technology, and implementation, I am even
less familiar with that. Hence the "out of place"
questions.
I'll examine threadsafety, compiler options, and
hetergeneous compiler/build enviroments.
Thanks again
Ross
-----Original Message-----
From: pgsql-general-owner@postgresql.org on behalf of Christopher Browne
Sent: Sat 28-May-05 11:37 PM
To: pgsql-general@postgresql.org
Cc:
Subject: Re: [GENERAL] Fast request for version checking....
Oops! RMohan@arbinet.com ("Mohan, Ross") was seen spray-painting on a wall:
> I have 2.53, yes.
>
> But, I am going to rebuild and re-AC this, so need
> to build m4 (1.4.3) in order to get to 2.59 of AConf.
>
> Any reasons to strongly advocate or avoid forcing
> compiler into strict ANSI/C99 or ISO C mode? I had
> to do that to get m4 to compile. I'd like to stay
> on a single track (ANSI compliant or not) with all
> builds.
>
> An RTFM pointer to a doc would be more than ample,
> if such explanation already exists!
There is no such explanation/document to be found, as the different
pieces of software you are building are managed by completely
independent groups of people.
PGDG (the folks responsible for PostgreSQL) are, at least at the Core
level, a disjoint set from the set of developers associated with FSF
m4.
There is little reason to expect any comprehensive sort of consistency
of the manner you suggest, nor that it is particularly useful, either.
- When you're looking at something like PostgreSQL, where there needs
to be some intimacy with system level details, it's quite likely
that there will need to be some weird things turned on.
For instance, you're liable to find a need to enable thread safety
on platforms like AIX and Solaris, even though that can Lead To
Certain Complications.
- In contrast, m4 is being used for relatively simple purposes, during
the build process, so that "weirdities" like threading are pretty
well irrelevant to compiling m4.
Indeed, it would be quite appropriate for an m4 build to use pretty
"anal-retentively" standards-compliant options, and it might even be
appropriate to ignore platform-specific stuff like optimization.
After all, the m4 code only runs at compile time, and if that slows
down a bit, or even a lot, that will not have any effect on the
efficiency of the resulting PostgreSQL binaries.
While it would be convenient if all software projects played by
exactly the same set of "how to use compiler options" rules, it is
completely unrealistic to expect this.
--
let name="cbbrowne" and tld="gmail.com" in String.concat "@" [name;tld];;
http://linuxdatabases.info/info/slony.html
And me, with this terrible pain in all the diodes down my left side...
-- Marvin the Paranoid Android
---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster
A long time ago, in a galaxy far, far away, RMohan@arbinet.com ("Mohan, Ross") wrote:
> Thanks for taking the time for a thoughtful response. Once
> again, I am educated on this list....
>
> I was a bit unclear in original post -- while I *am* planning on
> stabilizing my build environment (updating m4, autoconf, compiler,
> discovering c/cpp/ld flags, etc) my final goal is a (re-)buildable,
> maintainable PG8.* on AIX5.3
I'm happy if I can save you from wasting time trying to do the
impossible (namely to find consistency where it isn't to be found).
> This is a lot of fun, but "stumbly" work for me, because I have
> never been a C programmer (or anything but PL/SQL for oracle,
> really) and while fascinated by compiler theory, technology, and
> implementation, I am even less familiar with that. Hence the "out of
> place" questions.
AIX is definitely more of a circus than, say, Linux.
I'd not be surprised if it becomes a worthwhile idea in the not too
distant future to look at running Linux on the higher end pSeries
hardware instead of AIX. I'm certain that would make most of the
challenges go away.
IBM would be keen to sell pSeries hardware running Linux, too; the
drawback at this point is that it's not clear that the more esoteric
high performance hardware will work with Linux yet. They don't have
HACMP for Linux yet, for instance, and support for high end disk
controllers and such may yet be limited.
> I'll examine threadsafety, compiler options, and hetergeneous
> compiler/build enviroments.
We'll be looking at some of the same fairly shortly, as we're
receiving some AIX 5.3 systems.
As issues come, that will no doubt feed back somewhat to the FAQ_AIX
document.
One thing worth checking on... Are you a VisualAge C user? Or do you
wind up using GCC? We're using GCC, which definitely plays a little
different than VAC...
--
"cbbrowne","@","gmail.com"
http://cbbrowne.com/info/lsf.html
"Problem solving under linux has never been the circus that it is
under AIX." -- Pete Ehlke in comp.unix.aix
"Whip me. Beat me. Make me maintain AIX." -- Stephan Zielinski