Re: [Feed-back] Installing PostgreSQL 8.0.0 on SPARC/Solaris. Configure and install issues.

Hi,

I've successfully built PostgreSQL 8.0.0
on SPARC/Solaris (7), with gcc-3.2.2.
Hardware is SPARCstation 5, 170 MHz.

Because it doesn't build optimally right
out of the box, I'd like to provide you
with some feed-back.

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.

Should you need information about this
then please have a look at:

http://www.visi.com/~barr/ldpath.html
Why LD_LIBRARY_PATH is bad

During the build, I had the following
issues:

1). If I run './configure --with-pam --with-ssl' with
LD_RUN_PATH = '/usr/local/ssl/lib:/usr/local/lib'
configure will fail to find the ssl libs, if I do
not have LD_LIBRARY_PATH set.

2). If I do set LD_LIBRARY_PATH, './configure ...' will
not find OpenSSL's include files.

3). Thus, to configure/build with OpenSSL, using only
LD_RUN_PATH, i have to explicitly specify the paths
to OpenSSL's libraries and include files.

4). 'make install' fails unless LD_LIBRARY_PATH is set.

Please see the attached log file showing these issues
in deatail.

Please feel free to contact me if you should need more
information.

Hope this information helps you to improve the
installation procedures for PostgreSQL even more.

Thank you all! for your efforts, and for providing
providing this excellent piece of software.

Kind Regards,
Rolf Sponsel

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

Rolf Sponsel

___________________________________________e_n_d___o_f___m_e_s_s_a_g_e_

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.

No, the preferred thing is to set -rpath within the executable, which
we do already (see Makefile.solaris). It's possible that you need to
modify rpathdir to include /usr/local/ssl/lib and /usr/local/lib,
but I'd think that indicates fairly serious brain damage in Solaris'
runtime loader. We have many other Solaris users and none of them
have complained of this, so I wonder if you don't have something
misconfigured.

> 1). If I run './configure --with-pam --with-ssl' with
> LD_RUN_PATH = '/usr/local/ssl/lib:/usr/local/lib'
> configure will fail to find the ssl libs, if I do
> not have LD_LIBRARY_PATH set.

See configure's --with-libraries option.

regards, tom lane

Tom Lane 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.
>
> No, the preferred thing is to set -rpath within the executable, which
> we do already (see Makefile.solaris).

The problem with that is that it doesn't take effect for the run-time
tests run within configure.

--
Peter Eisentraut
http://developer.postgresql.org/~petere/

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, which
> we do already (see Makefile.solaris).

I don't think I understand what you mean by
"set -rpath within the executable".

Is this supposed to be an option to the Sun linker,
i.e. '/usr/ccs/bin/ld'?

I cannot find any information regardin to this
option in neither the man page of ld, nor gcc/g++.

Would you mind elaborating on this, please?

Ahaa!!! This might be the explanation to the "broken"
configure (with respect to postgresql executables not
having default loader paths compiled/linked-in).

Quoted from this post:

http://archive.gingerall.cz/archives/public/sablot2000/msg00283.html
Re: [Sab] Installation - HOWTO (was: Installation Problem)

>>> d) use "runtime path" linker flag for shared libs (it's very
>>> useful on systems which lack ldconfig). The correct flag
>>> syntax depends on linker, eg:
>>>
>>> Solaris ld:
>>> ld -R/path/to/lib/dir -L/path/to/lib/dir -lfoo ...
>>>
>>> Tru64 UNIX ld:
>>> ld -rpath /path/to/lib/dir -L/path/to/lib/dir -lfoo ...
>>>
>>> GNU binutils ld (eg. Linux):
>>> ld -rpath /path/to/lib/dir -L/path/to/lib/dir -lfoo ...
>>>
>>> HP-UX ld (actually, no flag is needed):
>>> ld -L/path/to/lib/dir -lfoo ...

You're sending GNU Binutils CC linker options to the
Sun linker (which probably just might ignore them),
which usually is the (best?) one used for Solaris.

Plese alseo see article #33 "Compiling Source Code".
Search for and read those paragraphs containing '-R'.

