Thread: PL compilations ignores LDFLAGS
I hit a problem with libtcl.so that LDFLAGS is not propagated. The same problem is with other PL languages as well. Is it intention or a bug? thanks Zdenek
Zdenek Kotala <Zdenek.Kotala@Sun.COM> writes:
> I hit a problem with libtcl.so that LDFLAGS is not propagated. The same
> problem is with other PL languages as well.
> Is it intention or a bug?
It's intentional; LDFLAGS is for linking executables and may not be
suitable for shlibs. I see that Makefile.shlib makes exceptions for
some platforms though. What *specific* problem are you having, on what
platform?
regards, tom lane
On Thursday 23 April 2009 17:50:47 Zdenek Kotala wrote: > I hit a problem with libtcl.so that LDFLAGS is not propagated. The same > problem is with other PL languages as well. > > Is it intention or a bug? For shared libraries, you need to use LDFLAGS_SL instead.
Zdenek Kotala píše v čt 23. 04. 2009 v 16:50 +0200: > I hit a problem with libtcl.so that LDFLAGS is not propagated. The same > problem is with other PL languages as well. > > Is it intention or a bug? I'm looking on Makefile.shlib and I see there strange line: # Insert -L from LDFLAGS after any -L already present in SHLIB_LINK SHLIB_LINK := $(filter -L%, $(SHLIB_LINK)) $(filter -L%, $(LDFLAGS)) $(filter-out -L%, $(SHLIB_LINK)) It seems to me that one of these line are not correct. But anyway I lost -R somewhere. Zdenek
Tom Lane píše v čt 23. 04. 2009 v 11:11 -0400: > Zdenek Kotala <Zdenek.Kotala@Sun.COM> writes: > > I hit a problem with libtcl.so that LDFLAGS is not propagated. The same > > problem is with other PL languages as well. > > > Is it intention or a bug? > > It's intentional; LDFLAGS is for linking executables and may not be > suitable for shlibs. I see that Makefile.shlib makes exceptions for > some platforms though. What *specific* problem are you having, on what > platform? I have problem with setup builfarm member on Solaris 10. I need to pass -R<path> (rpath). I can do it by LD_OPTIONS as we do it for package building. I had only doubt if it is correct behavior. however it seems to me that $rpath should be set like --with-libs, but it look likes that it does not work. Thanks Zdenek
Peter Eisentraut píše v čt 23. 04. 2009 v 18:11 +0300: > On Thursday 23 April 2009 17:50:47 Zdenek Kotala wrote: > > I hit a problem with libtcl.so that LDFLAGS is not propagated. The same > > problem is with other PL languages as well. > > > > Is it intention or a bug? > > For shared libraries, you need to use LDFLAGS_SL instead. I see. Thanks I will try it. Could anybody fix ./configure to show correct help? Thanks Zdenek
Zdenek Kotala <Zdenek.Kotala@Sun.COM> writes:
> Tom Lane píše v čt 23. 04. 2009 v 11:11 -0400:
>> What *specific* problem are you having, on what
>> platform?
> I have problem with setup builfarm member on Solaris 10. I need to pass
> -R<path> (rpath). I can do it by LD_OPTIONS as we do it for package
> building. I had only doubt if it is correct behavior.
Well, $(rpath) is included into SHLIB_LINK on every platform, so the
question is why that's not getting set.
regards, tom lane
Tom Lane píše v čt 23. 04. 2009 v 11:42 -0400:
> Zdenek Kotala <Zdenek.Kotala@Sun.COM> writes:
> > Tom Lane píše v čt 23. 04. 2009 v 11:11 -0400:
> >> What *specific* problem are you having, on what
> >> platform?
>
> > I have problem with setup builfarm member on Solaris 10. I need to pass
> > -R<path> (rpath). I can do it by LD_OPTIONS as we do it for package
> > building. I had only doubt if it is correct behavior.
>
> Well, $(rpath) is included into SHLIB_LINK on every platform, so the
> question is why that's not getting set.
I went through the makefiles and it is set correctly. I expected that
--with-libs automatically adds path into $(rpath), but it is --libdir
what is used. If I run ldd -rU on any libs or pl*.so then I got:
unused search path=/usr/postgres/8.3/lib (RUNPATH/RPATH from file /usr/postgres/8.3/lib/cube.so) unused search
path=/usr/postgres/8.3/lib (RUNPATH/RPATH from file /usr/postgres/8.3/lib/libpgtypes.so) unused search
path=/usr/postgres/8.3/lib (RUNPATH/RPATH from file /usr/postgres/8.3/lib/libpq.so) unused search
path=/usr/postgres/8.3/lib (RUNPATH/RPATH from file /usr/postgres/8.3/lib/pgcrypto.so) unused search
path=/usr/postgres/8.3/lib (RUNPATH/RPATH from file /usr/postgres/8.3/lib/pltcl.so) unused search
path=/usr/postgres/8.3/lib (RUNPATH/RPATH from file /usr/postgres/8.3/lib/sslinfo.so)
Which is wrong. I already discussed this issue with Peter a moth ago
without any result. But I find now that plperl.so override rpathdir and
it could be used in other libs too.
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
For plctl.so I suggest to use path to libtcl.so which can be detect in configure.
Zdenek
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?
> 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.
regards, tom lane
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
On Thursday 23 April 2009 18:14:59 Zdenek Kotala wrote: > I'm looking on Makefile.shlib and I see there strange line: > > # Insert -L from LDFLAGS after any -L already present in SHLIB_LINK > SHLIB_LINK := $(filter -L%, $(SHLIB_LINK)) $(filter -L%, $(LDFLAGS)) > $(filter-out -L%, $(SHLIB_LINK)) > > It seems to me that one of these line are not correct. Why not? > But anyway I lost -R somewhere. Use LDFLAGS_SL.
On Thursday 23 April 2009 18:32:19 Zdenek Kotala wrote: > however it seems to me that $rpath should be set like --with-libs, but > it look likes that it does not work. The rpath stuff only sets the rpath where our libraries are going to be installed. It does not handle rpaths necessary to get other libraries. That is up to the local admin to figure out, I suppose.
Dne 23.04.09 23:31, Peter Eisentraut napsal(a): > On Thursday 23 April 2009 18:14:59 Zdenek Kotala wrote: >> I'm looking on Makefile.shlib and I see there strange line: >> >> # Insert -L from LDFLAGS after any -L already present in SHLIB_LINK >> SHLIB_LINK := $(filter -L%, $(SHLIB_LINK)) $(filter -L%, $(LDFLAGS)) >> $(filter-out -L%, $(SHLIB_LINK)) >> >> It seems to me that one of these line are not correct. > > Why not? Yeah, It is correct I swapped meaning of filter and filter-out. Thanks Zdenek