On 12/12/2011 02:59 PM, Tom Lane wrote:
Peter Eisentraut writes:
On lör, 2011-12-10 at 20:26 -0500, Tom Lane wrote:
Right now, libpq laboriously rebuilds all the .o files it needs from
src/port/ so as to get them with -fpic. It would be nice if we could
clean that up while we're doing this
On 12/12/2011 02:59 PM, Tom Lane wrote:
Peter Eisentraut writes:
On lör, 2011-12-10 at 20:26 -0500, Tom Lane wrote:
Right now, libpq laboriously rebuilds all the .o files it needs from
src/port/ so as to get them with -fpic. It would be nice if we could
clean that up while we're doing this
Peter Eisentraut writes:
> On lör, 2011-12-10 at 20:26 -0500, Tom Lane wrote:
>> Right now, libpq laboriously rebuilds all the .o files it needs from
>> src/port/ so as to get them with -fpic. It would be nice if we could
>> clean that up while we're doing this. It might be all right to always
On fre, 2011-12-09 at 11:13 -0500, Andrew Dunstan wrote:
> Is there any good reason why we shouldn't build and install a dynamic
> libpgport.so?
Just note, if you do this, you need to carefully manage API, ABI,
soname, symbol list, and all that. Every time you tweak configure's
decision about wh
On lör, 2011-12-10 at 20:26 -0500, Tom Lane wrote:
> > The other
> > thing is we'd need to turn on flags that make the object suitable for a
> > dynamic library (e.g. -fpic).
>
> Right now, libpq laboriously rebuilds all the .o files it needs from
> src/port/ so as to get them with -fpic. It wo
On 12/10/2011 08:26 PM, Tom Lane wrote:
The other
thing is we'd need to turn on flags that make the object suitable for a
dynamic library (e.g. -fpic).
Right now, libpq laboriously rebuilds all the .o files it needs from
src/port/ so as to get them with -fpic. It would be nice if we could
c
Andrew Dunstan writes:
> On 12/09/2011 06:27 PM, Bruce Momjian wrote:
>> 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?
> Possibly. Below is a list
On 12/09/2011 06:27 PM, Bruce Momjian wrote:
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 intende
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 f
On 12/09/2011 01:01 PM, Steve Singer wrote:
On 11-12-09 11:13 AM, Andrew Dunstan wrote:
Recently I attempted to build an external package (pg_bulkload)
against the latest Fedora packages. Unfortunately this fails, as pgxs
adds "-lpgport" to any link line for an executable, and the
correspond
On 11-12-09 11:13 AM, Andrew Dunstan wrote:
Recently I attempted to build an external package (pg_bulkload)
against the latest Fedora packages. Unfortunately this fails, as pgxs
adds "-lpgport" to any link line for an executable, and the
corresponding libpgport.a isn't there. And in fact, pg_bu
On 9 December 2011 16:13, Andrew Dunstan wrote:
> Is there any good reason why we shouldn't build and install a dynamic
> libpgport.so?
+1 in favour of building and installing a dynamic libpgport.so. I
generally agree with your analysis.
I've seen this issue crop up a good few times now. I'm a F
Recently I attempted to build an external package (pg_bulkload) against
the latest Fedora packages. Unfortunately this fails, as pgxs adds
"-lpgport" to any link line for an executable, and the corresponding
libpgport.a isn't there. And in fact, pg_bulkload does use some of the
functionality th
13 matches
Mail list logo
