Thread: Autoconf version discrepancies

Autoconf version discrepancies

From
Peter Eisentraut
Date:
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/



Re: Autoconf version discrepancies

From
Bruce Momjian
Date:
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,
Pennsylvania19026
 


Re: Autoconf version discrepancies

From
Peter Eisentraut
Date:
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.

-- 
Peter Eisentraut      peter_e@gmx.net       http://yi.org/peter-e/



Re: Autoconf version discrepancies

From
Vince Vielhaber
Date:
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.net128K ISDN from $22.00/mo - 56K Dialup from
$16.00/moat Pop4 Networking       Online Campground Directory    http://www.camping-usa.com      Online Giftshop
Superstore   http://www.cloudninegifts.com
 
==========================================================================





Re: Autoconf version discrepancies

From
Bruce Momjian
Date:
> 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,
Pennsylvania19026
 


Re: Autoconf version discrepancies

From
Peter Eisentraut
Date:
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/



Re: Autoconf version discrepancies

From
Bruce Momjian
Date:
> 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,
Pennsylvania19026
 


Re: Autoconf version discrepancies

From
Tom Lane
Date:
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


Re: Autoconf version discrepancies

From
Matthew Kirkwood
Date:
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.



Re: Autoconf version discrepancies

From
The Hermit Hacker
Date:
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





Re: Autoconf version discrepancies

From
The Hermit Hacker
Date:
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 ...






Re: Autoconf version discrepancies

From
The Hermit Hacker
Date:
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? :(




Re: Autoconf version discrepancies

From
Patrick Welche
Date:
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
conditionin the time between the generation of a tempo-    rary filename by mktemp() and the invoker's use of the
temporaryname.  A    link-time warning will be issued advising the use of mkstemp() or    mkdtemp() instead.
 

Cheers,

Patrick