Thread: AW: AW: AW: Re: tinterval - operator problems on AIX
> > > > > 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
> 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
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.
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/
> 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
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/
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
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/
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
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/
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
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.