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

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_