| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Craig Ringer <craig(at)2ndquadrant(dot)com> |
| Cc: | Hiroshi Inoue <inoue(at)tpf(dot)co(dot)jp>, Andrew Dunstan <andrew(at)dunslane(dot)net>, Robert Haas <robertmhaas(at)gmail(dot)com>, Andres Freund <andres(at)2ndquadrant(dot)com>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: narwhal and PGDLLIMPORT |
| Date: | 2014-02-12 00:08:58 |
| Message-ID: | 2314.1392163738@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Craig Ringer <craig(at)2ndquadrant(dot)com> writes:
> On 02/12/2014 07:30 AM, Tom Lane wrote:
>> BTW, now that I look at this ... why are we bothering to build static
>> libraries (.a files) for DLLs? They have no possible use AFAICS.
> I don't see any use for that with plperl, but it might be a valid thing
> to be doing for (e.g.) hstore.dll. Though you can't really link to it
> from another module anyway, you have to go through the fmgr to get
> access to its symbols at rutime, so we can probably just skip generation
> of import libraries for contribs and PLs.
On second thought, I believe we need it for, say, libpq. Not sure if it's
worth adding the Makefile logic that'd be needed to not build the import
library for other cases.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2014-02-12 00:30:48 | Re: narwhal and PGDLLIMPORT |
| Previous Message | Craig Ringer | 2014-02-12 00:04:41 | Re: narwhal and PGDLLIMPORT |