Tom Lane wrote:
> Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> > Tom Lane wrote:
> >> I think you should leave the $(libpq) macro alone and add a $(libpgport)
> >> macro ... and yes, you will have to go around and modify the client
> >> program Makefiles individually.
> > How is this? It creates a new $(libpq_only) for library usage.
> > ecpglib/Makefile is the only place I saw that can use it.
> I think you are creating long-term confusion in order to save yourself a
> little bit of editing work. I don't object to having a combined macro
> but it shouldn't be called $(libpq). Maybe $(libpq_plus_support)
> or something like that ... or even libpq_plus_libpgport ...
> Also think about whether the hack in Makefile.global to add PTHREAD_LIBS
> to $(libpq) ought to add them to $(libpq_plus_support) instead. I'm
> not sure about that one ... it might be that you cannot link libpq
> successfully without PTHREAD_LIBS in the cases where the hack fires.
OK, here is a new patch. I called it 'libpq_pgport'.
I restructured the code so the threading is added first, and uses just
$libpq so it includes any thread additions.
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
In response to
pgsql-patches by date
|Next:||From: Tom Lane||Date: 2005-03-25 18:09:49|
|Subject: Re: Makefile breakage |
|Previous:||From: Tom Lane||Date: 2005-03-25 16:18:05|
|Subject: Re: Fix that deals with unusable custom variables. |