I you get the '-R' option right, for the Solaris Platform,
I guess(!?) the Sun linker takes care of LD_RUN_PATH etc.

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

Well, if nothing else, I'd take this "possibility"
as an indication of a "broken" configure process.

Sorry, never heard of rpathdir (on Solaris)!?

> 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?

And here some cases against such an theory.

1'st example: When building the Apache HTTPD Server,
I only to enable SSL/TLS support (mod_ssl) via
'./configure ... --enable-mods-shared="... ssl ..."'
and the configure script is intelligent enough
to find OpenSSL in its default location (which on
Solaris is '/usr/local/ssl' when built with gcc).

No need to explicitly point out where to find
include files and libraries (other than setenv
LD_RUN_PATH /usr/local/ssl/lib:/usr/local/lib
in order to have a default compiled-in loader
path for the executables and shared libraries).

Using LD_RUN_PATH is equivalent to specifying
the -R flag to the linker (ld). But this you
already know from reading the article, that I
provided a link to, "Why LD_LIBRARY_PATH is bad"
(and if you haven't read that article already,
then you really should; for your conveinice,
here is the link:
<http://www.visi.com/~barr/ldpath.html>
Why LD_LIBRARY_PATH is bad
).

2'nd example: Even PostgreSQL's competitor(?), MySQL,
seems to have gotten it, at least somewhat, right.
Although one has to explicitly point out the location
of the OpenSSL installation directory when running
configure (by giving the '--with-openssl=/usr/local/ssl'
option; which IMHO is far better than having to explicitly
give three options '--enable-ssl --with-libraries=\
/usr/local/ssl/lib --with-includes=/usr/local/ssl/include'
as for postgresql), the default loader path(s) are
properly compiled in according to LD_RUN_PATH (at
least for the shared libraries, although they too
seem to have missed this for the executables in
the bin directory.)

> We have many other Solaris users and none of them
> have complained of this,

Well, this might be because they are so used to
setenv LD_LIBRARY_PATH; as rutinely recommended
by many vendors, contrary to better judgement(?);
or/and don't know that that's the wrong way to do
it, and therefore strictly follow this - badly -
adviced, although working approaches (for broken
implementations).

> so I wonder if you don't have something
> misconfigured.

If that was the case, I guess I would have noticed it
a long time ago and would not have been able to build
and install e.g. Gnome 2.4 from source on Solaris 7.

>>1). If I run './configure --with-pam --with-ssl' with
>> LD_RUN_PATH = '/usr/local/ssl/lib:/usr/local/lib'
>> configure will fail to find the ssl libs, if I do
>> not have LD_LIBRARY_PATH set.
>
>
> See configure's --with-libraries option.
>
> regards, tom lane

I suppose you wrote this before I managed to supply
the logfile; which was stripped off from my post by
the mailing list (automatic?) manager, and I there-
fore provided as a separate link in a repost; see:

http://archives.postgresql.org/pgsql-bugs/2005-02/msg00005.php
[Feed-back] Installing PostgreSQL 8.0.0 on SPARC/Solaris. Configure and
install issues

or you would have noticed that I already
had figured that part out. Thanks anyway! :-)

I hope this (all too long) post helps
improving the postgres build process,
for the Solaris Platform (and maybe
enlightens some Linux developers too).

And I really hope I didn't just
suffer from a "brain outage"!!? :-)

Regards

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

Rolf Sponsel

___________________________________________e_n_d___o_f___m_e_s_s_a_g_e_

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_

I have waded through this email and the suggestion seems to be that on
Solaris we should add rpathdir based on the LD_RUN_PATH value at the
time of compile.

While this might be common on Solaris, I am not excited about
implementing it because it changes compile behavior based on an
environment variable, and this is typically not done on other platforms.
I have also not seen similar complains from other Solaris users. If
that changes, we can revisit the issue.

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

Rolf Sponsel wrote:
> 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_
>
> ---------------------------(end of broadcast)---------------------------
> TIP 5: Have you checked our extensive FAQ?
>
> http://www.postgresql.org/docs/faq
>

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073