Rolf Sponsel 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

Search Discussions

  • Peter Eisentraut at Feb 1, 2005 at 10:10 am

    Tom Lane 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.
    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.
  • Rolf Sponsel at Feb 5, 2005 at 5:46 pm
    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 <[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,
    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_

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppgsql-ports @
categoriespostgresql
postedFeb 1, '05 at 3:45a
activeFeb 5, '05 at 5:46p
posts3
users3
websitepostgresql.org
irc#postgresql

People

Translate

site design / logo © 2023 Grokbase