Skip site navigation (1) Skip section navigation (2)

Re: [Feed-back] Installing PostgreSQL 8.0.0 on SPARC/Solaris.

From: Rolf Sponsel <Rolf(dot)Sponsel(at)kstr(dot)lth(dot)se>
To: pgsql-bugs(at)postgresql(dot)org
Cc: pgsql-ports(at)postgresql(dot)org, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>,peter_e(at)gmx(dot)net
Subject: Re: [Feed-back] Installing PostgreSQL 8.0.0 on SPARC/Solaris.
Date: 2005-02-05 17:45:48
Message-ID: 4205064C.2070308@kstr.lth.se (view raw or flat)
Thread:
Lists: pgsql-bugspgsql-hackerspgsql-ports
Okay, I've now succeeded to build with
default runtime paths built/linked in,
although not using the optimal solution
(see end of this message).

Please see further comments in-lined below ...

Rolf Sponsel, 2005-02-04 23:26 GMT +01:00, wrote:

> 
> Tom Lane, 2005-02-01 04:45 GMT +01:00, wrote:
> 
>> Rolf Sponsel <Rolf(dot)Sponsel(at)kstr(dot)lth(dot)se> writes:
>>
>>> From my understanding, the preferred way
>>> for Solaris is to only set LD_RUN_PATH,
>>> and avoid setting LD_LIBRARY_PATH, at
>>> link-time. This is what I usually do.
> 
> And usually works very well.
> 
>> No, the preferred thing is to set -rpath within the executable,

When using the Sun linker the preferred way is to use the '-R' flag.

>> which we do already (see Makefile.solaris).

Yes, you do (via "rpath = -Wl,-R$(rpathdir)"
but you fail to set the proper library paths,
i.e. the value of rpathdirs (which indirectly
was confirmed by Tom Lane).

>
> ... DELETED ...
>
> I you get the '-R' option right, for the Solaris Platform,

You have gotten the '-R' flag right in Makefile.solaris,
but fail to feed it with the correct argument(s), as
mentioned above.

> I guess(!?) the Sun linker takes care of LD_RUN_PATH etc.

No need to guess anymore. Here is the answer, taken from
the Sun ld man page (for Solaris 7); an this is why the
build scripts fail to incorporate the default runtime
paths explicitly specified by me via LD_RUN_PATH:

...
      LD_RUN_PATH
                An alternative mechanism for specifying a  runpath
                to  the  link-editor  (see  -R  option).  If  both
                LD_RUN_PATH  and the -R option are  specified,  -R
                supersedes.
...

> 
>>                                        It's possible that you need to
>> modify rpathdir to include /usr/local/ssl/lib and /usr/local/lib,

Correct! One needs to modify the "rpathdir", although I
don't know how to do this, and this should be taken care
of automagically by the build scripts.

> Well, if nothing else, I'd take this "possibility"
> as an indication of a "broken" configure process.
> 
> Sorry, never heard of rpathdir (on Solaris)!?

Okay, I see, this is not a Solaris specific
parameter, it's a build related parameter.

>> but I'd think that indicates fairly serious brain damage in Solaris'
>> runtime loader. 
> 
> 
> I'd be interested in knowing from what
> point of view you make that conclusion?
> 
> ... DELETED ...
> 
> And I really hope I didn't just
> suffer from a "brain outage"!!? :-)

Seems like I had a tiny one anyhow :-)

* * * * *

BUG 1:

When building postgresql-8.0.0 on SPARC/Solaris 7,
compiling with gcc-3.2.2, and linking with the Sun
linker '/usr/ccs/bin/ld', no default runtime paths
(other than '/usr/local/pgsql/lib') are "hard-wired"
into the executables and shared libraries.

This regardless of whether runtime paths have been
explicitly specified via LD_RUN_PATH, or not.

FIX 1: (Preferred)

Make sure to provide necessary runtime paths to the
linker, e.g. via the rpathdir macro/variable.

In order to provide additional flexibility, and for
becoming backward compatible with comon procedures
on the Solaris platform, it would be even better to
derive the value for rpathdir from the environment
variable LD_RUN_PATH whenever it's been defined.

* * *

BUG 2:

