From: | Bruce Momjian <bruce(at)momjian(dot)us> |
---|---|
To: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
Cc: | Steve Singer <ssinger(at)ca(dot)afilias(dot)info>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: static or dynamic libpgport |
Date: | 2011-12-09 23:27:13 |
Message-ID: | 201112092327.pB9NRDd11340@momjian.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Andrew Dunstan wrote:
> >> Is there any good reason why we shouldn't build and install a dynamic
> >> libpgport.so?
> >
> > +1
> >
> > We've struggled with slony and pgport because so many users have had
> > problems with pgport not being included in some distributions. It has
> > some useful functions, I think recent versions of slony use it on
> > win32 but don't elsewhere. Wee have had at least one patch floating
> > around that makes conditionally includes certain small behaviours in
> > slony based on if pgport is available or not based on a configure check.
> >
> > What package would a shared static pgport be installed with? Slony
> > requires a server + headers to build but slon and slonik only have a
> > runtime dependency on libpq (I don't know if anyone installs
> > slon/slonik on a machine without a postgresql server but you could)
> >
> >
>
> In the Fedora world, a static lib would go in postgresql-devel, but a
> dynamic lib would go in postgresql-libs, which is also where libpq is
> shipped.
I am not against shipping a dynamic libpgport, but I will just point out
that this was never intended or anticipated. Are there any symbols in
there that might conflict with other software?
--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
From | Date | Subject | |
---|---|---|---|
Next Message | Ants Aasma | 2011-12-09 23:48:45 | Re: Timing overhead and Linux clock sources |
Previous Message | Noah Misch | 2011-12-09 22:41:47 | Re: RangeVarGetRelid() |