Обсуждение: 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, Pennsylvania19026
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/
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 ==========================================================================
> 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
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, Pennsylvania19026
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 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? :(
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