The current configure script doesn't automagically
detect an OpenSSL installation that resided in the
default location (i.e. '/usr/local/ssl', when built
from source with gcc on Solaris), without having to
explicitly specify the location of OpenSSL via the
configure options '--with-libraries=/usr/local/ssl/lib'
and '--with-includes='/usr/local/ssl/include' when
enabling SSL/TLS support via '--with-openssl'.

FIX 2: (Preferred)

To be considered "well-behaving" it should manage
to automagically detect OpenSSL installed in the
default location (and also supply a default runtime
path, to the OpenSSL libraries, to the Sun linker).

For non-standard situations, when OpenSSL does not
reside in one of it's default locations, it would
be preferrable to have the possibility to specify
the location as an argument to the '--with-openssl'
option, e.g. like '--with-openssl=/non-std/loc/ssl'.

* * * * *

INTERIM SOLUTION in order to BUILD PostgreSQL 8.0.0
with default runtime paths "hard-wired" into shared
libraries and executables (until the bugs described
above have been fixed).

As I haven't figured out how to explicitly specify
the runtime paths via "rpathdir" I'll use the 2'nd
best approach, according to my knowledge, i.e. by
replacing the "rpath = -Wl,-R$(rpathdir)" statement
(found in 'src/makefiles/Makefile.solaris') with
"rpath =", which is responsible for not succeeding
when using LD_RUN_PATH.

Step by step instructions:

myhost(1)# wget -nv ftp://..../postgresql-8.0.0.tgz
myhost(2)# tar zxvf postgresql-8.0.0.tgz
myhost(3)# cd postgresql-8.0.0
myhost(4)# echo $PATH
/usr/local/bin:/usr/ccs/bin:/usr/dt/bin:/usr/openwin/bin:/usr/sbin:/usr/bin:/bi\
n:/usr/xpg4/bin:/usr/ucb
myhost(5)# setenv LD_RUN_PATH 
/usr/local/pgsql/lib:/usr/local/ssl/lib:/usr/local/lib
myhost(6)#
myhost(6)# echo "PATCH for src/makefiles/Makefile.solaris" > /dev/null
myhost(7)# cp -p src/makefiles/Makefile.solaris 
src/makefiles/Makefile.solaris-GENERIC
myhost(8)# echo "Now EDIT src/makefiles/Makefile.solaris before 
proceeding" > /dev/null
myhost(9)# diff src/makefiles/Makefile.solaris-GENERIC 
src/makefiles/Makefile.solaris
9c9
< rpath = -Wl,-R$(rpathdir)
---
 > rpath =
myhost(10)#
myhost(10)# unsetenv LD_LIBRARY_PATH
myhost(11)#
myhost(11)# ./configure --with-pam --with-openssl 
--with-libraries=/usr/local/ssl/lib --with-includes=/usr/local/ssl/include
myhost(12)# make
myhost(13)# make install

... and you should be done,
and there should be no need
to either set LD_LIBRARY_PATH,
nor to include '/usr/local/lib'
and '/usr/local/ssl/lib' in
your system's runtime path(s),
e.g. via clre [or whatever it
is called on Solaris 8,9,10?].

* * * * *

Hope this helps at least someone!

And, YES, this *is* a BUG REPORT! ;-)

And, Feed-back is very welcome too! :-)


Regards

-- 
----
------
--------

Rolf Sponsel

___________________________________________e_n_d___o_f___m_e_s_s_a_g_e_

In response to

Responses

pgsql-ports by date

Next:From: Paul S. KwanDate: 2005-02-08 01:07:19
Subject: PostgreSQL 8.0.0 on SuSE 9 platform questions...
Previous:From: Robert TreatDate: 2005-02-05 14:54:57
Subject: Re: Réf. : Re: Réf. : Re: [PORTS]

pgsql-hackers by date

Next:From: Matthew T. O'ConnorDate: 2005-02-05 18:03:17
Subject: Re: Patch Count?
Previous:From: Tom LaneDate: 2005-02-05 17:42:10
Subject: Re: Fixing flat user/group files at database startup

pgsql-bugs by date

Next:From: VladimirDate: 2005-02-06 10:26:10
Subject: BUG #1462: install bug
Previous:From: Dirk LutzebaeckDate: 2005-02-05 16:45:53
Subject: Re: BUG #1453: NULLs in UNION query

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group