Michael Paquier <michael.paquier@gmail.com> writes:
> On Sun, Aug 21, 2016 at 3:02 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> I looked into this and soon found that fe_utils/string_utils.o has
>> dependencies on libpq that are much wider than just pqexpbuffer :-(.
> pqexpbuffer.c is an independent piece of facility, so we could move it
> to src/common and leverage the dependency a bit, and have libpq link
> to the source file itself at build phase. The real problem is the call
> to PQmblen in psqlscan.l... And this, I am not sure how this could be
> refactored cleanly.
I see all of these as libpq dependencies in string_utils.o:
U PQclientEncoding U PQescapeStringConn U PQmblen U
PQserverVersion
Maybe we could split that file into two parts (libpq-dependent and not)
but it would be pretty arbitrary.
> And actually, I had a look at the build failure that you reported in
> 3855.1471713949@sss.pgh.pa.us. While that was because of a copy of
> libpq.so that I had in my own LD_LIBRARY_PATH, shouldn't all the other
> frontend utilities depending on fe_utils also use $(libpq_pgport)
> instead of -lpq?
All the rest of them already have that, because their link commands
look like, eg for psql,
LDFLAGS += -L$(top_builddir)/src/fe_utils -lpgfeutils -lpq
psql: $(OBJS) | submake-libpq submake-libpgport submake-libpgfeutils$(CC) $(CFLAGS) $(OBJS) $(libpq_pgport) $(LDFLAGS)
$(LDFLAGS_EX)$(LIBS) -o $@$(X) ^^^^^^^^^^^^^^^^^^^^^^^^^^
The extra reference to -lpq just makes sure that references to libpq from
libpgfeutils get resolved properly. (And yeah, there are some platforms
that need that :-(.) We don't need an extra copy of the -L flag.
This is all pretty messy, not least because of the way libpq_pgport
is set up; as Makefile.global notes,
# ... This does cause duplicate -lpgport's to appear
# on client link lines.
Likely it would be better to refactor all of this so we get just one
reference to libpq and one reference to libpgport, but that'd require
a more thoroughgoing cleanup than you have here. (Now that I think
about it, adding -L/-l to LDFLAGS is pretty duff coding style to
begin with --- we should be adding those things to LIBS, or at least
putting them just before LIBS in the command lines.)
You're right that I missed the desirability of invoking
submake-libpq and submake-libpgfeutils in initdb's build.
Will fix that.
regards, tom lane
