Non-configure build of thread_test has been broken for awhile
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
On 2020-Oct-18, Tom Lane wrote:
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?
Standalone usage of that program is evidently non-existant, so +1 for
removing the Makefile and just keep the configure compile path for it.
BTW the only animal reporting without thread-safety in the buildfarm is
gaur.
Alvaro Herrera <alvherre@alvh.no-ip.org> writes:
On 2020-Oct-18, Tom Lane wrote:
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?
Standalone usage of that program is evidently non-existant, so +1 for
removing the Makefile and just keep the configure compile path for it.
I concluded that if thread_test.c will only be used by configure,
then we should stick it under $(SRCDIR)/config/ and nuke the
src/test/thread/ subdirectory altogether. See attached.
BTW the only animal reporting without thread-safety in the buildfarm is
gaur.
Yeah. At some point maybe we should just drop support for non-thread-safe
platforms, but I'm not proposing to do that yet.
regards, tom lane
Attachments:
remove-standalone-thread-testing.patchtext/x-diff; charset=us-ascii; name=remove-standalone-thread-testing.patchDownload+20-128
On Tue, Oct 20, 2020 at 12:25:48PM -0400, Tom Lane wrote:
Alvaro Herrera <alvherre@alvh.no-ip.org> writes:
On 2020-Oct-18, Tom Lane wrote:
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?Standalone usage of that program is evidently non-existant, so +1 for
removing the Makefile and just keep the configure compile path for it.I concluded that if thread_test.c will only be used by configure,
then we should stick it under $(SRCDIR)/config/ and nuke the
src/test/thread/ subdirectory altogether. See attached.
Sounds good.
--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EnterpriseDB https://enterprisedb.com
The usefulness of a cup is in its emptiness, Bruce Lee