Обсуждение: 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