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?
--
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
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/libThis 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/libThis 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
Import Notes
Resolved by subject fallback
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 19026On 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 19026On 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? |
"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
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 |
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) #
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
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? |
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 19026On 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? |
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
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? |