Thread: RPATH issue with libpq on Solaris 8 (gcc)
I'm interested in some guidance on how to best deal with the following issue. I'm building postgres-8.2.5 on Solaris 8 SPARC, using a gcc built (not by me) for our environment. We have an old home-grown software distribution/configuration management system that arranges shared-objects and binaries are in non-standard places. So to find them, I use -L and -R in $(CFLAGS) and $(LFLAGS) to make sure dependencies (like krb5/ssl libraries) are found. The problem is, the Makefile.shlib doesn't arrange to have the $(CFLAGS) passed to gcc, since maybe it assumes gcc on Solaris SPARC doesn't need it? So, while psql can find the shared objects, libpq can't, because libpq doesn't have the rpath I gave it! An example: % env | grep FLAGS LDFLAGS=-R/software/readline-5.2/lib:/software/gcc-3.4.5/lib:/software/openssl-0.9.8_runtime/lib:/software/krb5-1.6/lib CFLAGS=-R/software/readline-5.2/lib:/software/gcc-3.4.5/lib:/software/openssl-0.9.8_runtime/lib:/software/krb5-1.6/lib Then I configure && make && make install, only to find: % ldd -s libpq.so | head find object=libssl.so.0.9.8; required by ./libpq.so search path=/software/gcc-3.4.5_runtime/lib:/software/postgresql-8.2/lib (RPATH from file ./libpq.so) trying path=/software/gcc-3.4.5_runtime/lib/libssl.so.0.9.8 trying path=/software/postgresql-8.2/lib/libssl.so.0.9.8 search path=/usr/lib (default) trying path=/usr/lib/libssl.so.0.9.8 libssl.so.0.9.8 => (file not found) yet from 'ldd -s psql': find object=libssl.so.0.9.8; required by psql search path=/software/readline-5.2/lib:/software/gcc-3.4.5_runtime/lib:/software/openssl-0.9.8_runtime/lib:/software/krb5-1.6/lib:/softwar e/postgresql-8.2/lib (RPATH from file psql) trying path=/software/readline-5.2/lib/libssl.so.0.9.8 trying path=/software/gcc-3.4.5_runtime/lib/libssl.so.0.9.8 trying path=/software/openssl-0.9.8_runtime/lib/libssl.so.0.9.8 libssl.so.0.9.8 => /software/openssl-0.9.8_runtime/lib/libssl.so.0.9.8 If I hack Makefile.shlib in pgsql/src: ifeq ($(PORTNAME), solaris) ifeq ($(GCC), yes) LINK.shared = $(CC) -shared $(CFLAGS) # ^^^^^^^^^ I added this. else LINK.shared = $(CC) -G $(CFLAGS) # CFLAGS added for X86_64 then it's all good. Would this be considered a bug, or would my environment be considered "unsupported"???
Jason Testart <jatestart@cs.uwaterloo.ca> writes: > I'm building postgres-8.2.5 on Solaris 8 SPARC, using a gcc built (not > by me) for our environment. We have an old home-grown software > distribution/configuration management system that arranges > shared-objects and binaries are in non-standard places. So to find > them, I use -L and -R in $(CFLAGS) and $(LFLAGS) to make sure > dependencies (like krb5/ssl libraries) are found. Try adjusting 'rpathdir' in src/Makefile.global (post-configure), instead. regards, tom lane
Jason Testart <jatestart@cs.uwaterloo.ca> writes: > Tom Lane wrote: >> Try adjusting 'rpathdir' in src/Makefile.global (post-configure), instead. > That also seems to have the positive effect of getting libpq.so to find > the shared objects that it depends on. So is the fact that I need to > edit src/Makefile.global after I run configure mean that I found a bug? ;-) Seems more like a feature request: there should be a way to override rpathdir from a configure switch. We already have an enable-rpath switch, but it's just a boolean. Maybe allow configure --enable-rpath=PATH ? regards, tom lane
Am Samstag, 3. November 2007 schrieb Tom Lane: > > That also seems to have the positive effect of getting libpq.so to find > > the shared objects that it depends on. So is the fact that I need to > > edit src/Makefile.global after I run configure mean that I found a bug? > > ;-) > > Seems more like a feature request: there should be a way to override > rpathdir from a configure switch. We already have an enable-rpath > switch, but it's just a boolean. Maybe allow > configure --enable-rpath=PATH > ? Well, the rpath option affects the rpath to our own libraries. To find the system libraries, the environment variable LD_RUN_PATH can be used. Otherwise you'd have to convince every software product in existence to add the appropriate configuration options. -- Peter Eisentraut http://developer.postgresql.org/~petere/
On Mon, Nov 05, 2007 at 08:07:04AM +0100, Peter Eisentraut wrote: > Am Samstag, 3. November 2007 schrieb Tom Lane: > > > That also seems to have the positive effect of getting libpq.so to find > > > the shared objects that it depends on. So is the fact that I need to > > > edit src/Makefile.global after I run configure mean that I found a bug? > > > ;-) > > > > Seems more like a feature request: there should be a way to override > > rpathdir from a configure switch. We already have an enable-rpath > > switch, but it's just a boolean. Maybe allow > > configure --enable-rpath=PATH > > ? > > Well, the rpath option affects the rpath to our own libraries. To find the > system libraries, the environment variable LD_RUN_PATH can be used. > Otherwise you'd have to convince every software product in existence to add > the appropriate configuration options. > > -- > Peter Eisentraut > http://developer.postgresql.org/~petere/ > We use LD_RUN_PATH in our Solaris builds for that reason. Ken