Re: PL compilations ignores LDFLAGS

From: Zdenek Kotala <Zdenek(dot)Kotala(at)Sun(dot)COM>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: PL compilations ignores LDFLAGS
Date: 2009-04-23 20:16:46
Message-ID: 1240517806.1275.297.camel@localhost
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


Tom Lane píše v čt 23. 04. 2009 v 14:47 -0400:
> Zdenek Kotala <Zdenek(dot)Kotala(at)Sun(dot)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)dnl don't want to double-evaluate that one
# now that we have TCL_INCLUDE_SPEC, we can check for <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 can check 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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Marc Munro 2009-04-23 20:31:39 Re: RFE: Transparent encryption on all fields
Previous Message David E. Wheeler 2009-04-23 19:32:16 Re: Why do we let CREATE DATABASE reassign encoding?