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

On Mon, 2 Feb 1998, The Hermit Hacker wrote:

> On Mon, 2 Feb 1998, teunis wrote:
>
> > > > I'll say it again and again - glibc-2.0 is the _STANDARD_ (actually
> > > > reference) platform for Unix. All Unix. Not just Linux.
> > > > Adopted last year.
> > >
> > > And...how many Unix (other then Linux) are *actually* using it?
> > > Any idea on how we can test whether it is being used or not?
> >
> > AFAIK some BSD's are now using it - but I am probably wrong. I gave up on
> > BSD in '92.
>
> Geez, about the time I gave up on Linux and converted to *BSD
> *grin*

Awww - I only gave up on BSD 'cause it had no sound *grin*.... So I'm
biased. [and I've since grown to love Linux's many quirks so I'm never
going back... but each to their own, yes? :]

> > 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 varient.
>
> 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?

I'll work on it (I've attached a modified os.h to the end - this is so it
will work at all). Don't know how much time I'll have though....

[clipa]
> > 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*

*grin* - as long as linux is supported at all I'm happy :)
There's no real special features there that would benefit anything other
than a really low-level system (eg. Wine, Dosemu) anyways...

(aside: I also work on GGI (formerly linux-GGI) a [largely] system-neutral
graphics toolkit. Was originally modified kernel linux-only but now works
on SGI O/2, AIX, and others... under X, ascii (libaa), svgalib, and still
supporting the linux-native (KGI) drivers if under linux... :)
That crew is 100% linux-only but people had access to other hardware and
ported it.... soon people will try to port the kernel level to FreeBSD :)

[linux.h - canna remember where it is... but here's an updated version.
I'd prefer this stuff be in config.h or better handled by configure, but
that's life]

/* __USE_POSIX, __USE_BSD, and __USE_BSD_SIGNAL used to be defined either
here or with -D compile options, but __ macros should be set and used by C
library macros, not Postgres code. __USE_POSIX is set by features.h,
__USE_BSD is set by bsd/signal.h, and __USE_BSD_SIGNAL appears not to
be used.
*/
#define JMP_BUF
#define USE_POSIX_TIME
#define USE_POSIX_SIGNALS
#define NEED_I386_TAS_ASM
#define HAS_TEST_AND_SET

#if defined(PPC)
typedef unsigned int slock_t;
#elif defined(__alpha__)
typedef long int slock_t;
#else
typedef unsigned char slock_t;
#endif

#if (__GLIBC__ >= 2)
#ifdef HAVE_INT_TIMEZONE
#undef HAVE_INT_TIMEZONE
#endif
/* currently undefined as I (teunis(at)computersupportcentre(dot)com) have not
checked this yet */
/* #define HAVE_SIGSETJMP 1 */
#endif

#if defined(PPC)
#undef NEED_I386_TAS_ASM
#undef HAVE_INT_TIMEZONE
#endif

#if defined(sparc)
#undef NEED_I386_TAS_ASM
#endif

#if defined(__alpha__)
#undef NEED_I386_TAS_ASM
#endif