Thread: AW: AW: AW: Re: tinterval - operator problems on AIX

AW: AW: AW: Re: tinterval - operator problems on AIX

From
Zeugswetter Andreas SB
Date:
> > > > > Yes, the annoyance is, that localtime works for dates before 1970
> > > > > but mktime doesn't. Best would probably be to assume no DST before
> > > > > 1970 on AIX and IRIX.
> > > > 
> > > > That seems like a reasonable answer to me, especially since we have
> > > > other platforms that behave that way.  How can we do this --- just
> > > > test for isdst = -1 after the call, and assume that means failure?

Here is a patch that is incremental to the previous patch and makes AIX
not use DST before 1970. The results are now consistent with other 
no-DST-before-1970 platforms.

The down side is, that I did not do a configure test, and did not incooperate
IRIX, since I didn't know what define to check.

The correct thing to do instead of the #if defined (_AIX) would be to use
something like #ifdef NO_NEGATIVE_MKTIME and set that with a configure.
Thomas, are you volunteering ?

Andreas


Re: AW: AW: AW: Re: tinterval - operator problems on AIX

From
Thomas Lockhart
Date:
> The correct thing to do instead of the #if defined (_AIX) would be to use
> something like #ifdef NO_NEGATIVE_MKTIME and set that with a configure.
> Thomas, are you volunteering ?

Actually, I can volunteer to be supportive of your efforts ;) I'm
traveling at the moment, and don't have the original thread(s) which
describe in detail what we need to do for platforms I don't have.

If Peter E. would be willing to do a configure test for this mktime()
problem, then you or I can massage the actual code. Peter, is this
something you could pick up?

I do not have the original thread where Andreas describes the behavior
of mktime() on his machine. Andreas, can you suggest a simple configure
test to be used?
                     - Thomas


Re: AW: AW: AW: Re: tinterval - operator problems on AIX

From
Pete Forman
Date:
Zeugswetter Andreas SB writes:> The down side is, that I did not do a configure test, and did not> incooperate IRIX,
sinceI didn't know what define to check.> > The correct thing to do instead of the #if defined (_AIX) would be> to use
somethinglike #ifdef NO_NEGATIVE_MKTIME and set that with a> configure.
 

I agree that configure is the way to go.  What if someone has
installed a third party library to provide a better mktime() and
localtime()?

But to answer your question, #if defined (__sgi) is a good test for
IRIX, at least with the native compiler.  I can't speak for gcc.
-- 
Pete Forman                 -./\.- Disclaimer: This post is originated
WesternGeco                   -./\.-  by myself and does not represent
pete.forman@westerngeco.com     -./\.-  opinion of Schlumberger, Baker
http://www.crosswinds.net/~petef  -./\.-  Hughes or their divisions.


Re: AW: AW: AW: Re: tinterval - operator problems on AIX

From
Peter Eisentraut
Date:
Pete Forman writes:

> I agree that configure is the way to go.  What if someone has
> installed a third party library to provide a better mktime() and
> localtime()?

Exactly.  What if someone has a binary PostgreSQL package installed, then
updates his time library to something supposedly binary compatible and
finds out that PostgreSQL still doesn't use the enhanced capabilities?
Runtime behaviour checks are done at runtime, it's as simple as that.

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



Re: AW: AW: AW: Re: tinterval - operator problems on AIX

From
Thomas Lockhart
Date:
> Exactly.  What if someone has a binary PostgreSQL package installed, then
> updates his time library to something supposedly binary compatible and
> finds out that PostgreSQL still doesn't use the enhanced capabilities?
> Runtime behaviour checks are done at runtime, it's as simple as that.

I'm not sure I fully appreciate the distinction here. configure will
check for "behavior" of various kinds, including "behavior assumptions"
in the PostgreSQL code.

So the issue for this case is simply whether it is appropriate to check
for behavior at run time on all platforms, even those known to "never"
exhibit this problematic result, or whether we put in a configure-time
check to save the day for the (two) platforms known to have trouble --
without the other supported platforms taking the hit by having to check
even though the check will never fail.

Andreas, Pete and I were advocating the latter view: that the majority
of platforms which happen to be well behaved should run code optimized
for them, while the bad actors can be supported without "#ifdef __AIX__
|| __IRIX__" in our code, but rather with a more helpful "#ifdef
NO_DST_BEFORE_1970" or whatever.
                   - Thomas


Re: AW: AW: AW: Re: tinterval - operator problems on AIX

From
Peter Eisentraut
Date:
Thomas Lockhart writes:

> I'm not sure I fully appreciate the distinction here. configure will
> check for "behavior" of various kinds, including "behavior assumptions"
> in the PostgreSQL code.

There are two general categories of platform dependencies:  One is
compilation system features, for example presence of certain functions,
libraries, header files, argument types, compiler flags.  These sort of
things must be determined before compilation can begin.  Autoconf is used
to test for these things.

