Re: [HACKERS] (: JDBC+(Sun ~3:pm MST) CVS :) -also question about regression tests

> > There's no reason to break anything with this...  This is a way of
> > detecting it (there are others IIRC).
> >
> > #if (__GLIBC__ >= 2)
> > [glibc-2 stuff]
> > #endif
> >
> > for a complicated variant.
>
>         I personally feel that this would be an acceptable way of fixing
> the bugs...again, this is compiler defined, so its pretty transparent to
> the 'end-user'...do you want to supply patches that does this?  Thomas,
> does this work for you as well?

This is the nature of the patch Oliver developed which I'll bet works just
great. However, the patch is on top of kludge code to get Solaris to work one
or two releases ago. I'd rather back those changes out, and get #ifdef Solaris
as well as #ifdef _GLIBC_ code blocks, or even better put these in the
port-specific code.

I'd also like to not have to watch this too closely for v6.3, since I should be
swamped with docs, regression testing, and perhaps contributing to subselects.

If we do apply the glibc2 patches, then I'd like help from someone running
Solaris to clean things up for v6.4.

> That and #undef HAVE_INT_TIMEZONE in os/linux.h for glibc-2...  as that's

> > autodetected (and invalid).  Detecting HAVE_SIGSETJMP would be nice to as
> > it really IS a function in glibc (just remapped via a #define).

So, we kludge both HAVE_INT_TIMEZONE and HAVE_SIGSETJMP in config.h.in by
bracketing them with #if (_GLIBC_ >= 2) ? I suspect that the RH5.0 distribution
of Postgres has broken date and time behavior because HAVE_INT_TIMEZONE is
wrong.

The HAVE_SIGSETJMP problem (which is present in RH4.x also since sigsetjmp() is
defined as a macro, which is explicitly disallowed by the configure test) can
be worked-around by checking for #ifdef sigsetjmp. btw, I've tried running
RH4.2 compiled both ways and noticed no difference in behavior, but I'm not
certain what to look for.

Oh, I forgot; already fixed it because I was tired of the compiler warnings.
Here is the code in bootstrap.c:

/* The test for HAVE_SIGSETJMP fails on Linux 2.0.x because the test
 *  explicitly disallows sigsetjmp being a #define, which is how it
 *  is declared in Linux. So, to avoid compiler warnings about
 *  sigsetjmp() being redefined, let's not redefine unless necessary.
 * - thomas 1997-12-27
 */

#if !defined(HAVE_SIGSETJMP) && !defined(sigsetjmp)
static jmp_buf Warn_restart;
#define sigsetjmp(x,y)  setjmp(x)
#define siglongjmp longjmp

#else
static sigjmp_buf Warn_restart;
#endif

...

>         Patch for this?  I'd rather see a patch of what you'd like to
> review then to blindly go around and "fix" what I can't directly test. :)
>
> > AFAIK gnu's libc's are not used on just linux.  So making it a linux-only
> > thing would be almost as bad as not fixing it in the first place... *g*
> > (not trying to be rude - personally I've found that the database works
> > well enough regardless of the regression tests :)
>
>         It would be worse, IMHO...just look at the 'wine' project...such
> good potential, but they core developers feel that supporting Linux-only
> is the way to go...so they keep bringing in these really great features
> ... that work *only* under Linux.  Then, they release a new beta and find
> out that nobody else can use it anymore :(
>
>         At least 3 out of 4 of the core developers here are *BSD, so we
> offset the Linux-camp very well *grin*  *wave to Thomas*

Sure, takes 3 BSD machines for an even fight *ducks and hits head on desk*

                                         - Tom