Re: PL compilations ignores LDFLAGS - Mailing list pgsql-hackers

From Zdenek Kotala
Subject Re: PL compilations ignores LDFLAGS
Date
Msg-id 1240517806.1275.297.camel@localhost
Whole thread Raw
In response to Re: PL compilations ignores LDFLAGS  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Tom Lane píše v čt 23. 04. 2009 v 14:47 -0400:
> Zdenek Kotala <Zdenek.Kotala@Sun.COM> writes:
> > I supposed to do something like this for libpq, libpgtypes and so on.
> 
> > *** pgsql.orig.d976d4abedca/src/interfaces/libpq/Makefile    2009-04-23 20:07:21.178749132 +0200
> > --- pgsql.orig/src/interfaces/libpq/Makefile    2009-04-23 20:07:21.194173674 +0200
> > ***************
> > *** 65,70 ****
> > --- 65,71 ----
> >   endif
>   
> >   SHLIB_EXPORTS = exports.txt
> > + rpath = ""
>   
> >   all: all-lib
> 
> That seems like a pretty awful idea.  How do you know that the rpath
> isn't being used to pick up stuff like openssl?

Dynamic linker explicitly looks into /lib and /usr/lib directory. If
openssl is placed e.g. in /usr/sfw/lib (Solaris 10) then you need
specify -R (or -rpath) option, because postgresql libs are
in /usr/postgres/8.3/lib. It make sense to set rpath=libdir for example
when somebody install postgres into /usr/local/lib. 

But I don't like this idea when compilation auto setup it. What you can
do in case, when you have more openssl version on the system? One
in /usr/local/lib and one in /usr/lib and you prefer /usr/lib for
openssl. I think if user want to opessl from same location as libpq he
should specified it explicitly.


> > For plctl.so I suggest to use path to libtcl.so which can be detect in configure.
> 
> I believe that we expect to get any required switches for that out of
> the TCL_LIB_SPEC and/or TCL_LIBS variables, which we get from tclconfig.
> I wonder if you are working with an improperly configured Tcl
> installation.

Problem is that TCL_LD_SEARCH_FLAGS is not use in pltcl Makefile to
override rpath. See patch. Unfortunately it does not work on Solaris 11,
because it is wrongly defined. On Solaris 10 and RHEL 4 it seems to be
ok. 


diff -Nrc pgsql.orig.d976d4abedca/configure.in pgsql.orig/configure.in
*** pgsql.orig.d976d4abedca/configure.in    2009-04-23 22:08:39.205236380 +0200
--- pgsql.orig/configure.in    2009-04-23 22:08:39.212144346 +0200
***************
*** 1709,1715 **** if test "$with_tcl" = yes; then     PGAC_PATH_TCLCONFIGSH([$with_tclconfig])
PGAC_EVAL_TCLCONFIGSH([$TCL_CONFIG_SH],
!                           [TCL_INCLUDE_SPEC,TCL_LIB_FILE,TCL_LIBS,TCL_LIB_SPEC,TCL_SHARED_BUILD])
AC_SUBST(TCL_SHLIB_LD_LIBS)dnldon't want to double-evaluate that one     # now that we have TCL_INCLUDE_SPEC, we can
checkfor <tcl.h>     ac_save_CPPFLAGS=$CPPFLAGS
 
--- 1709,1715 ---- if test "$with_tcl" = yes; then     PGAC_PATH_TCLCONFIGSH([$with_tclconfig])
PGAC_EVAL_TCLCONFIGSH([$TCL_CONFIG_SH],
!                           [TCL_INCLUDE_SPEC,TCL_LIB_FILE,TCL_LIBS,TCL_LIB_SPEC,TCL_SHARED_BUILD,TCL_LD_SEARCH_FLAGS])
   AC_SUBST(TCL_SHLIB_LD_LIBS)dnl don't want to double-evaluate that one     # now that we have TCL_INCLUDE_SPEC, we
cancheck for <tcl.h>     ac_save_CPPFLAGS=$CPPFLAGS
 
diff -Nrc pgsql.orig.d976d4abedca/src/Makefile.global.in pgsql.orig/src/Makefile.global.in
*** pgsql.orig.d976d4abedca/src/Makefile.global.in    2009-04-23 22:08:39.208705241 +0200
--- pgsql.orig/src/Makefile.global.in    2009-04-23 22:08:39.212430882 +0200
***************
*** 182,187 ****
--- 182,188 ---- TCL_LIB_SPEC        = @TCL_LIB_SPEC@ TCL_INCLUDE_SPEC    = @TCL_INCLUDE_SPEC@ TCL_SHARED_BUILD    =
@TCL_SHARED_BUILD@
+ TCL_LD_SEARCH_FLAGS = @TCL_LD_SEARCH_FLAGS@ TCL_SHLIB_LD_LIBS    = @TCL_SHLIB_LD_LIBS@  PTHREAD_CFLAGS        =
@PTHREAD_CFLAGS@
diff -Nrc pgsql.orig.d976d4abedca/src/pl/tcl/Makefile pgsql.orig/src/pl/tcl/Makefile
*** pgsql.orig.d976d4abedca/src/pl/tcl/Makefile    2009-04-23 22:08:39.210435528 +0200
--- pgsql.orig/src/pl/tcl/Makefile    2009-04-23 22:08:39.213140838 +0200
***************
*** 28,33 ****
--- 32,38 ---- endif endif 
+ rpath=$(TCL_LD_SEARCH_FLAGS)  SHLIB_LINK = $(TCL_LIB_SPEC) ifneq ($(PORTNAME), win32)


Zdenek





pgsql-hackers by date:

Previous
From: "David E. Wheeler"
Date:
Subject: Re: Why do we let CREATE DATABASE reassign encoding?
Next
From: Marc Munro
Date:
Subject: Re: RFE: Transparent encryption on all fields