Bug 226042 - databases/postgresql95-client fails to build: "not thread-safe"
Summary: databases/postgresql95-client fails to build: "not thread-safe"
Status: Open
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Only Me
Assignee: pgsql
URL:
Keywords:
: 226604 (view as bug list)
Depends on:
Blocks:
 
Reported: 2018-02-19 12:48 UTC by oz42
Modified: 2018-03-14 16:07 UTC (History)
2 users (show)

See Also:
bugzilla: maintainer-feedback? (pgsql)


Attachments
config.log (23.83 KB, application/x-bzip)
2018-02-20 07:54 UTC, oz42
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description oz42 2018-02-19 12:48:30 UTC
databases/postgresql95-client fails to build, and I assume the reason is this:

root@betsy:/usr/ports/databases/postgresql95-client/work/postgresql-9.5.11/src/test/thread # make
make: "/usr/ports/databases/postgresql95-client/work/postgresql-9.5.11/src/test/thread/Makefile" line 13: Could not find ../../../src/Makefile.global
make: "/usr/ports/databases/postgresql95-client/work/postgresql-9.5.11/src/test/thread/Makefile" line 15: Missing dependency operator
make: Fatal errors encountered -- cannot continue
make: stopped in /usr/ports/databases/postgresql95-client/work/postgresql-9.5.11/src/test/thread
root@betsy:/usr/ports/databases/postgresql95-client/work/postgresql-9.5.11/src/test/thread # find /usr/ports/ -name Makefile.global


So making postgresql95-client fails with the error

checking thread safety of required library functions... no
configure: error: thread test program failed
This platform is not thread-safe.
Comment 1 Palle Girgensohn freebsd_committer 2018-02-19 16:25:40 UTC
Hi,

I cannot reproduce this. You cannot run BSD make in the postgresql source tree, as you suggest, so I don't really understand what goes wrong. What is your platform? uname -a? a log from the failing build would also be great.

Can you show some more insights into what goes wrong?

What happens when you run
cd /usr/ports/databases/postgresql95-client
make clean all


Regards,
Palle
Comment 2 oz42 2018-02-20 07:54:51 UTC
Created attachment 190819 [details]
config.log

Hi,

sorry for the confusion. My host runs 11.1-RELEASE-p6 amd64

When I run portupgrade databases/postgresql95-client

the build fails:

checking for sgml2xml... no
checking for sx... no
checking thread safety of required library functions... no
configure: error: thread test program failed
This platform is not thread-safe.  Check the file 'config.log' or compile
and run src/test/thread/thread_test for the exact reason.
Use --disable-thread-safety to disable thread safety.
===>  Script "configure" failed unexpectedly.

config.log is attached.

I tried to build src/test/thread/thread_test, but it failed also. So I assume that the failed build of the test tool lets the whole build fail.
Comment 3 oz42 2018-02-20 08:48:49 UTC
Hmm, I tried a first-time build on another 11.1-RELEASE-p6 amd64 machine and got:

# cd /usr/ports/databases/postgresql95-client
# make
===>   postgresql95-client-9.5.11 depends on package: pkgconf>=1.3.0_1 - found
===>   postgresql95-client-9.5.11 depends on executable: gmake - found
===>   postgresql95-client-9.5.11 depends on executable: msgfmt - found
===>   postgresql95-client-9.5.11 depends on file: /usr/local/lib/libcrypto.so.42 - found
===>   postgresql95-client-9.5.11 depends on package: perl5>=5.24<5.25 - found
===>   postgresql95-client-9.5.11 depends on shared library: libreadline.so.7 - found (/usr/local/lib/libreadline.so.7)
===>   postgresql95-client-9.5.11 depends on shared library: libintl.so - found (/usr/local/lib/libintl.so)
===>  Configuring for postgresql95-client-9.5.11
env: ./configure: No such file or directory
===>  Script "configure" failed unexpectedly.
Please report the problem to pgsql@FreeBSD.org [maintainer] and attach the
"/usr/ports/databases/postgresql95-client/work/postgresql-9.5.11/config.log"

But there is no config.log

Could it be that ccache is confused? I use it on both hosts. When I disable ccache on this (2nd) host, I get the same error as in comment #2.
Comment 4 Palle Girgensohn freebsd_committer 2018-02-20 08:55:13 UTC
Seems a bit suspicions. I use ccacche as well. Your ports tree and build chain are of course up to date, just double checking.

It tends to fail on thread-safe issues. What's in your /etc/make.conf?

