Re: [HACKERS] dynamic libraries

Поиск
Список
Период
Сортировка
От Billy G. Allie
Тема Re: [HACKERS] dynamic libraries
Дата
Msg-id 199810130603.CAA07521@bgalli.mug.org
обсуждение исходный текст
Ответ на Re: [HACKERS] dynamic libraries  ("Matthew N. Dodd" <winter@jurai.net>)
Ответы Re: [HACKERS] dynamic libraries
Список pgsql-hackers
> 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    |



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Peter T Mount
Дата:
Сообщение: Sequences and jdbc 6.3.2 (fwd)
Следующее
От: "Billy G. Allie"
Дата:
Сообщение: Re: [HACKERS] TCL/TK library glitches in configure.in