Makefile breakage

Tom Lane wrote:

You can't just arbitrarily pull in libpgport.a everywhere that libpq.so
is used. That breaks anything that requires position-independent code
... for instance ecpglib.

Strange because it worked on my BSD system and I do compile ecpg. What
do you suggest? Is this worth fixing somehow?

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Bruce Momjian <pgman@candle.pha.pa.us> writes:

Tom Lane wrote:

You can't just arbitrarily pull in libpgport.a everywhere that libpq.so
is used. That breaks anything that requires position-independent code
... for instance ecpglib.

Strange because it worked on my BSD system and I do compile ecpg. What
do you suggest? Is this worth fixing somehow?

Intel machines tend not to care whether code is officially
position-independent or not. Most other platforms are sticky about it.
You don't have a choice whether to fix it.

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.

regards, tom lane

Tom Lane wrote:

Bruce Momjian <pgman@candle.pha.pa.us> writes:

Tom Lane wrote:

You can't just arbitrarily pull in libpgport.a everywhere that libpq.so
is used. That breaks anything that requires position-independent code
... for instance ecpglib.

Strange because it worked on my BSD system and I do compile ecpg. What
do you suggest? Is this worth fixing somehow?

Intel machines tend not to care whether code is officially
position-independent or not. Most other platforms are sticky about it.
You don't have a choice whether to fix it.

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.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Bruce Momjian <pgman@candle.pha.pa.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.

regards, tom lane

Tom Lane wrote:

Bruce Momjian <pgman@candle.pha.pa.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@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Bruce Momjian <pgman@candle.pha.pa.us> writes:

OK, here is a new patch. I called it 'libpq_pgport'.

Looks alright to me now. Are you going to get this into 8.0.2beta?

regards, tom lane

Tom Lane wrote:

Bruce Momjian <pgman@candle.pha.pa.us> writes:

OK, here is a new patch. I called it 'libpq_pgport'.

Looks alright to me now. Are you going to get this into 8.0.2beta?

Yea, I guess. It really just has to be in our final release before 8.1.

Would someone else eyeball it before I apply it, or should I just keep
it for post 8.0.2?

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Bruce Momjian wrote:

Tom Lane wrote:

Bruce Momjian <pgman@candle.pha.pa.us> writes:

OK, here is a new patch. I called it 'libpq_pgport'.

Looks alright to me now. Are you going to get this into 8.0.2beta?

Yea, I guess. It really just has to be in our final release before 8.1.

Would someone else eyeball it before I apply it, or should I just keep
it for post 8.0.2?

I just remembered 8.0.2 is going to get more testing than a typical
8.0.X release, so I am applying now.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073