Skip site navigation (1) Skip section navigation (2)

Re: PG Patch (fwd) [openserver patch followup #2]

From: Larry Rosenman <ler(at)lerctr(dot)org>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: pgsql-patches(at)postgresql(dot)org, jkj(at)sco(dot)com
Subject: Re: PG Patch (fwd) [openserver patch followup #2]
Date: 2003-07-25 09:52:28
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-patches

--On Friday, July 25, 2003 11:58:18 +0200 Peter Eisentraut 
<peter_e(at)gmx(dot)net> wrote:

> Larry Rosenman writes:
>> I disagree STRONGLY with what you are saying here.  What harm does it do
>> to add the ABILITY for a port to use a ABSOLUTE DT_SONAME?
> We can discuss adding the ability, but I'm against enforcing it by
> default.
>> I belive that the issue is not broken systems, but broken practice.
> No, the issue is precisely that someone is proposing to break reasonable,
> useful practice to accomodate broken systems.  No one is claiming that
> absolute sonames make the system more featureful or useful.  In fact, it
> was admitted that it would have the reverse effect.  The only argument for
> absolute sonames that was brought forth was that some older systems have
> security holes that can be worked around in this manner.
For an example of ADDING to the usefulness, UnixWare has no, or 
ldconfig equivalent.  For ALL my PostgreSQL apps, I either need to specify 
on the EXECUTABLE build, or make sure there is a GLOBAL LD_LIBRARY_PATH 
variable set.

The absolute DT_SONAME will fix that issue on THIS platform, which is why 
of an INDIVIDUAL port to set an absolute DT_SONAME would be useful.


Larry Rosenman           
Phone: +1 972-414-9812                 E-Mail: ler(at)lerctr(dot)org
US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749

In response to


pgsql-patches by date

Next:From: Peter EisentrautDate: 2003-07-25 09:58:18
Subject: Re: PG Patch (fwd) [openserver patch followup #2]
Previous:From: Larry RosenmanDate: 2003-07-25 09:22:31
Subject: Re: PG Patch (fwd) [openserver patch followup #2]

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group