Thread safety and libxml2
We got an interesting report on the testers list today:
http://archives.postgresql.org/pgsql-testers/2009-12/msg00000.php
Basically, configure failed on their OpenBSD system because thread
safety is on but the libxml2 wasn't compiled with threaded support:
http://xmlsoft.org/threads.html
Disabling either feature (no --with-libxml or --disable-thread-safety)
gives a working build.
I wonder if it's worthwhile to document this coupling between thread
safety and libxml2 in either
http://developer.postgresql.org/pgdocs/postgres/install-procedure.html
or even the release notes. It seems quite likely to bite someone else
again the future.
--
Greg Smith 2ndQuadrant Baltimore, MD
PostgreSQL Training, Services and Support
greg@2ndQuadrant.com www.2ndQuadrant.com
On ons, 2009-12-30 at 12:55 -0500, Greg Smith wrote:
Basically, configure failed on their OpenBSD system because thread
safety is on but the libxml2 wasn't compiled with threaded support:
http://xmlsoft.org/threads.htmlDisabling either feature (no --with-libxml or --disable-thread-safety)
gives a working build.
This could perhaps be fixed by excluding libxml when running the thread
test. The thread result is only used in the client libraries and libxml
is only used in the backend, so those two shouldn't meet each other in
practice.
Peter Eisentraut wrote:
On ons, 2009-12-30 at 12:55 -0500, Greg Smith wrote:
Basically, configure failed on their OpenBSD system because thread
safety is on but the libxml2 wasn't compiled with threaded support:
http://xmlsoft.org/threads.htmlDisabling either feature (no --with-libxml or --disable-thread-safety)
gives a working build.This could perhaps be fixed by excluding libxml when running the thread
test. The thread result is only used in the client libraries and libxml
is only used in the backend, so those two shouldn't meet each other in
practice.
The attached patch removes "-lxml2" from the link line of the thread
test program. Comments? Can anyone test this fixes the OpenBSD
problem?
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
Attachments:
/pgpatches/xml2text/x-diffDownload
Index: configure
===================================================================
RCS file: /cvsroot/pgsql/configure,v
retrieving revision 1.671
diff -c -c -r1.671 configure
*** configure 17 Feb 2010 04:19:36 -0000 1.671
--- configure 19 Feb 2010 00:40:05 -0000
***************
*** 28593,28599 ****
_CFLAGS="$CFLAGS"
_LIBS="$LIBS"
CFLAGS="$CFLAGS $PTHREAD_CFLAGS -DIN_CONFIGURE"
! LIBS="$LIBS $PTHREAD_LIBS"
if test "$cross_compiling" = yes; then
{ $as_echo "$as_me:$LINENO: result: maybe" >&5
$as_echo "maybe" >&6; }
--- 28593,28601 ----
_CFLAGS="$CFLAGS"
_LIBS="$LIBS"
CFLAGS="$CFLAGS $PTHREAD_CFLAGS -DIN_CONFIGURE"
! # On OpenBSD, libxml2 is not thread-safe, but it is not used in the backend
! # 2010-02-18
! LIBS=`echo "$LIBS" | sed 's/-lxml2 //'`"$PTHREAD_LIBS"
if test "$cross_compiling" = yes; then
{ $as_echo "$as_me:$LINENO: result: maybe" >&5
$as_echo "maybe" >&6; }
Index: configure.in
===================================================================
RCS file: /cvsroot/pgsql/configure.in,v
retrieving revision 1.623
diff -c -c -r1.623 configure.in
*** configure.in 17 Feb 2010 04:19:37 -0000 1.623
--- configure.in 19 Feb 2010 00:40:10 -0000
***************
*** 1746,1752 ****
_CFLAGS="$CFLAGS"
_LIBS="$LIBS"
CFLAGS="$CFLAGS $PTHREAD_CFLAGS -DIN_CONFIGURE"
! LIBS="$LIBS $PTHREAD_LIBS"
AC_TRY_RUN([#include "$srcdir/src/test/thread/thread_test.c"],
[AC_MSG_RESULT(yes)],
[AC_MSG_RESULT(no)
--- 1746,1754 ----
_CFLAGS="$CFLAGS"
_LIBS="$LIBS"
CFLAGS="$CFLAGS $PTHREAD_CFLAGS -DIN_CONFIGURE"
! # On OpenBSD, libxml2 is not thread-safe, but it is not used in the backend
! # 2010-02-18
! LIBS=`echo "$LIBS" | sed 's/-lxml2 //'`"$PTHREAD_LIBS"
AC_TRY_RUN([#include "$srcdir/src/test/thread/thread_test.c"],
[AC_MSG_RESULT(yes)],
[AC_MSG_RESULT(no)
On Thu, Feb 18, 2010 at 8:41 PM, Bruce Momjian <bruce@momjian.us> wrote:
Peter Eisentraut wrote:
On ons, 2009-12-30 at 12:55 -0500, Greg Smith wrote:
Basically, configure failed on their OpenBSD system because thread
safety is on but the libxml2 wasn't compiled with threaded support:
http://xmlsoft.org/threads.htmlDisabling either feature (no --with-libxml or --disable-thread-safety)
gives a working build.This could perhaps be fixed by excluding libxml when running the thread
test. The thread result is only used in the client libraries and libxml
is only used in the backend, so those two shouldn't meet each other in
practice.The attached patch removes "-lxml2" from the link line of the thread
test program. Comments? Can anyone test this fixes the OpenBSD
problem?
Can someone take the time to test this whether this patch fixes the
problem? This is on the list of open items for PG 9.0, but
considering that there's been a proposed patch available for almost
two months and no responses to this thread, it may be time to conclude
that nobody cares very much - in which case we can either remove this
item or relocate it to the TODO list.
...Robert
On Mon, Apr 19, 2010 at 10:52 AM, Robert Haas <robertmhaas@gmail.com> wrote:
On Thu, Feb 18, 2010 at 8:41 PM, Bruce Momjian <bruce@momjian.us> wrote:
Peter Eisentraut wrote:
On ons, 2009-12-30 at 12:55 -0500, Greg Smith wrote:
Basically, configure failed on their OpenBSD system because thread
safety is on but the libxml2 wasn't compiled with threaded support:
http://xmlsoft.org/threads.htmlDisabling either feature (no --with-libxml or --disable-thread-safety)
gives a working build.This could perhaps be fixed by excluding libxml when running the thread
test. The thread result is only used in the client libraries and libxml
is only used in the backend, so those two shouldn't meet each other in
practice.The attached patch removes "-lxml2" from the link line of the thread
test program. Comments? Can anyone test this fixes the OpenBSD
problem?Can someone take the time to test this whether this patch fixes the
problem? This is on the list of open items for PG 9.0, but
considering that there's been a proposed patch available for almost
two months and no responses to this thread, it may be time to conclude
that nobody cares very much - in which case we can either remove this
item or relocate it to the TODO list.
Since no one has responded to this, I'm moving this to the section of
the open items list called "long-term issues: These items are not
9.0-specific. They should be fixed eventually, but not for now." I am
inclined to think this isn't worth adding to the main TODO list. If
someone complains about it again, we can ask them to test the patch.
If not, I don't see much point in investing any more time in it.
...Robert