How are people handling the fact that libpq is dynamic, and psql needs
to find it.  I don't see people using -rpath as a link option.

Are people setting LD_LIBRARY_PATH to the PostgreSQL library directory?

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  maillist@candle.pha.pa.us            |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026


Fri, 9 Oct 1998 13:10:08 -0400 (EDT)
Bruce Momjian <maillist@candle.pha.pa.us>
dynamic libraries
   How are people handling the fact that libpq is dynamic, and psql needs
   to find it.  I don't see people using -rpath as a link option.

   Are people setting LD_LIBRARY_PATH to the PostgreSQL library directory?

Using ldconfig and /etc/ld.so.conf:

     # ld.so.conf
     /usr/X11R6/lib
     /usr/pkg/lib
     /usr/local/lib
     /usr/local/pgsql/lib

This is on NetBSD 1.3.2.

Cheers,
Brook

Fri, 9 Oct 1998 11:30:41 -0600 (MDT)
Brook Milligan <brook@trillium.NMSU.Edu>
Re: [HACKERS] dynamic libraries
>
> How are people handling the fact that libpq is dynamic, and psql needs
> to find it.  I don't see people using -rpath as a link option.
>
> Are people setting LD_LIBRARY_PATH to the PostgreSQL library directory?
>

    I  have  a  /usr/local/pgsql/lib  line in the /etc/ld.so.conf
    file and run ldconfig(8)  when  I  get  any  error  from  the
    dynamic  linker  (e.g.   pg_id  fails to load libpq.so.2 :-).
    Usually the problem disappears then.


Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#======================================== jwieck@debis.com (Jan Wieck) #



Fri, 9 Oct 1998 19:44:55 +0200 (MET DST)
jwieck@debis.com (Jan Wieck)
Re: [HACKERS] dynamic libraries
>    How are people handling the fact that libpq is dynamic, and psql needs
>    to find it.  I don't see people using -rpath as a link option.
> 
>    Are people setting LD_LIBRARY_PATH to the PostgreSQL library directory?
> 
> Using ldconfig and /etc/ld.so.conf:
> 
>      # ld.so.conf
>      /usr/X11R6/lib
>      /usr/pkg/lib
>      /usr/local/lib
>      /usr/local/pgsql/lib
> 
> This is on NetBSD 1.3.2.

ELF shared libraries are new to BSDI 4.0, so I was a little confused.  I
editied ld.so.conf, but did not know I needed to run ldconfig, which I
have done figured out, and it works.

My larger question is why we don't get more reports of problems like
this.  Do novices just know to go edit ld.so.conf, and run ldconfig?

It is probably in the Linux FAQ, but is everyone reading that when they
get the error?

I am trying to figure out how to deal with this for BSDI 4.0 users.  I
am sure they are going to be confused.

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  maillist@candle.pha.pa.us            |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026


Fri, 9 Oct 1998 13:46:06 -0400 (EDT)
Bruce Momjian <maillist@candle.pha.pa.us>
Re: [HACKERS] dynamic libraries
On Fri, 9 Oct 1998, Bruce Momjian wrote:

> How are people handling the fact that libpq is dynamic, and psql needs
> to find it.  I don't see people using -rpath as a link option.
> 
> Are people setting LD_LIBRARY_PATH to the PostgreSQL library directory?

I've got the directory defined in /etc/ld.co.conf, and ran ldconfig. Works
fine since then.

-- 
       Peter T Mount peter@retep.org.uk
      Main Homepage: http://www.retep.org.uk
PostgreSQL JDBC Faq: http://www.retep.org.uk/postgres
 Java PDF Generator: http://www.retep.org.uk/pdf


