Non-configure build of thread_test has been broken for awhile

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Non-configure build of thread_test has been broken for awhile
Date: 2020-10-18 17:20:12
Message-ID: 227659.1603041612@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

If you go into src/test/thread/ and type "make", you get
a bunch of "undefined reference to `pg_fprintf'" failures.
That's because thread_test.c #include's postgres.h but
the Makefile doesn't bother to link it with libpgport,
arguing (falsely) that that might not exist yet.

Presumably, this has been busted on all platforms since
96bf88d52, and for many years before that on platforms
that have always used src/port/snprintf.c.

Configure's use of the program works anyway because it doesn't
use the Makefile and thread_test.c doesn't #include postgres.h
when IN_CONFIGURE.

It doesn't really seem sane to me to support two different build
environments for thread_test, especially when one of them is so
little-used that it can be broken for years before we notice.
So I'd be inclined to rip out the Makefile and just consider
that thread_test.c is *only* meant to be used by configure.
If we wish to resurrect the standalone build method, we could
probably do so by adding LIBS to the Makefile's link command
... but what's the point, and what will keep it from getting
broken again later?

regards, tom lane

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alexander Lakhin 2020-10-18 18:00:00 Re: Sometimes the output to the stdout in Windows disappears
Previous Message Tom Lane 2020-10-18 16:27:36 Re: pg_restore error message during ENOSPC with largeobj