Обсуждение: 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.html > > Disabling 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.html > > > > Disabling 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. + 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.html >> > >> > Disabling 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.html >>> > >>> > Disabling 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