Fri, 9 Oct 1998 19:48:30 +0100 (GMT)
Peter T Mount <peter@retep.org.uk>
Re: [HACKERS] dynamic libraries
On UnixWare 7.0 (and Solaris systems, also) I export LD_RUN_PATH which 
contains the paths to the dynamic libraries.  When the linker runs, it 
incorporates the paths into the output file so that LD_LIBRARY_PATH is not 
needed to find the needed dynamic libraries.
-- 
____       | Billy G. Allie    | Domain....: Bill.Allie@mug.org
|  /|      | 7436 Hartwell     | Compuserve: 76337,2061
|-/-|----- | Dearborn, MI 48126| MSN.......: B_G_Allie@email.msn.com
|/  |LLIE  | (313) 582-1540    | 



Fri, 09 Oct 1998 22:24:16 -0400
"Billy G. Allie" <Bill.Allie@mug.org>
Re: [HACKERS] dynamic libraries 
On Fri, 9 Oct 1998, Billy G. Allie wrote:
> On UnixWare 7.0 (and Solaris systems, also) I export LD_RUN_PATH which 
> contains the paths to the dynamic libraries.  When the linker runs, it 
> incorporates the paths into the output file so that LD_LIBRARY_PATH is not 
> needed to find the needed dynamic libraries.

Damnit, I'm really getting annoyed by all of this...  An ELF system should
not be using ldconfig or LD_LIBRARY_PATH to find its libraries.

ELF executables are told where to find their binaries at compile time.  On
Solaris this involves using '-R/path/to/libs' to add the a path to be
compiled into the binary.  I believe this works for Linux/ELF as well.
FreeBSD/ELF is using -rpath I think, but someone should check. (I'm
converting my 3.0-current system to ELF at the moment but its only a
486dx50 so its kind of slow.)

If PostgreSQL is not doing this IT IS BROKEN.

Regardless, do whatever you want; I keep on fixing this myself when I
compile new releases so I'm not likely to notice any further brokeness.

Have a good one.

-- 
| Matthew N. Dodd  | 78 280Z | 75 164E | 84 245DL | FreeBSD/NetBSD/Sprite/VMS |
| winter@jurai.net |      This Space For Rent     | ix86,sparc,m68k,pmax,vax  |
| http://www.jurai.net/~winter | Are you k-rad elite enough for my webpage?   |


Mon, 12 Oct 1998 01:57:37 -0400 (EDT)
"Matthew N. Dodd" <winter@jurai.net>
Re: [HACKERS] dynamic libraries 
> > On UnixWare 7.0 (and Solaris systems, also) I export LD_RUN_PATH 
> > which contains the paths to the dynamic libraries.  When the linker 
> > runs, it incorporates the paths into the output file so that 
> > LD_LIBRARY_PATH is not needed to find the needed dynamic libraries.
<gratuitous griping snipped :)>
> ...An ELF system should
> not be using ldconfig or LD_LIBRARY_PATH to find its libraries.

It sounds like you have a strong opinion on this, but I'll need more
info to help convince/educate me...

> ELF executables are told where to find their binaries at compile time. 
> On Solaris this involves using '-R/path/to/libs' to add a path to 
> be compiled into the binary.  I believe this works for Linux/ELF as 
> well. FreeBSD/ELF is using -rpath I think, but someone should check. 
> (I'm converting my 3.0-current system to ELF at the moment but its 
> only a 486dx50 so its kind of slow.)

A nice feature of putting libraries into /etc/ld.so.conf is that the
libraries are found automatically as a system resource. Hard-linking the
paths (or possible paths) in the executable seems to be a bit
restrictive.

Since ld.so.conf is a very useful feature for linking with at least some
kinds of libraries, perhaps you can suggest or point to the guidelines a
system builder would use to choose what mechanism to use for a specific
case? I could image guidelines that would say to put system-wide
resources into ld.so.conf, and user-installed resources into
LD_LIBRARY_PATH or the "-R/r" flags.

The recent bump in libpq version number (entirely appropriate imho)
illustrated the downside to using ld.so.conf in that my root account had
to rerun ldconfig to make the new library known to the system. otoh it
was really easy to do...

                      - Tom

