Autoconf version discrepancies
I have noticed that some operating system distributors ship custom-patched
versions of Autoconf. That is pretty brain-dead because some of the
changes make things work worse on other systems.
Therefore I would recommend that everybody install the original
autoconf-2.13.tar.gz from GNU and not use anything that comes with their
operating system. That includes the installation on hub.org.
--
Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/
I always telnet into hub to run autoconf. I have a little script in my
~momjian/bin directory called pgautoconf that does that, and cvs commits
the changes.
I have noticed that some operating system distributors ship custom-patched
versions of Autoconf. That is pretty brain-dead because some of the
changes make things work worse on other systems.Therefore I would recommend that everybody install the original
autoconf-2.13.tar.gz from GNU and not use anything that comes with their
operating system. That includes the installation on hub.org.--
Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026Bruce Momjian writes:
I always telnet into hub to run autoconf. I have a little script in my
~momjian/bin directory called pgautoconf that does that, and cvs commits
the changes.
That's exactly the problem, the version on hub.org is custom-patched for
FreeBSD and has significant loser potential on other platforms.
And really, there's no need to do that either, if you install the original
GNU tarball locally.
--
Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/
On Tue, 3 Oct 2000, Peter Eisentraut wrote:
Bruce Momjian writes:
I always telnet into hub to run autoconf. I have a little script in my
~momjian/bin directory called pgautoconf that does that, and cvs commits
the changes.That's exactly the problem, the version on hub.org is custom-patched for
FreeBSD and has significant loser potential on other platforms.And really, there's no need to do that either, if you install the original
GNU tarball locally.
An upgrade must have replaced it then 'cuze I built 2.13 from original
sources back in April '99 and Marc installed it on hub.
Marc it's in my autoconf directory if you want to reinstall it. I just
remade it so it's current to this version of the OS.
Vince.
--
==========================================================================
Vince Vielhaber -- KA8CSH email: vev@michvhf.com http://www.pop4.net
128K ISDN from $22.00/mo - 56K Dialup from $16.00/mo at Pop4 Networking
Online Campground Directory http://www.camping-usa.com
Online Giftshop Superstore http://www.cloudninegifts.com
==========================================================================
Bruce Momjian writes:
I always telnet into hub to run autoconf. I have a little script in my
~momjian/bin directory called pgautoconf that does that, and cvs commits
the changes.That's exactly the problem, the version on hub.org is custom-patched for
FreeBSD and has significant loser potential on other platforms.And really, there's no need to do that either, if you install the original
GNU tarball locally.
Good point. I think autoconf is run as part of the tarball creation, so
we had better have the right version on hub. Personally, I prefer to
use a version on hub because it is the official one for PostgreSQL.
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026
On Tue, 3 Oct 2000, Peter Eisentraut wrote:
Bruce Momjian writes:
I always telnet into hub to run autoconf. I have a little script in my
~momjian/bin directory called pgautoconf that does that, and cvs commits
the changes.That's exactly the problem, the version on hub.org is custom-patched for
FreeBSD and has significant loser potential on other platforms.
Okay, autoconf on hub.org is based on what is in ports ... the only
"custom patches" are that which are in /usr/ports/devel/autoconf/patches,
and I just went through them and there doesn't look like anything *odd* in
there ... can you look at those patches and tell me which one is screwing
things up for you, that I'm not seeing? :(
The Hermit Hacker writes:
Okay, autoconf on hub.org is based on what is in ports ... the only
"custom patches" are that which are in /usr/ports/devel/autoconf/patches,
and I just went through them and there doesn't look like anything *odd* in
there ... can you look at those patches and tell me which one is screwing
things up for you, that I'm not seeing? :(
The patches ad, ae, and af will cause configure to fail on machines
without mktemp. It's not like things get "screwed up" for me, but the
point of Autoconf is portability to *all* machines, so FreeBSD-specific
changes/optimizations(?) seem misplaced.
--
Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/
The Hermit Hacker writes:
Okay, autoconf on hub.org is based on what is in ports ... the only
"custom patches" are that which are in /usr/ports/devel/autoconf/patches,
and I just went through them and there doesn't look like anything *odd* in
there ... can you look at those patches and tell me which one is screwing
things up for you, that I'm not seeing? :(The patches ad, ae, and af will cause configure to fail on machines
without mktemp. It's not like things get "screwed up" for me, but the
point of Autoconf is portability to *all* machines, so FreeBSD-specific
changes/optimizations(?) seem misplaced.
Are there any platforms that do not have mktemp? Hard to imagine.
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026
Bruce Momjian <pgman@candle.pha.pa.us> writes:
The patches ad, ae, and af will cause configure to fail on machines
without mktemp. It's not like things get "screwed up" for me, but the
point of Autoconf is portability to *all* machines, so FreeBSD-specific
changes/optimizations(?) seem misplaced.
Are there any platforms that do not have mktemp? Hard to imagine.
Not hard at all, considering that mktemp(1) is defined by no standard
according to the references I have handy.
More generally, I have to side with Peter on this: local patches to
Autoconf are a fine example of Missing The Point. The output script
has to run everywhere, not only on your own platform.
Also, we not long ago went through the exercise of making sure that all
committers were standardized on the same version of Autoconf, ie, 2.13.
Now it emerges that hub.org is running a NON STANDARD version of
Autoconf: 2.13 + unspecified BSD-originated hacks. So the output is
likely to change depending on who committed last and where they did it
from.
This will not do. Please fix hub's copy of Autoconf.
regards, tom lane
On Sun, 8 Oct 2000, Bruce Momjian wrote:
Are there any platforms that do not have mktemp? Hard to imagine.
mktemp(1) or mktemp(3)?
The latter is pretty much universal (and dangerous too).
The former is, AFAICS, available only on some Linux and BSD.
But it's under the BSD licence, and is not a long program.
For portability's sake, it may be easier just to include it
in the distribution.
Matthew.
On Sun, 8 Oct 2000, Peter Eisentraut wrote:
The Hermit Hacker writes:
Okay, autoconf on hub.org is based on what is in ports ... the only
"custom patches" are that which are in /usr/ports/devel/autoconf/patches,
and I just went through them and there doesn't look like anything *odd* in
there ... can you look at those patches and tell me which one is screwing
things up for you, that I'm not seeing? :(The patches ad, ae, and af will cause configure to fail on machines
without mktemp. It's not like things get "screwed up" for me, but the
point of Autoconf is portability to *all* machines, so FreeBSD-specific
changes/optimizations(?) seem misplaced.
okay, I just looked through those patches, and all they are doing is
changing the use of $$ to use the process id as a temp file name to using
'mktemp' ... have we had any reports of this breaking anything on any of
the platforms we support? If so, then I agree this is a bad thing, if
not, I'm curious as to why this has suddenly become a problem since we've
been using this autoconf since March 8:
-rwxr-xr-x 1 root wheel 4987 Mar 8 2000 /usr/local/bin/autoconf
On Sun, 8 Oct 2000, Tom Lane wrote:
Bruce Momjian <pgman@candle.pha.pa.us> writes:
The patches ad, ae, and af will cause configure to fail on machines
without mktemp. It's not like things get "screwed up" for me, but the
point of Autoconf is portability to *all* machines, so FreeBSD-specific
changes/optimizations(?) seem misplaced.Are there any platforms that do not have mktemp? Hard to imagine.
Not hard at all, considering that mktemp(1) is defined by no standard
according to the references I have handy.More generally, I have to side with Peter on this: local patches to
Autoconf are a fine example of Missing The Point. The output script
has to run everywhere, not only on your own platform.Also, we not long ago went through the exercise of making sure that all
committers were standardized on the same version of Autoconf, ie, 2.13.
Now it emerges that hub.org is running a NON STANDARD version of
Autoconf: 2.13 + unspecified BSD-originated hacks. So the output is
likely to change depending on who committed last and where they did it
from.
Take a look at the patches that I pointed Peter at for these "Unspecified"
patches. The ones that Peter points out merely change from using .$$ to
stipulate the temp file name to using 'mktemp' ...
Now, what I'd be curious about is what platforms this does break things
on, cause if it does, it kinda makes using FreeBSD's autoconf difficult
for non-FreeBSD developments, about as difficult as some of the
Linux-centric ones that we try to port to FreeBSD ...
Basically, what benefits are there to using 'mktemp' over using the shell
based '.$$', and do those developing software under *BSD then break
themselves for other platforms as a result (or force other platforms to
run autoconf to build)?
If using mktemp doesn't break any platform, this is a moot point ... if it
does, then I think it is something that *has* to be fix in the FreeBSD
port itself so that it doesn't make us look FreeBSD-centric in our
development efforts on any other package ...
On Mon, Oct 09, 2000 at 04:11:20PM -0300, The Hermit Hacker wrote:
On Sun, 8 Oct 2000, Tom Lane wrote:
...
Also, we not long ago went through the exercise of making sure that all
committers were standardized on the same version of Autoconf, ie, 2.13.
Now it emerges that hub.org is running a NON STANDARD version of
Autoconf: 2.13 + unspecified BSD-originated hacks. So the output is
likely to change depending on who committed last and where they did it
from.
...
If using mktemp doesn't break any platform, this is a moot point ... if it
does, then I think it is something that *has* to be fix in the FreeBSD
port itself so that it doesn't make us look FreeBSD-centric in our
development efforts on any other package ...
To flog an already dead horse (then again my posts get stalled, so 8 Oct mail
isn't that late :-) (whatever happenend to pgsql-loophole) )
SECURITY CONSIDERATIONS
The use of mktemp() should generally be avoided, as a hostile process can
exploit a race condition in the time between the generation of a tempo-
rary filename by mktemp() and the invoker's use of the temporary name. A
link-time warning will be issued advising the use of mkstemp() or
mkdtemp() instead.
Cheers,
Patrick