Horton

Thread

  1. Re: [HACKERS] Building Postgres

    Tom Lane <tgl@sss.pgh.pa.us> — 1999-06-21T21:35:02Z

    Thomas Lockhart <lockhart@alumni.caltech.edu> writes:
> I am wrong about this one (the shared library *is* built during "make
> all"), but am still looking for suggestions for the right way to phase
> the building for an installation. Do other platforms have statically
> built apps too?

The only really good, cross-platform solution that I know about is to
start using GNU "libtool" to manage the construction of the shared
libraries and the applications that depend on them.  There are enough
different ways to handle (or mishandle) shared libs on different Unix
platforms that I do not think it a good use of our time to try to solve
the problem piecemeal; we'd just be reinventing libtool, probably not
very well.

I have it on my to-do list to incorporate libtool into the Postgres
build system, but I have been putting off actually doing anything,
because I don't think that the current release of libtool is quite there
on supporting multiple levels of library dependencies (pgtclsh depends
on libpgtcl.so depends on libpq.so...).  This feature was originally
promised for libtool 1.3 but has been put off to 1.4.

In the meantime, I'd suggest living with the static-library build, or
else installing libpq and then repeating the build step for psql...

			regards, tom lane

  2. Re: [HACKERS] Building Postgres

    Thomas Lockhart <lockhart@alumni.caltech.edu> — 1999-06-22T05:44:37Z

    > In the meantime, I'd suggest living with the static-library build, or
> else installing libpq and then repeating the build step for psql...

For v6.5, I think I'm going to do the phased build (the "repeating"
option). But I'm pretty sure I'll do it with a patch to the top level
Makefile, and will suggest it as a feature for v6.6, so this phasing
can be repeated.

It's an interesting problem, since preparing an rpm involves building
the entire app, and then copying pieces like libraries into the binary
rpm file. For the basic pieces this looks fairly straightforward,
except for the phasing problem mentioned above, but for some packages
like perl and pythong it apparently involves modifying configuration
files in the perl or python distribution itself. Hopefully there will
be a reasonable way to do it...

                      - Thomas

-- 
Thomas Lockhart				lockhart@alumni.caltech.edu
South Pasadena, California

  3. Perl library (was Building Postgres)

    Thomas Lockhart <lockhart@alumni.caltech.edu> — 1999-06-28T15:02:56Z

    > For v6.5, I think I'm going to do the phased build (the "repeating"
> option).

OK, I think I've got a good start at a Postgres-6.5 rpm set. It will
have the apps using shared libraries, rather than static links. It
includes more interfaces than past rpms, including ODBC, and I've
separated out the language-specific features into separate rpms (e.g.
the tcl interfaces are in postgres-tcl-6.5-1.rpm).

I'm now trying to package the perl (and next, python) interfaces. Can
someone with perl installation experience give me some hints on what
actually needs to be installed and how it has to happen?

The Postgres source tree uses a perl-based make system which ends up
with very installation-specific and perl-version-specific target
paths, but I don't know if these paths are actually used in the final
product. Will I need to put Makefile.PL, etc., in the binary rpm
itself, and build the perl interface on the fly for every target
machine? Can I instead just plop some files into the proper place on
the target machine in a version-independent way?

                       - Thomas

-- 
Thomas Lockhart				lockhart@alumni.caltech.edu
South Pasadena, California

  4. Re: [HACKERS] Perl library (was Building Postgres)

    Maarten Boekhold <boekhold@tibco.com> — 1999-06-28T15:14:48Z

    > I'm now trying to package the perl (and next, python) interfaces. Can
> someone with perl installation experience give me some hints on what
> actually needs to be installed and how it has to happen?

Me thinks the guy who's building the Debian packages should have some
experience with these. IIRC that'd be Oliver Elphick (?).

(just imagine, redhat and debian cooperating, hell must be freezing
over ;)

Maarten

-- 

Maarten Boekhold, boekhold@tibco.com
TIBCO Finance Technology Inc.
The Atrium
Strawinskylaan 3051
1077 ZX Amsterdam, The Netherlands
tel: +31 20 3012158, fax: +31 20 3012358
http://www.tibco.com

  5. Re: [HACKERS] Perl library (was Building Postgres)

    Mark Hollomon <mhh@nortelnetworks.com> — 1999-06-28T15:50:27Z

    Thomas Lockhart wrote:
> 
> > For v6.5, I think I'm going to do the phased build (the "repeating"
> > option).
> 
> OK, I think I've got a good start at a Postgres-6.5 rpm set. It will
> have the apps using shared libraries, rather than static links. It
> includes more interfaces than past rpms, including ODBC, and I've
> separated out the language-specific features into separate rpms (e.g.
> the tcl interfaces are in postgres-tcl-6.5-1.rpm).
> 
> I'm now trying to package the perl (and next, python) interfaces. Can
> someone with perl installation experience give me some hints on what
> actually needs to be installed and how it has to happen?
> 
> The Postgres source tree uses a perl-based make system which ends up
> with very installation-specific and perl-version-specific target
> paths, but I don't know if these paths are actually used in the final
> product. Will I need to put Makefile.PL, etc., in the binary rpm
> itself, and build the perl interface on the fly for every target
> machine? Can I instead just plop some files into the proper place on
> the target machine in a version-independent way?

The incantation
perl -MConfig -e 'print $Config{archlib},"\n"'

will give you the directory where things need to go.

The pm file goes directly in archlib. The sharedlib and the bootstrap
file go in <archlib>/auto/<extension-name>

<archlib>/Postgres.pm
<archlib>/auto/Postgres/Postgres.so
<archlib>/auto/Postgres/Postgres.bs

That would be a start.

---
Mark Hollomon
mhh@nortelnetworks.com

  6. Re: Perl library (was Building Postgres)

    Cristian Gafton <gafton@redhat.com> — 1999-06-30T04:26:12Z

    On Mon, 28 Jun 1999, Thomas Lockhart wrote:

> machine? Can I instead just plop some files into the proper place on
> the target machine in a version-independent way?

On a Red Hat system you can use /usr/lib/perl5/site_perl, for example.
That is not dependent on perl version.

Cristian
--
----------------------------------------------------------------------
Cristian Gafton    --     gafton@redhat.com     --       Red Hat, Inc.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 UNIX is user friendly. It's just selective about who its friends are.

  7. Re: Perl library (was Building Postgres)

    Edmund Mergl <e.mergl@bawue.de> — 1999-06-30T04:56:20Z

    Cristian Gafton wrote:
> 
> On Mon, 28 Jun 1999, Thomas Lockhart wrote:
> 
> > machine? Can I instead just plop some files into the proper place on
> > the target machine in a version-independent way?
> 
> On a Red Hat system you can use /usr/lib/perl5/site_perl, for example.
> That is not dependent on perl version.
> 
> Cristian
> --
> ----------------------------------------------------------------------
> Cristian Gafton    --     gafton@redhat.com     --       Red Hat, Inc.
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>  UNIX is user friendly. It's just selective about who its friends are.


if you install a perl module in the standard way (make install)
on a RedHat system, you will end up with the modules installed in:

   /usr/lib/perl5/site_perl/5.005/i386-linux/

A standard Makfile.PL does not contain any information about 
the target directories. This is always handled by perl itself.



Edmund


-- 
Edmund Mergl
mailto:E.Mergl@bawue.de
http://www.bawue.de/~mergl

  8. Re: Perl library (was Building Postgres)

    Thomas Lockhart <lockhart@alumni.caltech.edu> — 1999-06-30T13:16:26Z

    Hi Cristian! Glad you surfaced ;)

> > machine? Can I instead just plop some files into the proper place on
> > the target machine in a version-independent way?
> On a Red Hat system you can use /usr/lib/perl5/site_perl, for example.
> That is not dependent on perl version.

I see that now. For some reason the postgres v6.4.2 spec file didn't
quite handle the new perl tree, but between these hints and looking at
the mod_perl package (the perl extensions for apache) I think I see
how to do things.

Thanks for the help! I'm pretty sure I'm close to having some more
capable rpms for v6.5 than we've had in the past, but it wasn't at all
trivial! It's uncovered several small problems in our make system
which prevented this from happening earlier.

I'll be posting these on the Postgres web site for folks to test;
would you like me to send you a copy directly to look at? Somehow we
should coordinate this so my postgresql-6.5-1 doesn't conflict with
one coming from a RedHat distribution...

Regards.

                    - Thomas

-- 
Thomas Lockhart				lockhart@alumni.caltech.edu
South Pasadena, California