Mon, 12 Oct 1998 14:58:28 +0000
"Thomas G. Lockhart" <lockhart@alumni.caltech.edu>
Re: [HACKERS] dynamic libraries
On Mon, 12 Oct 1998, Thomas G. Lockhart wrote:
> A nice feature of putting libraries into /etc/ld.so.conf is that the
> libraries are found automatically as a system resource. Hard-linking
> the paths (or possible paths) in the executable seems to be a bit
> restrictive.

I'm not sure how that is a feature at all.  Having loads of junk in your
library search path really slows things down.

An ELF system does not have an ld.so.conf.  (Note that FreeBSD/ELF does
have an ld.so.conf but I believe this is only for transition purposes.)

If you (the system administrator) install a package, you know where it is
installed.  You are able let the binary take care of tracking where its
libraries are supposed to be, not the system.

> Since ld.so.conf is a very useful feature for linking with at least some
> kinds of libraries, perhaps you can suggest or point to the guidelines a
> system builder would use to choose what mechanism to use for a specific
> case? I could image guidelines that would say to put system-wide
> resources into ld.so.conf, and user-installed resources into
> LD_LIBRARY_PATH or the "-R/r" flags.

Having to set LD_LIBRARY_PATH to make things work is bogus; what if
someone forgets to set it?  What if a user can't edit ld.so.conf (ignoring
the fact that it won't exist on a real ELF system).

Compiling the information into the binary is much prefered.  If for some
reason you have to move the libraries, using LD_LIBRARY_PATH to keep them
running is a good bandaid until you can recimpile or edit the compiled in
paths (if your system supports such tools.)

> The recent bump in libpq version number (entirely appropriate imho)
> illustrated the downside to using ld.so.conf in that my root account had
> to rerun ldconfig to make the new library known to the system. otoh it
> was really easy to do...

Elf systems have no 'major' version number.  On an a.out system you'd get
something like 'libpq.so.1.1'.  ELF would call this library 'libpq1.so'
which would be a link to 'libpq1.so.1'.  If the 'major' number is to be
changed (ie: an incompatible interface change was made) you must change
the name of the library.  For a.out it would become 'libpq.so.2.0' and ELF
'libpq2.so -> libpq2.so.0'.

Anyhow, in summary, depending on enviornment variables or a hacked linkrer
that supports 'ld.so.conf' is a bad thing on a real ELF system.  ELF
provides for compiled in search paths and they should be used.  This
reduces the additional steps a user must take to have a running system and
does not violate the POLA.  Since the compile/build process knows where
the install destination will be, nothing prevents it from doing the right
thing and using '-R' or '-rpath' ld(1) directives to set the search path.

I've done the whole LD_LIBRARY_PATH and it sucks; I had one that was
nearly a page long.  How the heck do you maintain such a thing and make
sure nobody else introduces a trojaned library that appears earlier in
your path?

-- 
| Matthew N. Dodd  | 78 280Z | 75 164E | 84 245DL | FreeBSD/NetBSD/Sprite/VMS |
| winter@jurai.net |      This Space For Rent     | ix86,sparc,m68k,pmax,vax  |
| http://www.jurai.net/~winter | Are you k-rad elite enough for my webpage?   |


Mon, 12 Oct 1998 11:36:07 -0400 (EDT)
"Matthew N. Dodd" <winter@jurai.net>
Re: [HACKERS] dynamic libraries
> Anyhow, in summary, depending on enviornment variables or a hacked linkrer
> that supports 'ld.so.conf' is a bad thing on a real ELF system.  ELF
> provides for compiled in search paths and they should be used.  This
> reduces the additional steps a user must take to have a running system and
> does not violate the POLA.  Since the compile/build process knows where
> the install destination will be, nothing prevents it from doing the right
> thing and using '-R' or '-rpath' ld(1) directives to set the search path.

Just to comment.  If we use -R or -rpath, people need to use that for
_every_ application that uses libpq, etc.  That seems like a pain to me.

