Re: Re: [PATCHES] Makefile.PL for Pg.so

From: Peter Eisentraut <peter_e(at)gmx(dot)net>
To: Lamar Owen <lamar(dot)owen(at)wgcr(dot)org>
Cc: Larry Rosenman <ler(at)lerctr(dot)org>, PostgreSQL Hackers List <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Re: [PATCHES] Makefile.PL for Pg.so
Date: 2001-08-26 12:37:25
Message-ID: Pine.LNX.4.30.0108261429020.699-100000@peter.localdomain
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-patches

Lamar Owen writes:

> Pg.so does not get the proper RPATH in a DESTDIR build environment.
>
> Trying to fix this for the RPMS -- the RPATH contains the buildroot instead
> of where the libs really are. Could cause security problems. Working on it,
> but it's slow going for me at this busy time.

Another fun feature of the DESTDIR build environment is that the
writability test of the target directory will most likely fail because it
doesn't exist at all.

I've been thinking how I'd like to fix this: We add an option to
configure that says to *not* install the Perl module into the standard
Perl tree, but instead somewhere under our own $prefix. That way people
that don't have root access can use this option and still install the
whole tree in one run. But then we'd remove that writability check and
people that have root access or failed to use that option will get a hard
failure. This would create a much more reliable and predictable build
environment.

Comments? And a good name for such an option?

--
Peter Eisentraut peter_e(at)gmx(dot)net http://funkturm.homeip.net/~peter

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2001-08-26 16:11:25 Re: Re: [PATCHES] Makefile.PL for Pg.so
Previous Message Tom Lane 2001-08-26 06:42:00 C++ and bool constants (was Re: [NOVICE] gcc 3.0.1)

Browse pgsql-patches by date

  From Date Subject
Next Message Tom Lane 2001-08-26 16:11:25 Re: Re: [PATCHES] Makefile.PL for Pg.so
Previous Message Barry Lind 2001-08-26 07:58:50 Re: [BUGS] Bug #428: Another security issue with the JDBC driver.