Palle
Comment 5 oz42 2018-02-20 09:06:45 UTC
My make.conf:

.if !defined(NO_CCACHE)
CC=/usr/local/libexec/ccache/world/cc
CXX=/usr/local/libexec/ccache/world/c++
.endif

.if ${.CURDIR:M*/ports/devel/ccache}
NO_CCACHE=yes
.endif

KERNCONF=OZ
NO_KERNELCLEAN=yes
MODULES_OVERRIDE=accf_http accf_data tmpfs

CCACHE_DIR=/var/cache/ccache

KERNCONF=OZ
MODULES_OVERRIDE= accf_http accf_data tmpfs

OPTIONS_UNSET= NIS
OPTIONS_UNSET+= X11
OPTIONS_UNSET+= DOCS
OPTIONS_UNSET+= DEBUG

# base, openssl, openssl-devel, libressl or libressl-devel:
DEFAULT_VERSIONS+= ssl=libressl



I have just completed a 1st time build of bash on host #2 without problems.
Comment 6 Palle Girgensohn freebsd_committer 2018-02-20 09:22:55 UTC
libressl differs from standard, could it be the culprit? I think not since wou have --without-openssl, but could you perhaps try building without SSL altogether just to see if it makes a difference?
Comment 7 oz42 2018-02-20 12:20:35 UTC
Sorry, no. Instead, I have installed a virtual FreeBSD meanwhile and compiled postgresql-client successfully, so it is no SSL issue.

That system is now building world and kernel, after that I will try to compile the client again.
Comment 8 oz42 2018-02-20 13:18:56 UTC
Update: I have built world and kernel, now building the client fails.

My src.conf:

WITH_SYSTEM_COMPILER=YES
#
WITHOUT_ACCT=YES
WITHOUT_AMD=YES
WITHOUT_ATM=YES
WITHOUT_AUDIT=YES
WITHOUT_AUTHPF=YES
WITHOUT_AUTOFS=YES
WITHOUT_BHYVE=YES
WITHOUT_BLUETOOTH=YES
WITHOUT_BOOTPD=YES
WITHOUT_BSNMP=YES
WITHOUT_CALENDAR=YES
WITHOUT_CAPSICUM=YES
WITHOUT_CASPER=YES
WITHOUT_CCD=YES
WITHOUT_CDDL=YES
WITHOUT_CLANG_BOOTSTRAP=YES
WITHOUT_CLANG_FULL=YES
WITHOUT_CLANG_EXTRAS=YES
WITHOUT_CROSS_COMPILER=YES
# WITHOUT_CRYPT=YES
WITHOUT_CTM=YES
WITHOUT_CUSE=YES
WITHOUT_DEBUG_FILES=YES
WITHOUT_DICT=YES
WITHOUT_DMAGENT=YES
WITHOUT_ED_CRYPTO=YES
WITHOUT_EXAMPLES=YES
WITHOUT_FINGER=YES
WITHOUT_FLOPPY=YES
# WITHOUT_FORTH=YES
WITHOUT_FTP=YES
WITHOUT_GAMES=YES
WITHOUT_GCC=YES
WITHOUT_GCOV=YES
WITHOUT_GDB=YES
WITHOUT_GSSAPI=YES
WITHOUT_HAST=YES
WITHOUT_HTML=YES
WITHOUT_HYPERV=YES
# WITHOUT_INET6=YES
WITHOUT_IPFILTER=YES
# WITHOUT_IPFW=YES
WITHOUT_ISCSI=YES
WITHOUT_JAIL=YES
WITHOUT_KDUMP=YES
WITHOUT_KERBEROS=YES
WITHOUT_KERNEL_SYMBOLS=YES
WITHOUT_KVM=YES
# WITHOUT_LEGACY_CONSOLE=YES
# -- only on x64
WITHOUT_LIB32=YES
WITHOUT_LLDB=YES
WITHOUT_LPR=YES
WITHOUT_MAILWRAPPER=YES
WITHOUT_NDIS=YES
WITHOUT_NETGRAPH=YES
WITHOUT_NIS=YES
WITHOUT_OPENSSH=YES
# WITHOUT_OPENSSL=YES
WITHOUT_PF=YES
WITHOUT_PMC=YES
WITHOUT_PPP=YES
WITHOUT_PROFILE=YES
WITHOUT_QUOTAS=YES
WITHOUT_RADIUS_SUPPORT=YES
WITHOUT_RBOOTD=YES
WITHOUT_RCMDS=YES
WITHOUT_RCS=YES
WITHOUT_RESCUE=YES
WITHOUT_ROUTED=YES
WITHOUT_SENDMAIL=YES
WITHOUT_SHAREDOCS=YES
WITHOUT_TALK=YES
WITHOUT_TCP_WRAPPERS=YES
WITHOUT_TESTS=YES
WITHOUT_TFTP=YES
WITHOUT_TIMED=YES
WITHOUT_USB=YES
WITHOUT_WIRELESS=YES
WITHOUT_WPA_SUPPLICANT_EAPOL=YES
WITHOUT_ZFS=YES
Comment 9 Palle Girgensohn freebsd_committer 2018-02-20 22:53:25 UTC
Wow, that is indeed a very restricted build.