The other category is run-time behaviour, which is the present case of
testing whether mktime() behaves a certain way when given certain
arguments.  Another item that has been thrown around over the years is
whether the system supports Unix domain sockets (essentially a run-time
behaviour check of socket()).  You do not need to check these things in
configure; you can just do it when the program runs and adjust
accordingly.

More importantly, you *should* *not* do these tests in configure because
these tests will be unreliable in a cross-compilation situation.
Cross-compilation in this context does not only mean compiling between
completely different platforms, but it includes any setup where the build
system is configured differently from the system you're going to run the
system on, including building on a noexec file system, misconfigured
run-time linkers, different user id, or just a different file system
layout on an otherwise identical platform.

I'm not making these things up.  Just yesterday there was a message on
this list where someone ran into this problem and his configure run
misbehaved badly.  (PostgreSQL currently violates these rules, but that
does not mean that we should make it harder now to clean it up at some
later date.)  Admittedly, these situations sound somewhat exotic, but that
does not mean they do not happen, it may merely mean that PostgreSQL is
not fit to perform in these situations.

> So the issue for this case is simply whether it is appropriate to check
> for behavior at run time on all platforms, even those known to "never"
> exhibit this problematic result,

You can make the run-time check #ifdef one or the other platform.  Or you
don't check at all and just postulate the misfeature for a set of
platforms.  We have done this in at least two cases:  The list of
platforms known not to support Unix domain sockets (HAVE_UNIX_SOCKETS),
and the list of platforms known to have a peculiar bug in the accept()
implementation (happen to be both from SCO).  I think this is an
appropriate solution in cases where the affected systems can be classified
easily.  But as soon as some versions of some of these systems start
implementing Unix sockets (which is indeed the situation we're currently
facing) or SCO fixes their kernels we're going to have to think harder.

So I would currently suggest that you define

#ifdef AIX || IRIX
# define NO_DST_BEFORE_1970
#endif

but when these systems get fixed you might have to run a simple check once
when the system starts up.  This is not really a "hit".

> Andreas, Pete and I were advocating the latter view: that the majority
> of platforms which happen to be well behaved should run code optimized
> for them, while the bad actors can be supported without "#ifdef __AIX__
> || __IRIX__" in our code, but rather with a more helpful "#ifdef
> NO_DST_BEFORE_1970" or whatever.

Yeah.

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



Re: AW: AW: AW: Re: tinterval - operator problems on AIX

From
Ian Lance Taylor
Date:
Peter Eisentraut <peter_e@gmx.net> writes:

> More importantly, you *should* *not* do these tests in configure because
> these tests will be unreliable in a cross-compilation situation.
> Cross-compilation in this context does not only mean compiling between
> completely different platforms, but it includes any setup where the build
> system is configured differently from the system you're going to run the
> system on, including building on a noexec file system, misconfigured
> run-time linkers, different user id, or just a different file system
> layout on an otherwise identical platform.

An approach I've followed in the past is to use three-way logic.  If
configuring for a native system, compile and run a program which
provides a yes or no answer.  When using cross-configuration, set the
configuration variable to ``don't know'' (or, since this a database
group, NULL).

Pull all code which needs to make this test into a single routine.
Let it check the configuration variable.  If the variable is ``don't
know,'' then compile in a static variable, and run the required test
once, at run time, and set the static variable accordingly.  Then test
the static variable in all future calls.

This is the approach I used in my UUCP code to look for a bad version
of ftime on some versions of SCO Unix--the ftime result would
sometimes run backward.

Ian
Co-author of GNU Autoconf, Automake, and Libtool


Re: AW: AW: AW: Re: tinterval - operator problems on AIX

From
Peter Eisentraut
Date:
Ian Lance Taylor writes:

> An approach I've followed in the past is to use three-way logic.  If
> configuring for a native system, compile and run a program which
> provides a yes or no answer.  When using cross-configuration, set the
> configuration variable to ``don't know'' (or, since this a database
> group, NULL).

This would seem to be the right answer, but unfortunately Autoconf is not
smart enough to detect marginal cross-compilation cases in all situations.
Someone had zlib installed in a location where gcc would find it (compiles
okay) but the run-time linker would not (does not run).  This is not
detected when AC_PROG_CC runs, but only later on after you have checked
for the libraries.

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



Re: AW: AW: AW: Re: tinterval - operator problems on AIX

From
Ian Lance Taylor
Date:
Peter Eisentraut <peter_e@gmx.net> writes:

> Ian Lance Taylor writes:
> 
> > An approach I've followed in the past is to use three-way logic.  If
> > configuring for a native system, compile and run a program which
> > provides a yes or no answer.  When using cross-configuration, set the
> > configuration variable to ``don't know'' (or, since this a database
> > group, NULL).
> 
> This would seem to be the right answer, but unfortunately Autoconf is not
> smart enough to detect marginal cross-compilation cases in all situations.
> Someone had zlib installed in a location where gcc would find it (compiles
> okay) but the run-time linker would not (does not run).  This is not
> detected when AC_PROG_CC runs, but only later on after you have checked
> for the libraries.

Hmmm.  I would not describe that as a cross-compilation case at all.
The build machine and the host machine are the same.  I would describe
that as a case where the compiler search path and the run time library
search path are not the same.

