On 07/22/2016 03:02 AM, Tom Lane wrote:
Michael Paquier <michael.paqu...@gmail.com> writes:
On Fri, Jul 22, 2016 at 8:48 AM, Tom Lane <t...@sss.pgh.pa.us> wrote:
I'm confused.  We need that code in both libpq and backend, no?
src/common is the place for stuff of that description.


Not necessarily. src/interfaces/libpq/Makefile uses a set of files
like md5.c which is located in the backend code and directly compiles
libpq.so with them, so one possibility would be to do the same for
sha.c: locate the file in src/backend/libpq/ and then fetch the file
directly when compiling libpq's shared library.

Meh.  That seems like a hack left over from before we had src/common.

Having said that, src/interfaces/libpq/ does have some special
requirements, because it needs the code compiled with -fpic (on most
hardware), which means it can't just use the client-side libpgcommon.a
builds.  So maybe it's not worth improving this.

src/common/Makefile says:

# This makefile generates two outputs:
#
#       libpgcommon.a - contains object files with FRONTEND defined,
#               for use by client application and libraries
#
#       libpgcommon_srv.a - contains object files without FRONTEND defined,
#               for use only by the backend binaries

It claims that libpcommon.a can be used by libraries, but without -fPIC, that's a lie.

One thing about my current set of patches is that I have begun adding
files from src/common/ to libpq's list of files. As that would be new
I am wondering if I should avoid doing so.

Well, it could link source files from there just as easily as from the
backend.  Not object files, though.

I think that's the way to go (and that's what Michael's latest patch did). But let's update the comment in the Makefile, explaining that you can also copy or symlink source files directly from src/common as needed, for instance for shared libraries.

Let's take the opportunity and also move src/backend/libpq/ip.c and md5.c into src/common. It would be weird to have sha.c in src/common, but md5.c in src/backend/libpq. Looking at ip.c, it could be split into two: some of the functions in ip.c are clearly not needed in the client, like enumerating all interfaces.

- Heikki



--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Reply via email to