I can't see why any of those WITHOUTs should make the thread safe configure check fail, but it seems it does.

The threadsafe stuff is there for some plpython to work, so you can probably live without it. You could try this patch to see if that is the only problem:


Index: databases/postgresql10-server/Makefile
===================================================================
--- databases/postgresql10-server/Makefile	(revision 462308)
+++ databases/postgresql10-server/Makefile	(working copy)
@@ -39,12 +39,9 @@
 LDFLAGS+=	-L${LOCALBASE}/lib
 INCLUDES+=	-I${LOCALBASE}/include
 CONFIGURE_ARGS+=--with-libraries=${PREFIX}/lib \
-		--with-includes=${PREFIX}/include \
-		--enable-thread-safety
+		--with-includes=${PREFIX}/include
 CONFIGURE_ENV+=	INCLUDES="${INCLUDES}" \
-		PTHREAD_LIBS="-lpthread" \
 		LDFLAGS_SL="${LDFLAGS_SL}"
-LDFLAGS+=	-lpthread
 
 PLIST=		${PKGDIR}/pkg-plist${COMPONENT}
 
@@ -102,7 +99,7 @@
 # (requires dump/restore if modified.)
 OPTIONS_DEFINE+=	INTDATE
 INTDATE_DESC=	Builds with 64-bit date/time type
-OPTIONS_DEFAULT+=	XML TZDATA INTDATE
+OPTIONS_DEFAULT+=	TZDATA INTDATE DTRACE
 .endif
 
 .if !defined(SLAVE_ONLY)
Comment 10 oz42 2018-02-21 08:38:42 UTC
I have tried your patch, but it did not help. BTW, this patch is for databases/postgresql10-server, I hope that's okay.
Comment 11 Palle Girgensohn freebsd_committer 2018-02-21 08:43:28 UTC
postgresql10-server is the master port for all postgresql ports.

You should probably have another type of error? Does it still complain about thread safeness?
Comment 12 oz42 2018-02-21 09:08:36 UTC
Yes, it is still the complaint about thread safety. ("Use --disable-thread-safety to disable thread safety.")
Comment 13 Palle Girgensohn freebsd_committer 2018-02-21 09:50:08 UTC
How about this, where I've explicitally disabled thread safeness

Index: databases/postgresql10-server/Makefile
===================================================================
--- databases/postgresql10-server/Makefile	(revision 462308)
+++ databases/postgresql10-server/Makefile	(working copy)
@@ -40,11 +40,9 @@
 INCLUDES+=	-I${LOCALBASE}/include
 CONFIGURE_ARGS+=--with-libraries=${PREFIX}/lib \
 		--with-includes=${PREFIX}/include \
-		--enable-thread-safety
+		--disable-thread-safety
 CONFIGURE_ENV+=	INCLUDES="${INCLUDES}" \
-		PTHREAD_LIBS="-lpthread" \
 		LDFLAGS_SL="${LDFLAGS_SL}"
-LDFLAGS+=	-lpthread
 
 PLIST=		${PKGDIR}/pkg-plist${COMPONENT}
Comment 14 oz42 2018-02-21 13:01:41 UTC
Now it worked! So we have a workaround, but not a solution. :-/
It must be something in my src.conf, although all other ports are happy with this setup.
Comment 15 Palle Girgensohn freebsd_committer 2018-02-21 13:18:46 UTC
I believe that the way the test for thread safeness is done in the configure script is perhaps not the correct way for FreeBSD. I'll check it out.
Comment 16 Palle Girgensohn freebsd_committer 2018-03-14 16:06:27 UTC
*** Bug 226604 has been marked as a duplicate of this bug. ***