Обсуждение: 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/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
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 |
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? |
"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 ELFbased systems. It's linker does not have a -R or --rpath option. To have UnixWare's ld command embed the location ofthe shared libraries into the executable, you set the LD_RUN_PATH to the path(s) containing the libraries. From the syntaxof the --rpath option, it is apparent you are running the GNU C compiler with ELF support (an upstart, late commerin the world of ELF support). You should know that the one true path of ELF support is to use the LD_RUN_PATH environmentvariable, not -R/--rpath :-> I find it much easier to set LD_RUN_PATH then to have configure figure out thatthe 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 librarylocations 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 19026
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? |
> 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? |