On Wed, Mar 10, 2010 at 10:51:23AM -0500, Tom Lane wrote:
> =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= writes:
> > -LDFLAGS="-Wl,--allow-multiple-definition"
> > +LDFLAGS="${LDFLAGS} -Wl,--allow-multiple-definition"
>
> That bit seems sane.
I've committed that part. Thanks.
--
Noah Misch
Enterprise
2010/3/12 Dag-Erling Smørgrav :
> Tom Lane writes:
>> Any such platform would already be contending with plpgsql not working,
>> encoding conversion not working, etc etc. It's barely conceivable that
>> a client-only installation would be useful.
>
> Uh, I don't understand why it's so hard to con
Tom Lane writes:
> Any such platform would already be contending with plpgsql not working,
> encoding conversion not working, etc etc. It's barely conceivable that
> a client-only installation would be useful.
Uh, I don't understand why it's so hard to conceive that someone might
need the client
On Thu, Mar 11, 2010 at 01:34:34PM -0800, Steve Atkins wrote:
> On Mar 11, 2010, at 1:06 PM, Tom Lane wrote:
> >
> > BTW, I'm not sure I buy the argument that commercial software
> > requires static linking. Red Hat would be as interested in that
> > market as anybody, and as I said, they don't t
On Mar 11, 2010, at 1:06 PM, Tom Lane wrote:
>
>
> BTW, I'm not sure I buy the argument that commercial software requires
> static linking. Red Hat would be as interested in that market as
> anybody, and as I said, they don't think it's necessary to ship static
> libraries (with a *very* short
Greg Stark writes:
> The two (separate) goals which are useful are 1) Provide a library
> others can link against to produce a binary which has no run-time
> dependency on your library. In this case the only library they might
> want to link against would be libpq. The encoding libraries etc aren'
Tom Lane wrote:
Now libpq doesn't often have critical security bugs filed against it,
but it certainly has bugs. Do you really want to have to remember to
rebuild every piece of dependent software when you update it? The OP's
case apparently involves multiple independent libraries that he wan
2010/3/11 Tom Lane :
> Now libpq doesn't often have critical security bugs filed against it,
> but it certainly has bugs. Do you really want to have to remember to
> rebuild every piece of dependent software when you update it?
I absolutely agree that linking statically is a terrible idea for
dis
Greg Stark writes:
> 2010/3/10 David Fetter :
--disable-shared, as previously mentioned.
>>
>> +1 for de-supporting this option.
> I would be sad about this. It seems likely there are platforms where
> it's important.
Any such platform would already be contending with plpgsql not working,
Magnus Hagander writes:
> In particular, libpq only exports a fixed subset of symbols on any
> platform that supports that (which includes Windows).
> AFAIK, there is no way to make that restriction on static libraries,
> at least not on Windows.
Right, and not anyplace else either except by pre
2010/3/11 Dag-Erling Smørgrav :
> Greg Stark writes:
>> I would be sad about this. It seems likely there are platforms where
>> it's important. But I'm not really about to spend the effort to fix it
>> up myself and I agree it wouldn't be worth hacking the source to get
>> it to work. I'm a bit pu
Greg Stark writes:
> I would be sad about this. It seems likely there are platforms where
> it's important. But I'm not really about to spend the effort to fix it
> up myself and I agree it wouldn't be worth hacking the source to get
> it to work. I'm a bit puzzled why the symbol conflicts occur o
2010/3/10 David Fetter :
>> > --disable-shared, as previously mentioned.
>>
>> Oh. Well, we don't really support that, and there is a proposal on
>> the table to remove it altogether from the configure script. I
>> don't think we're going to contort our source code in order to make
>> a marginal
On Wed, Mar 10, 2010 at 01:28:55PM -0500, Tom Lane wrote:
> =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= writes:
> > Tom Lane writes:
> >> It builds for everybody else (and we do have multiple mingw
> >> machines in the buildfarm, so it's not like this doesn't get
> >> tested). I think there is some oth
=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= writes:
> Tom Lane writes:
>> It builds for everybody else (and we do have multiple mingw machines in
>> the buildfarm, so it's not like this doesn't get tested). I think there
>> is some other factor involved here, and you need to identify what that
>> is.
Tom Lane writes:
> "Dag-Erling Smørgrav" writes:
> > Without this patch, pg_ctl fails to build...
> It builds for everybody else (and we do have multiple mingw machines in
> the buildfarm, so it's not like this doesn't get tested). I think there
> is some other factor involved here, and you need
=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= writes:
> Magnus Hagander writes:
>> But the fix seems wrong. If you are using a static libpq, the library
>> should be added whenever you link that library into your client
>> application. Not for every single EXE and DLL that postgres produces.
> Without th
Tom Lane writes:
> We don't support linking the backend into other applications.
libpq uses this as well.
> If you're complaining about libpq, the right thing for that is to use
> a platform that can suppress non-exported symbols from a shared
> library. Maybe what we need to do is teach the mi
Magnus Hagander writes:
> Dag-Erling Smørgrav writes:
> > Your users might need to link with both. I'm working on an
> > application that generates animations (specifically, animated
> > weather forecasts) based on data retrieved from a PostgreSQL
> > database.
> This shows up only with static
=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= writes:
> Tom Lane writes:
>> "Dag-Erling Smørgrav" writes:
>>> 1. PostgreSQL's private versions of inet_aton etc. can conflict with
>>> similar functions in other libraries (in my case, PostgreSQL's
>>> inet_aton conflicts with libavformat's).
>> So what?
2010/3/10 Dag-Erling Smørgrav :
> Tom Lane writes:
>> "Dag-Erling Smørgrav" writes:
>> > 1. PostgreSQL's private versions of inet_aton etc. can conflict with
>> > similar functions in other libraries (in my case, PostgreSQL's
>> > inet_aton conflicts with libavformat's).
>> So what? We
Tom Lane writes:
> "Dag-Erling Smørgrav" writes:
> > 1. PostgreSQL's private versions of inet_aton etc. can conflict with
> > similar functions in other libraries (in my case, PostgreSQL's
> > inet_aton conflicts with libavformat's).
> So what? We don't link with those libraries.
Your
=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= writes:
> I've run across a couple of stumbling blocks when building on Win32
> (specifically, XP + MinGW):
> 1. PostgreSQL's private versions of inet_aton etc. can conflict with
> similar functions in other libraries (in my case, PostgreSQL's
> inet_
23 matches
Mail list logo
