Re: PL/Perl without shared libperl.a - Mailing list pgsql-general

From Peter Eisentraut
Subject Re: PL/Perl without shared libperl.a
Date
Msg-id Pine.LNX.4.30.0105112347260.757-100000@peter.localdomain
Whole thread Raw
In response to Re: PL/Perl without shared libperl.a  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-general
Tom Lane writes:

> Hmm.  Or perhaps we could just go ahead and try to build libperl.so,
> but not abort the make if it fails.  The reason for the shlib test
> originally was that we didn't want the whole build of Postgres to blow
> up if we couldn't link libperl.so.  Seems like you end up with no
> libperl.so either way, so perhaps we could hack the Makefile to not
> treat link failure as fatal.  The trick is that it's a makefile
> generated by MakeMaker and not entirely under our control...

Or we could get rid of that makefile and write our own.  MakeMaker is a
piece of gar^H^H^Hoverengineering anyway.  I have such a makefile worked
out as a proof of concept I did a while ago.  I find it a lot better in
many ways already.

What I would suggest in any case is that we test at configure time (no
time like configure time) whether libperl is shared (using the current,
official mechanism).  If not, we print a warning message and disable the
build.  If the user wants to try it anyway we could provide some way to
override it, e.g., (stupid) --with-perl=i_want_plperl, or they could go
into the directory and build it there.

--
Peter Eisentraut   peter_e@gmx.net   http://funkturm.homeip.net/~peter


pgsql-general by date:

Previous
From: will trillich
Date:
Subject: Re: Postgresql newbie username/password question
Next
From: will trillich
Date:
Subject: Re: Synonym