Patch for glibc2 date problems
The Hermit Hacker wrote:
On Thu, 15 Jan 1998, Oliver Elphick wrote:
I have a potential patch for the glibc2 date problem; however I can't
test it because the snapshot won't build.remove src/backend/parser/scan.c...that should fix your problem
Thanks, it did.
The patch for glibc2 dates is attached. With this applied, a Linux system
with libc6 (glibc2) passes all the date and time related regression tests.
Attachments:
patch.dt.ctext/plain; charset=us-ascii; name=patch.dt.cDownload+12-6
Import Notes
Reply to msg id not found: MessagefromTheHermitHackerscrappy@hub.orgofThu15Jan1998080646EST.Pine.NEB.3.95.980115080620.16579F-100000@hub.org
The patch for glibc2 dates is attached. With this applied, a Linux system
with libc6 (glibc2) passes all the date and time related regression tests.
It looks as though this patch is a bit Linux-specific (or specific to some version of glibc which has only been tested on
Linux).
Can we wait until glibc2 settles down, or provide this as an add-on patch rather than merging it into the main tree? I hate
adding machine-specific code into otherwise general code...
Another possibility would be to add a new #define variable like HAVE_FUNNY_LIBRARY in config.h or in linux.h so we can
possibly use this with other ports if necessary in the future.
I'm planning on installing RH5.0 sometime soon (I have a clean disk so can fall back to RH4.2). I'm sure I'll sound more
sympathetic by then :)
- Tom
"Thomas G. Lockhart" wrote:
The patch for glibc2 dates is attached. With this applied, a Linux system
with libc6 (glibc2) passes all the date and time related regression tests.It looks as though this patch is a bit Linux-specific (or specific to some v
ersion of glibc which has only been tested on
Linux).
I don't have experience of using glibc2 on any other type of machine.
However, isn't part of the point of it to remove inter-machine differences?
Can we wait until glibc2 settles down, or provide this as an add-on patch ra
ther than merging it into the main tree? I hate
adding machine-specific code into otherwise general code...
I guess that's up to you.
Another possibility would be to add a new #define variable like HAVE_FUNNY_L
IBRARY in config.h or in linux.h so we can
Why isn't
#if __GLIBC__ < 2
enough for this?
possibly use this with other ports if necessary in the future.
I don't have experience of using glibc2 on any other type of machine.
However, isn't part of the point of it to remove inter-machine differences?
I'm planning on installing RH5.0 sometime soon (I have a clean disk so can f
all back to RH4.2). I'm sure I'll sound more
sympathetic by then :)- Tom
My assumption was that any system using glibc2 would not have a broken
rint() function; so the general change to TMODULO would be justified.
The change of the test of `var != 0' to `var != rint(var)' should not break
anything, even if var is non-zero. It is merely saying, don't use
decimal points if there's no decimal part.
The remaining part of the patch is to force the undefinition of
HAVE_INT_TIMEZONE; again this is glibc2-specific, but I don't know
any reason to suppose it wouldn't be needed on any machine with glibc2.
It would really be helpful to have someone on a non-Linux machine test
it; but is there anyone?
--
Oliver Elphick Oliver.Elphick@lfix.co.uk
Isle of Wight http://www.lfix.co.uk/oliver
PGP key from public servers; key ID 32B8FAA1
Unsolicited email advertisements are not welcome; any person sending
such will be invoiced for telephone time used in downloading together
with a £25 administration charge.
Import Notes
Reply to msg id not found: lockhart@alumni.caltech.edu | Resolved by subject fallback
On Fri, 16 Jan 1998, Thomas G. Lockhart wrote:
The patch for glibc2 dates is attached. With this applied, a Linux system
with libc6 (glibc2) passes all the date and time related regression tests.
It looks as though this patch is a bit Linux-specific (or specific to
some version of glibc which has only been tested on Linux).
Can we wait until glibc2 settles down, or provide this as an add-on
patch rather than merging it into the main tree? I hate adding
machine-specific code into otherwise general code...
Another possibility would be to add a new #define variable like
HAVE_FUNNY_LIBRARY in config.h or in linux.h so we can possibly use this
with other ports if necessary in the future.
How about making this #define 'HAVE_GLIBC' ???
Maarten
_____________________________________________________________________________
| Maarten Boekhold, Faculty of Electrical Engineering TU Delft, NL |
| Computer Architecture and Digital Technique section |
| M.Boekhold@et.tudelft.nl |
-----------------------------------------------------------------------------
"Thomas G. Lockhart" wrote:
The patch for glibc2 dates is attached. With this applied, a Linux system
with libc6 (glibc2) passes all the date and time related regression tests.It looks as though this patch is a bit Linux-specific (or specific to some v
ersion of glibc which has only been tested on
Linux).I don't have experience of using glibc2 on any other type of machine.
However, isn't part of the point of it to remove inter-machine differences?
Can we wait until glibc2 settles down, or provide this as an add-on patch ra
ther than merging it into the main tree? I hate
adding machine-specific code into otherwise general code...I guess that's up to you.
Another possibility would be to add a new #define variable like HAVE_FUNNY_L
IBRARY in config.h or in linux.h so we canWhy isn't
#if __GLIBC__ < 2
enough for this?possibly use this with other ports if necessary in the future.
I don't have experience of using glibc2 on any other type of machine.
However, isn't part of the point of it to remove inter-machine differences?I'm planning on installing RH5.0 sometime soon (I have a clean disk so can f
all back to RH4.2). I'm sure I'll sound more
sympathetic by then :)- Tom
My assumption was that any system using glibc2 would not have a broken
rint() function; so the general change to TMODULO would be justified.The change of the test of `var != 0' to `var != rint(var)' should not break
anything, even if var is non-zero. It is merely saying, don't use
decimal points if there's no decimal part.The remaining part of the patch is to force the undefinition of
HAVE_INT_TIMEZONE; again this is glibc2-specific, but I don't know
any reason to suppose it wouldn't be needed on any machine with glibc2.It would really be helpful to have someone on a non-Linux machine test
it; but is there anyone?
Our code is complicated enough without adding patches for OS bugs. A
good place for the patch is the Linux FAQ. If it really becomes a
problem, we can put the patch as a separate file in the distribution,
and mention it in the INSTALL instructions. If you really want to get
fancy, as I did with the flex bug, you can run a test at compile time to
see if the bug exists.
--
Bruce Momjian
maillist@candle.pha.pa.us
The remaining part of the patch is to force the undefinition of
HAVE_INT_TIMEZONE; again this is glibc2-specific, but I don't know
any reason to suppose it wouldn't be needed on any machine with glibc2.It would really be helpful to have someone on a non-Linux machine test
it; but is there anyone?Our code is complicated enough without adding patches for OS bugs. A
good place for the patch is the Linux FAQ. If it really becomes a
problem, we can put the patch as a separate file in the distribution,
and mention it in the INSTALL instructions. If you really want to get
fancy, as I did with the flex bug, you can run a test at compile time to
see if the bug exists.--
Bruce Momjian
maillist@candle.pha.pa.us
If someone can mail me an exact description of the problem with info on
the setup which shows it AND the patch info, then I'll add it to the
Linux-specific FAQ. (Much like the ld bug in Irix-6 has a patch
description in the Irix-FAQ).
Bets wishes,
Andrew
----------------------------------------------------------------------------
Dr. Andrew C.R. Martin University College London
EMAIL: (Work) martin@biochem.ucl.ac.uk (Home) andrew@stagleys.demon.co.uk
URL: http://www.biochem.ucl.ac.uk/~martin
Tel: (Work) +44(0)171 419 3890 (Home) +44(0)1372 275775
Import Notes
Resolved by subject fallback