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

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) #

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

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

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.

It's in the INSTALL file. Or at least it was.
-DEJ

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.

It's in the INSTALL file. Or at least it was.

I have updated the INSTALL and sgml/INSTALL files to recommend ldconfig
on Linux/ELF and any ELF-based system.

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

I have updated the INSTALL and sgml/INSTALL files to recommend ldconfig
on Linux/ELF and any ELF-based system.

It's not an ELF thing! This applies to any (I think) shared library
system. At least I know my NetBSD a.out system uses ldconfig in this
way. Your note should be more general.

Cheers,
Brook

I have updated the INSTALL and sgml/INSTALL files to recommend ldconfig
on Linux/ELF and any ELF-based system.

It's not an ELF thing! This applies to any (I think) shared library
system. At least I know my NetBSD a.out system uses ldconfig in this
way. Your note should be more general.

Yes, I wanted to improve it too. ELF came with SVr4, and the Linux
mention, while valuable for a large base of users, was misleading to others.

Here is the new text:

If necessary, tell UNIX how to find your shared libraries. If you
are using an ELF-based system, such as Linux, do ONE of the following,
preferably the first:

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

Yes, I wanted to improve it too. ELF came with SVr4, and the Linux
mention, while valuable for a large base of users, was misleading to others.

Here is the new text:

If necessary, tell UNIX how to find your shared libraries. If you
are using an ELF-based system, such as Linux, do ONE of the following,
preferably the first:

I'm not sure what your list is that follows this, but if it includes
either LD_LIBRARY_PATH or /etc/ld.so.conf and ldconfig, then your
restriction to ELF is not correct. (And why single out Linux for
special notes when postgresql applies MUCH more broadly and ELF is
MUCH more widely used than on Linux boxes?)

Perhaps you can say something like

If necessary, tell UNIX how to find your shared libraries.
Commonly, ONE of the following (preferably the first) is
sufficient:

- mention /etc/ld.so.conf and ldconfig
- mention LD_LIBRARY_PATH
...

If there really are system-specific things, they can be added to the
list with a caveat about their applicability.

Cheers,
Brook

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 |

If necessary, tell UNIX how to find your shared libraries.
Commonly, ONE of the following (preferably the first) is
sufficient:

- mention /etc/ld.so.conf and ldconfig
- mention LD_LIBRARY_PATH
...

If there really are system-specific things, they can be added to the
list with a caveat about their applicability.

I have changed it to:

14) If necessary, tell UNIX how to find your shared libraries. You can
do ONE of the following, preferably the first:

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

On Fri, 9 Oct 1998, Bruce Momjian wrote:

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.

It's in the INSTALL file. Or at least it was.

I have updated the INSTALL and sgml/INSTALL files to recommend ldconfig
on Linux/ELF and any ELF-based system.

ldconfig was there before ELF became popular.

When I originally started using Linux back in 94, I was using Slackware,
and it used aout. ldconfig was in use 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

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

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

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

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

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

"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

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