Re: libpq_r

From: Peter Eisentraut <peter_e(at)gmx(dot)net>
To: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
Cc: Larry Rosenman <ler(at)lerctr(dot)org>, Lee Kindness <lkindness(at)csl(dot)co(dot)uk>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL Development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: libpq_r
Date: 2003-07-25 09:23:05
Message-ID: Pine.LNX.4.56.0307251114190.1545@krusty.credativ.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Bruce Momjian writes:

> I still think it is confusing to create a libpq_r on platforms that have
> no _r libraries. I am on BSD/OS and I can find only _r library on my
> entire system,

The criterion is not whether the platform has _r libraries, it's whether
special actions are required in order to make a library fit for threaded
programs, at the time that library is built. Such special actions may
include:

1. need to link in special libc_r (FreeBSD)
2. need to use magic flags for compiler and/or linker (FreeBSD, UnixWare)
3. need to compile with special preprocessor symbols (UnixWare, AIX)
4. need to use different compiler altogether (AIX)

(If you read between the lines of the manufacturers' documentation, all
these methods end up accomplishing similar things, they are only different
interfaces for it.)

If any of these cases apply, we need to provide a separate libpq_r, or
else either threaded land or nonthreaded land will suffer pain, from what
I read. (The simplest example is errno being defined in different ways
and referring to different symbols.)

If none of these cases apply, then a separate libpq_r will be redundant,
perhaps "confusing" to some, but it can be ignored by the user.

--
Peter Eisentraut peter_e(at)gmx(dot)net

In response to

  • Re: libpq_r at 2003-07-24 20:30:14 from Bruce Momjian

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Larry Rosenman 2003-07-25 09:47:56 Re: libpq_r
Previous Message Larry Rosenman 2003-07-25 09:19:42 Re: libpq_r