On Thu, Aug 18, 2016 at 9:28 PM, Heikki Linnakangas <hlinn...@iki.fi> wrote: >> # 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.
Yes. >>> 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. Updating that is a good idea. > 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. It would be definitely better to do all that before even moving sha.c. For the current ip.c, I don't have a better idea than putting in src/common/ip.c the set of routines used by both the frontend and backend, and have fe_ip.c the new file that has the frontend-only things. Need a patch? -- Michael -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