B1ecause people have not had problems in the past using ld.so.conf, and I
can see them having problems with -R or -rpath, I would hesistate to
change it, though I can see why some installations would prefer the
-R/-rpath.

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  maillist@candle.pha.pa.us            |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026


Mon, 12 Oct 1998 12:01:50 -0400 (EDT)
Bruce Momjian <maillist@candle.pha.pa.us>
Re: [HACKERS] dynamic libraries
On Mon, 12 Oct 1998, Bruce Momjian wrote:
> Just to comment.  If we use -R or -rpath, people need to use that for
> _every_ application that uses libpq, etc.  That seems like a pain to me.

The alternative is more painful.  If PostgreSQL were the only application
package installed on a system your LD_LIBRARY_PATH would be really short.

> B1ecause people have not had problems in the past using ld.so.conf, and I
> can see them having problems with -R or -rpath, I would hesistate to
> change it, though I can see why some installations would prefer the
> -R/-rpath.

I'll continue to ignore the fact that some ELF systems do have a
bastardized runtime linker and use ld.so.conf when I state that ELF
systems have no ld.so.conf, so its LD_LIBRARY_PATH or -R/--rpath (I looked
up the flag finally.)

ld.so.conf or ldconfig with various directories on the command line is
necessary for a non-ELF system; this is the way you do things.  ELF fixes
this (the problem is when you have a zillion different directories to
search for libraries in and it starts taking a long time to start
dynamically linked programs on a loaded system.  I'll assume everyoen sees
the security problems with a system wide library path.)  So for a.out or
other non-ELF systems, I'm proposing no change; do whatever works.  For
ELF, the specification supports compiled in library search paths; lets use
them.  Asking the system administrator to keep track of another library
path is most assuming.  -R/--rpath also makes it simpler for non-root
users to install PostgreSQL.

-- 
| Matthew N. Dodd  | 78 280Z | 75 164E | 84 245DL | FreeBSD/NetBSD/Sprite/VMS |
| winter@jurai.net |      This Space For Rent     | ix86,sparc,m68k,pmax,vax  |
| http://www.jurai.net/~winter | Are you k-rad elite enough for my webpage?   |


Mon, 12 Oct 1998 12:18:13 -0400 (EDT)
"Matthew N. Dodd" <winter@jurai.net>
Re: [HACKERS] dynamic libraries
"Matthew N. Dodd" wrote:
  >  For
  >ELF, the specification supports compiled in library search paths; lets use
  >them.  Asking the system administrator to keep track of another library
  >path is most assuming.  -R/--rpath also makes it simpler for non-root
  >users to install PostgreSQL.
 
