Tom Lane, 2005-02-01 04:45 GMT +01:00, wrote:
Rolf Sponsel <[EMAIL PROTECTED]> 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_
---------------------------(end of broadcast)--------------------------- TIP 4: Don't 'kill -9' the postmaster