The autoconf tests don't use any extra libraries, so any discrepancies
of this sort should not matter to them.  Autoconf tests whether it can
compile and run a simple program; if it can, it assumes that it is not
in a cross-compilation situation.

Clearly differences between search paths matter, but they are not the
same as cross-compilation.

Ian


Re: AW: AW: AW: Re: tinterval - operator problems on AIX

From
Peter Eisentraut
Date:
Ian Lance Taylor writes:

> > This would seem to be the right answer, but unfortunately Autoconf is not
> > smart enough to detect marginal cross-compilation cases in all situations.
> > Someone had zlib installed in a location where gcc would find it (compiles
> > okay) but the run-time linker would not (does not run).  This is not
> > detected when AC_PROG_CC runs, but only later on after you have checked
> > for the libraries.
>
> Hmmm.  I would not describe that as a cross-compilation case at all.
> The build machine and the host machine are the same.

Only for small values of "same". ;-)  Sameness is not defined by the names
being spelled identically or the physical coincidence of the hardware.
There are a million things you can do to a system that supposedly preserve
binary compatibility, such as installing vendor patches or changing a
setting in /etc.  But if you run a test program is such a situation you're
testing the wrong system.

> I would describe that as a case where the compiler search path and the
> run time library search path are not the same.

The assumption is surely that the user would set LD_LIBRARY_PATH or
configure his linker before running the program.  But nothing guarantees
that he'll actually set the search path to /usr/local/lib, which is what
gcc was searching in this situation.

> Clearly differences between search paths matter, but they are not the
> same as cross-compilation.

It's not the same as the classical Canadian Cross, but it's still cross
enough to concern me. ;-)

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



Re: AW: AW: AW: Re: tinterval - operator problems on AIX

From
Ian Lance Taylor
Date:
Peter Eisentraut <peter_e@gmx.net> writes:

> > > This would seem to be the right answer, but unfortunately Autoconf is not
> > > smart enough to detect marginal cross-compilation cases in all situations.
> > > Someone had zlib installed in a location where gcc would find it (compiles
> > > okay) but the run-time linker would not (does not run).  This is not
> > > detected when AC_PROG_CC runs, but only later on after you have checked
> > > for the libraries.
> >
> > Hmmm.  I would not describe that as a cross-compilation case at all.
> > The build machine and the host machine are the same.
> 
> Only for small values of "same". ;-)  Sameness is not defined by the names
> being spelled identically or the physical coincidence of the hardware.
> There are a million things you can do to a system that supposedly preserve
> binary compatibility, such as installing vendor patches or changing a
> setting in /etc.  But if you run a test program is such a situation you're
> testing the wrong system.

I believe that terminology is important in technical issues, and in
any case I'm pedantic by nature.  So I am going to disagree.  When you
build a program on the system on which it is going to run, that is not
cross-compilation.  I agree that if you build a program on one system,
and then copy it (either physically or via something like NFS) to
another system, and run it on that other system, then that may be
cross-compilation.

It may be that the program in this case was being moved from one
machine to another, and I missed it.  However, unless that was the
case, a difference in search path between the compiler and the runtime
linker is not a cross-compilation issue.  A difference in where a
library appears from one machine to another is a cross-compilation
issue.

I believe that it is important to describe problems correctly in order
to understand how to fix them correctly.  If the problem is ``autoconf
does not correctly diagnose a case of cross-compilation,'' that
suggests one sort of fix.  If the problem is ``the compiler and the
runtime linker have different search paths,'' that suggests a
different sort of fix.


To return to the issue which started this thread, I believe it was an
issue concerning the behaviour of the mktime library call.  The
behaviour of that library call is not going to be affected by the
location of a shared library.  The approach I suggested should suffice
to address the particular problem at hand.  Do you disagree?


The issue in which the compiler and the runtime linker use different
search paths is fixed by either changing the compiler search path, to
by default only choose shared libraries from directories which the
runtime linker will search, or by changing the library installation
procedure, either put the library in /usr/lib, or on systems which
support ld.so.conf arrange to put the directory in ld.so.conf.

Note that if you link with -lz, at least some versions of the GNU
linker will issue a warning that the library will not be found by the
runtime linker.

Ian


Re: AW: AW: AW: Re: tinterval - operator problems on AIX

From
Pete Forman
Date:
Peter Eisentraut writes:> What if someone has a binary PostgreSQL package installed, then> updates his time library to
somethingsupposedly binary compatible> and finds out that PostgreSQL still doesn't use the enhanced> capabilities?
 

You are too generous.  If someone downloads a binary package it should
not be expected to be able to take advantage of non standard features
of the platform.  It is reasonable that they should compile it from
source to get the most from it.
-- 
Pete Forman                 -./\.- Disclaimer: This post is originated
WesternGeco                   -./\.-  by myself and does not represent
pete.forman@westerngeco.com     -./\.-  opinion of Schlumberger, Baker
http://www.crosswinds.net/~petef  -./\.-  Hughes or their divisions.