If you do this, Debian Linux will consider it a bug and I shall have to take
it out for the Debian package.  From Debian documentation:

   "`-rpath' can cause big problems if the referenced
    libraries get updated. Therefore, no Debian package should use the
    `-rpath' option."


-- 
Oliver Elphick                                Oliver.Elphick@lfix.co.uk
Isle of Wight                              http://www.lfix.co.uk/oliver
               PGP key from public servers; key ID 32B8FAA1
                 ========================================
     "Blessed is the man who makes the LORD his trust, 
      who does not look to the proud, to those who turn 
      aside to false gods."            Psalms 40:4 



Mon, 12 Oct 1998 21:20:59 +0100
"Oliver Elphick" <olly@lfix.co.uk>
Re: [HACKERS] dynamic libraries 
On Mon, 12 Oct 1998, Oliver Elphick wrote:
> "Matthew N. Dodd" wrote:
>   >  For
>   >ELF, the specification supports compiled in library search paths; lets use
>   >them.  Asking the system administrator to keep track of another library
>   >path is most assuming.  -R/--rpath also makes it simpler for non-root
>   >users to install PostgreSQL.
>  
> If you do this, Debian Linux will consider it a bug and I shall have to take
> it out for the Debian package.  From Debian documentation:
>
>    "`-rpath' can cause big problems if the referenced
>     libraries get updated. Therefore, no Debian package should use the
>     `-rpath' option."

Yes, since Debian distributes binary packages where users can install the
package anywhere they like, compiling in a search path causes problems.

Let me ask you though, when was the last time you updated the shared libs
and didn't update the utils that used them?  Regardless, under ELF, a
major number change will require relinking anyway as ELF has no 'major
revision number'.

A solution would be to compile in multiple probable locations for the
library in to the binary.  Another solution is to beat users up until they
no longer have the desire to install packages in non-standard places.

Regardless, just because Debian or any other system can't figure out how
to do library versioning doesn't mean it should handycap any correct ELF
library solution.  The little warning you pased about -rpath is bogus; if
the library changes and the minor version is bumped, no problems will be
experienced because, by definition, such changes do not alter behavior.
A change that would cause problems will require a relink anyway as you're
no longer linking against the same library.  (libpq1.so.0 vs libpq2.so.0).

For those of you coming from an a.out or other background, your libraries
aren't going to be named the same.  I am not proposing any changes to the
a.out library naming.

ELF provides compiled in library search paths for a reason; it is the
correct thing to do.  How it effects binary packages of a particluar OS
(FreeBSD, NetBSD, Debian or whatever) is beyond the scope of the
postgresql development project.  I'm pretty sure postgresql is provided in
source form for that reason. :)

BTW, you misspelled 'Debian GNU/Linux'.

-- 
| Matthew N. Dodd  | 78 280Z | 75 164E | 84 245DL | FreeBSD/NetBSD/Sprite/VMS |
| winter@jurai.net |      This Space For Rent     | ix86,sparc,m68k,pmax,vax  |
| http://www.jurai.net/~winter | Are you k-rad elite enough for my webpage?   |


Mon, 12 Oct 1998 16:40:05 -0400 (EDT)
"Matthew N. Dodd" <winter@jurai.net>
Re: [HACKERS] dynamic libraries 
"Matthew N. Dodd" wrote:
  >Let me ask you though, when was the last time you updated the shared libs
  >and didn't update the utils that used them? 

Well, using Debian's packaging system, I don't have to worry about it; the
dependencies should take care of such things...
  > ...
  >Regardless, just because Debian or any other system can't figure out how
  >to do library versioning doesn't mean it should handycap any correct ELF
  >library solution.  The little warning you pased about -rpath is bogus; if
  >the library changes and the minor version is bumped, no problems will be
  >experienced because, by definition, such changes do not alter behavior.
  >A change that would cause problems will require a relink anyway as you're
  >no longer linking against the same library.  (libpq1.so.0 vs libpq2.so.0).

I've been trying to find any more information than the single sentence I
quoted; there was nothing in the documentation on my own system. 

  >BTW, you misspelled 'Debian GNU/Linux'.
 
Sheer laziness!

-- 
Oliver Elphick                                Oliver.Elphick@lfix.co.uk
Isle of Wight                              http://www.lfix.co.uk/oliver
               PGP key from public servers; key ID 32B8FAA1
                 ========================================
     "Blessed is the man who makes the LORD his trust, 
      who does not look to the proud, to those who turn 
      aside to false gods."            Psalms 40:4 



Mon, 12 Oct 1998 22:52:17 +0100
"Oliver Elphick" <olly@lfix.co.uk>
Re: [HACKERS] dynamic libraries 
> On Mon, 12 Oct 1998, Bruce Momjian wrote:
> > Just to comment.  If we use -R or -rpath, people need to use that for
> > _every_ application that uses libpq, etc.  That seems like a pain to me.
> 
> The alternative is more painful.  If PostgreSQL were the only application
> package installed on a system your LD_LIBRARY_PATH would be really short.
> 
> > B1ecause people have not had problems in the past using ld.so.conf, and I
> > can see them having problems with -R or -rpath, I would hesistate to
> > change it, though I can see why some installations would prefer the
> > -R/-rpath.
> 
> I'll continue to ignore the fact that some ELF systems do have a
> bastardized runtime linker and use ld.so.conf when I state that ELF
> systems have no ld.so.conf, so its LD_LIBRARY_PATH or -R/--rpath (I looked
> up the flag finally.)
> 
> ld.so.conf or ldconfig with various directories on the command line is
> necessary for a non-ELF system; this is the way you do things.  ELF fixes
> this (the problem is when you have a zillion different directories to
> search for libraries in and it starts taking a long time to start
> dynamically linked programs on a loaded system.  I'll assume everyoen sees
> the security problems with a system wide library path.)  So for a.out or
> other non-ELF systems, I'm proposing no change; do whatever works.  For
> ELF, the specification supports compiled in library search paths; lets use
> them.  Asking the system administrator to keep track of another library
> path is most assuming.  -R/--rpath also makes it simpler for non-root
> users to install PostgreSQL.

Matthew:

I am running UnixWare 7.01, a System V Release 4 based system.  It is an ELF based system with roots back to the first ELF based systems.  It's linker does not have a -R or --rpath option.  To have UnixWare's ld command embed the location of the shared libraries into the executable, you set the LD_RUN_PATH to the path(s) containing the libraries.  From the syntax of the --rpath option, it is apparent you are running the GNU C compiler with ELF support (an upstart, late commer in the world of ELF support).  You should know that the one true path of ELF support is to use the LD_RUN_PATH environment variable, not -R/--rpath :->  I find it much easier to set LD_RUN_PATH then to have configure figure out that the a system is running GNU C with ELF support and for that system only, use -R/--rpath.  Check out your ld command.  If it supports LD_LIBRARY_PATH, it probably supprorts LD_RUN_PATH.  If it does, then use it to embed the library locations into your executable.
-- 
____       | Billy G. Allie    | Domain....: Bill.Allie@mug.org
|  /|      | 7436 Hartwell     | Compuserve: 76337,2061
|-/-|----- | Dearborn, MI 48126| MSN.......: B_G_Allie@email.msn.com
|/  |LLIE  | (313) 582-1540    | 



Tue, 13 Oct 1998 02:03:09 -0400
"Billy G. Allie" <Bill.Allie@mug.org>
Re: [HACKERS] dynamic libraries 
Folks,

    this   debate   is  becoming  more  and  more  a  philosophic
    discussion about "if it is right to force end  users  to  use
    -rpath  or  ld.so.conf".   I  think  it's  not the PostgreSQL
    developers teams subject to make a  decision  about  it.  And
    even if, I think we cannot make such a decision until release
    schedule of 6.4.

    PostgreSQL should be easily installable out of  the  box.  On
    systems  where  ld.so.conf  is  the defacto standard, forcing
    -rpath will be IMHO a drawback against PostgreSQL  (the  user
    already made his OS decision). If using a search path means a
    loss of performance or security, systems where  this  is  the
    standard  way  have  other  problems  than  those coming with
    PostgreSQL.

    We can clearify in the installation instructions  that  using
    ld.so.conf  requires  root  permissions  any time the library
    interface changes or LD_LIBRARY_PATH can be used  (if  a  non
    privileged user wants to play around with it).

    For 6.5 we could discuss if using ld.so.conf, LD_LIBRARY_PATH
    or -rpath could become a configure option.

    What we never should do is to be arrogant and say "PostgreSQL
    MUST  be  installed  using  the  ONE  and ONLY correct way of
    shared library usage".   This  would  only  become  a  pseudo
    argument against PostgreSQL.

    Let's  all calm down and release. There are end users waiting
    for the capabilities of 6.4. They don't care  about  how  the
    shared libs are used as long as it's easy to use them.


Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#======================================== jwieck@debis.com (Jan Wieck) #



Tue, 13 Oct 1998 09:50:07 +0200 (MET DST)
jwieck@debis.com (Jan Wieck)
Re: [HACKERS] dynamic libraries
>     Let's  all calm down and release. There are end users waiting
>     for the capabilities of 6.4. They don't care  about  how  the
>     shared libs are used as long as it's easy to use them.

Don't panic Jan! I took up the discussion because Matthew seemed to have
strong opinions on a subject that afaik is not an issue really. So I was
hoping to learn more about the fine points, and I think I have.

It looks like there may be pros and cons to each method, but for me the
"old style" of using ld.conf.so allows some independence between apps
and library location that -rpath/-R may not.

I would expect that, as Jan suggests, it is best to leave the choice to
the installer.

Anyway, if Matthew wants to write up the way one would put an entry for
LDFLAGS or LDFLAGS_SO or ?? in a Makefile.custom to get the behavior he
is advocating I would be happy to include it in the Admin/installation
docs as an installation tip or alternative.

Matthew?

                     - Tom

Tue, 13 Oct 1998 14:26:23 +0000
"Thomas G. Lockhart" <lockhart@alumni.caltech.edu>
Re: [HACKERS] dynamic libraries
On Tue, 13 Oct 1998, Billy G. Allie wrote:
> I am running UnixWare 7.01, a System V Release 4 based system.  It is
> an ELF based system with roots back to the first ELF based systems.  
> It's linker does not have a -R or --rpath option.  To have UnixWare's
> ld command embed the location of the shared libraries into the
> executable, you set the LD_RUN_PATH to the path(s) containing the
> libraries.

Ok.

> From the syntax of the --rpath option, it is apparent you are running
> the GNU C compiler with ELF support (an upstart, late commer in the
> world of ELF support).  

Actually, while I did mention --rpath (In the context of a FreeBSD/ELF or
Linux/ELF system) I am running Solaris which uses the -R flag to tell
ld(1) where things are.  -R takes prescedence over LD_RUN_PATH according
to my doc.

> You should know that the one true path of ELF support is to use the
> LD_RUN_PATH environment variable, not -R/--rpath :-> I find it much
> easier to set LD_RUN_PATH then to have configure figure out that the a
> system is running GNU C with ELF support and for that system only, use
> -R/--rpath.  Check out your ld command.  If it supports
> LD_LIBRARY_PATH, it probably supprorts LD_RUN_PATH.  If it does, then
> use it to embed the library locations into your executable.

I'm pretty sure all ELF systems support LD_LIBRARY_PATH and LD_RUN_PATH.
Using -R/--rpath allows us to have better control of what search paths are
compiled in.  Who knows what the user has LD_RUN_PATH set to.  Should
configure ask them if they want to use LD_RUN_PATH as well?  Should we
find all the libraries we are to link with and construct our own
-R/--rpath?  For systems that don't support -R/--rpath we'll have to do
this anyway as we'll be messing with LD_RUN_PATH.

-- 
| Matthew N. Dodd  | 78 280Z | 75 164E | 84 245DL | FreeBSD/NetBSD/Sprite/VMS |
| winter@jurai.net |      This Space For Rent     | ix86,sparc,m68k,pmax,vax  |
| http://www.jurai.net/~winter | Are you k-rad elite enough for my webpage?   |


Tue, 13 Oct 1998 11:15:43 -0400 (EDT)
"Matthew N. Dodd" <winter@jurai.net>
Re: [HACKERS] dynamic libraries 
> >     Let's  all calm down and release. There are end users waiting
> >     for the capabilities of 6.4. They don't care  about  how  the
> >     shared libs are used as long as it's easy to use them.
> 
> Don't panic Jan! I took up the discussion because Matthew seemed to have
> strong opinions on a subject that afaik is not an issue really. So I was
> hoping to learn more about the fine points, and I think I have.
> 
> It looks like there may be pros and cons to each method, but for me the
> "old style" of using ld.conf.so allows some independence between apps
> and library location that -rpath/-R may not.
> 
> I would expect that, as Jan suggests, it is best to leave the choice to
> the installer.
> 
> Anyway, if Matthew wants to write up the way one would put an entry for
> LDFLAGS or LDFLAGS_SO or ?? in a Makefile.custom to get the behavior he
> is advocating I would be happy to include it in the Admin/installation
> docs as an installation tip or alternative.

Frankly, I think the environment variable LD_RUN_PATH is the only way to
go(see man ld.so).  Setting the flag on every link, and for user apps
too, seems too painful for regular use.

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  maillist@candle.pha.pa.us            |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026


Tue, 13 Oct 1998 11:24:33 -0400 (EDT)
Bruce Momjian <maillist@candle.pha.pa.us>
Re: [HACKERS] dynamic libraries
On Tue, 13 Oct 1998, Thomas G. Lockhart wrote:
> Anyway, if Matthew wants to write up the way one would put an entry for
> LDFLAGS or LDFLAGS_SO or ?? in a Makefile.custom to get the behavior he
> is advocating I would be happy to include it in the Admin/installation
> docs as an installation tip or alternative.
> 
> Matthew?

When I install 6.4 on the systems here I'll see if I can make clean
patches and submit them.

Like I said in my first message this is a sore subject only because I run
into it so much and few software packages seem to deal with it correctly.
What PostgreSQL does won't really affect me as I'll just keep doing what
I've been doing (along with lots of cursing).  If my patches are of any
use then maybe PostgreSQL won't be on my list of things to fix shared libs
before compiling.

Anyhow, getting 6.4 out is of paramount importance so this discussion is
academic at this point.

-- 
| Matthew N. Dodd  | 78 280Z | 75 164E | 84 245DL | FreeBSD/NetBSD/Sprite/VMS |
| winter@jurai.net |      This Space For Rent     | ix86,sparc,m68k,pmax,vax  |
| http://www.jurai.net/~winter | Are you k-rad elite enough for my webpage?   |


Tue, 13 Oct 1998 12:05:32 -0400 (EDT)
"Matthew N. Dodd" <winter@jurai.net>
Re: [HACKERS] dynamic libraries
> Anyhow, getting 6.4 out is of paramount importance so this discussion 
> is academic at this point.

Well, I was proposing that you document how to use the -rpath/-R style
of building the v6.4beta. If you can do that in the next few days then
it can appear in the v6.4 docs. If not, then it will wait for sometime
later. 

In either case, we aren't proposing to change the current methods, which
are independent of loader configuration and options (for example, those
installing into /usr/lib just need to reboot to get ldconfig run), but
rather allowing you to document the way you would suggest doing it.

Your choice...

                   - Tom

Tue, 13 Oct 1998 18:34:44 +0000
"Thomas G. Lockhart" <lockhart@alumni.caltech.edu>
Re: [HACKERS] dynamic libraries
On Tue, 13 Oct 1998, Thomas G. Lockhart wrote:
> Well, I was proposing that you document how to use the -rpath/-R style
> of building the v6.4beta. If you can do that in the next few days then
> it can appear in the v6.4 docs. If not, then it will wait for sometime
> later. 
> 
> In either case, we aren't proposing to change the current methods, which
> are independent of loader configuration and options (for example, those
> installing into /usr/lib just need to reboot to get ldconfig run), but
> rather allowing you to document the way you would suggest doing it.

Well, for Solaris I've always added '-R' flags that correspond to the
various -L flags in the appropriate make files.  Since $(LIBDIR) is equal
to $(POSTGRESDIR)/lib which is the final installation directory it kind of
makes sense to use '-R' as we're only specifying additional linker search
directories as supplied to us by the user.  I suppose for Unixware we
could 'setenv LD_RUN_PATH $(LIBDIR)' or something.

-- 
| Matthew N. Dodd  | 78 280Z | 75 164E | 84 245DL | FreeBSD/NetBSD/Sprite/VMS |
| winter@jurai.net |      This Space For Rent     | ix86,sparc,m68k,pmax,vax  |
| http://www.jurai.net/~winter | Are you k-rad elite enough for my webpage?   |


Tue, 13 Oct 1998 14:39:29 -0400 (EDT)
"Matthew N. Dodd" <winter@jurai.net>
Re: [HACKERS] dynamic libraries