I'm suspecting that my libpq is not thread-safe. Is this the right way to check it? Reproducible: Always Steps to Reproduce: 1. emerge =dev-db/postgresql-base-8.4.2-r1 2. cat pgtest.cpp << EOF #include <iostream> #include <libpq-fe.h> using namespace std; void main(int argc, char **argv) { if (!PQisthreadsafe()) { cout << "ERROR: PostgreSQL libpq isn't thread-safe." << endl; } else { cout << "OK: PostgreSQL libpq is thread-safe." << endl; } } 3. g++ pgtest.cpp -o pgtest -I/usr/include/postgresql-8.4 -lpq 4. ./pgtest Actual Results: ERROR: PostgreSQL libpq isn't thread-safe. Expected Results: OK: PostgreSQL libpq is thread-safe. As I checked in the ebuild, the use flag "threads" enables the --enable-thread-safety and --enable-thread-safety-force configure options, which is the correct behavior. I didn't want to report this upstream until I check here that the test I use to determine the thread-safety of libpq is adequate.
Looking at the libpq documentation, kerberos might be a potential problem. Let me remove kerberos from make.conf and update world, maybe it fixes this issue.
Nope; I've recompiled everything and libpq is still not thread-safe. Does anyone know how to make a thread-safe libpq in Gentoo? The shell script I've used for the test is: # file: pgtest.sh cat > pgtest.cpp << EOF #include <iostream> #include <libpq-fe.h> using namespace std; int main(int argc, char **argv) { if (!PQisthreadsafe()) { cout << "ERROR: PostgreSQL libpq isn't thread-safe." << endl; return 1; } else { cout << "OK: PostgreSQL libpq is thread-safe." << endl; return 0; } } EOF g++ pgtest.cpp -o pgtest -I/usr/include/postgresql -lpq ./pgtest rm pgtest.cpp pgtest
I've just tested this on my system with dev-db/postgresql-{base,server}-8.4.3 with the 'threads' USE flag set globally. I get the OK message.
Well, I still get the error message. Let me provide some more info: $ grep thread /etc/make.conf USE="${USE} gpg threads bzip2 rar md5sum sasl" $ grep postgres /etc/portage/* -r /etc/portage/package.keywords/custom-packages:dev-db/postgresql-base ~amd64 /etc/portage/package.keywords/custom-packages:dev-db/postgresql-server ~amd64 $ eix postgresql-base [D] dev-db/postgresql-base Available versions: (7.3) 7.3.21!t (7.4) 7.4.26!t 7.4.27!t (8.0) 8.0.22!t 8.0.23!t (8.1) 8.1.11!t 8.1.18!t 8.1.19!t (8.2) 8.2.14!t 8.2.15!t (8.3) 8.3.8!t 8.3.9!t (8.4) 8.4.1!t 8.4.2!t 8.4.2-r1!t {doc kerberos ldap linguas_af linguas_cs linguas_de linguas_es linguas_fa linguas_fr linguas_hr linguas_hu linguas_it linguas_ko linguas_nb linguas_pl linguas_pt_BR linguas_ro linguas_ru linguas_sk linguas_sl linguas_sv linguas_tr linguas_zh_CN linguas_zh_TW nls pam pg-intdatetime pg_legacytimestamp readline ssl threads zlib} Installed versions: 8.4.3(8.4)!t(00:39:53 03/20/10)(nls pam readline ssl threads zlib -doc -kerberos -ldap -linguas_af -linguas_cs -linguas_de -linguas_es -linguas_fa -linguas_fr -linguas_hr -linguas_hu -linguas_it -linguas_ko -linguas_nb -linguas_pl -linguas_pt_BR -linguas_ro -linguas_ru -linguas_sk -linguas_sl -linguas_sv -linguas_tr -linguas_zh_CN -linguas_zh_TW -pg_legacytimestamp) Homepage: http://www.postgresql.org/ Description: PostgreSQL libraries and clients [I] virtual/postgresql-base Available versions: (7.3) 7.3 (7.4) 7.4 (8.0) 8.0 (8.1) 8.1 (8.2) 8.2 (8.3) 8.3 (8.4) 8.4 Installed versions: 8.4(8.4)(01:52:34 01/08/10) Description: Virtual for PostgreSQL base (clients + libraries) Found 2 matches. $ eix postgresql-server [D] dev-db/postgresql-server Available versions: (7.3) 7.3.21 (7.4) 7.4.26 7.4.27 (8.0) 8.0.22 8.0.23 (8.1) 8.1.18 8.1.19 (8.2) 8.2.14 8.2.15 (8.3) 8.3.8 8.3.9 (8.4) 8.4.1!t 8.4.1-r1!t 8.4.2!t 8.4.2-r1!t {doc kernel_linux linguas_af linguas_cs linguas_de linguas_es linguas_fa linguas_fr linguas_hr linguas_hu linguas_it linguas_ko linguas_nb linguas_pl linguas_pt_BR linguas_ro linguas_ru linguas_sk linguas_sl linguas_sv linguas_tr linguas_zh_CN linguas_zh_TW nls perl pg_legacytimestamp python selinux tcl uuid xml} Installed versions: 8.4.3(8.4)!t(00:47:04 03/20/10)(kernel_linux nls perl python xml -doc -linguas_af -linguas_cs -linguas_de -linguas_es -linguas_fa -linguas_fr -linguas_hr -linguas_hu -linguas_it -linguas_ko -linguas_nb -linguas_pl -linguas_pt_BR -linguas_ro -linguas_ru -linguas_sk -linguas_sl -linguas_sv -linguas_tr -linguas_zh_CN -linguas_zh_TW -pg_legacytimestamp -selinux -tcl -uuid) Homepage: http://www.postgresql.org/ Description: PostgreSQL server [I] virtual/postgresql-server Available versions: (7.3) 7.3 (7.4) 7.4 (8.0) 8.0 (8.1) 8.1 (8.2) 8.2 (8.3) 8.3 (8.4) 8.4 Installed versions: 8.4(8.4)(16:06:10 02/18/10) Description: Virtual for PostgreSQL libraries Found 2 matches. Is there anything obvious I'm overlooking here?
What is your output of: ls -l /usr/include/postgresql
$ ls -l /usr/include/postgresql lrwxrwxrwx 1 root root 27 Jan 8 01:52 /usr/include/postgresql -> /usr/include/postgresql-8.4 $ ls -l /usr/include/postgresql-8.4/ total 136 -rw-r--r-- 1 root root 623 Mar 20 00:39 ecpg_config.h -rw-r--r-- 1 root root 2772 Mar 20 00:39 ecpg_informix.h -rw-r--r-- 1 root root 2600 Mar 20 00:39 ecpgerrno.h -rw-r--r-- 1 root root 2506 Mar 20 00:39 ecpglib.h -rw-r--r-- 1 root root 2560 Mar 20 00:39 ecpgtype.h drwxr-xr-x 3 root root 4096 Jan 8 01:52 informix drwxr-xr-x 3 root root 4096 Mar 20 00:39 internal drwxr-xr-x 2 root root 4096 Mar 20 00:39 libpq -rw-r--r-- 1 root root 2270 Mar 20 00:39 libpq-events.h -rw-r--r-- 1 root root 19646 Mar 20 00:39 libpq-fe.h -rw-r--r-- 1 root root 24803 Mar 20 00:39 pg_config.h -rw-r--r-- 1 root root 7583 Mar 20 00:39 pg_config_manual.h -rw-r--r-- 1 root root 766 Mar 20 00:39 pg_config_os.h -rw-r--r-- 1 root root 814 Mar 20 00:39 pgtypes_date.h -rw-r--r-- 1 root root 588 Mar 20 00:39 pgtypes_error.h -rw-r--r-- 1 root root 1485 Mar 20 00:39 pgtypes_interval.h -rw-r--r-- 1 root root 2306 Mar 20 00:39 pgtypes_numeric.h -rw-r--r-- 1 root root 1057 Mar 20 00:39 pgtypes_timestamp.h -rw-r--r-- 1 root root 1837 Mar 20 00:39 postgres_ext.h drwxr-xr-x 2 root root 4096 Mar 20 00:39 postmaster drwxr-xr-x 24 root root 4096 Mar 20 00:39 server -rw-r--r-- 1 root root 834 Mar 20 00:39 sql3types.h -rw-r--r-- 1 root root 1267 Mar 20 00:39 sqlca.h I get no errors when compiling the test script, except the one telling me that it is not thread-safe. Is this a good way to test for thread-safety? I made up that little script a long tim ago...
The script works for me. At least, I've built PgSQL with and without threads and got the expect results each time. Post your 'emerge --info', please.
Here it is: http://dpaste.com/176677/ (I just found out there's a dpaste vim script. Neat!) I suspect the non-thread-safe part might come from something other built into my postgresql. That's why I removed unnecessary stuff like "kerberos" from it's USE flags. Still, it's not thread-safe for me. Thanks for helping out, by the way!
Wow, I've just realized that I have two more versions of Python that are not build using emerge. I have the 2.7 (trunk) that is sometimes the default version; maybe I compiled that non-thread-safe and it might have been the default python when building postgresql-base? Let me set my python to 2.6 and rebuild postgresql. I'll get back with the results.
I've just rebuilt postgresql with python 2.6 as the default python (also built with the "threads" USE flag enabled), still getting the same results, psql is not thread-safe. Any further ideas?
Well, I wonder if it's because pthreads can't be found at build time. If you could post the portion of the "Checking for...." part, we can see if the problem is there.
Here's the output of "$ sudo emerge postgresql-base 2>&1" (compile part cut out so it could fit on dpaste): http://dpaste.com/177155/ Please take a look at line 358: it is skipping the thread-safety test. Also: $ grep threads /var/db/pkg/dev-db/postgresql-base-8.4.3/postgresql-base-8.4.3.ebuild IUSE="doc kerberos nls pam readline ssl threads zlib ldap pg_legacytimestamp ${IUSE_LINGUAS}" $(use_enable threads thread-safety) \ $(use_enable threads thread-safety-force) \ It seems like the "threads" use flag implies the --enable-thread-safety-force option, which disables the thread test program. How can I run the thread test program manually? Is this the correct behavior of the ebuild? Thanks for your help!
(In reply to comment #12) > Here's the output of "$ sudo emerge postgresql-base 2>&1" (compile part cut out > so it could fit on dpaste): http://dpaste.com/177155/ > > Please take a look at line 358: it is skipping the thread-safety test. Also: > > $ grep threads > /var/db/pkg/dev-db/postgresql-base-8.4.3/postgresql-base-8.4.3.ebuild > IUSE="doc kerberos nls pam readline ssl threads zlib ldap pg_legacytimestamp > ${IUSE_LINGUAS}" > $(use_enable threads thread-safety) \ > $(use_enable threads thread-safety-force) \ > > It seems like the "threads" use flag implies the --enable-thread-safety-force > option, which disables the thread test program. How can I run the thread test > program manually? Is this the correct behavior of the ebuild? > > Thanks for your help! > Your output is nearly identical to mine except I'm on an x86. You can edit the ebuild and remove the thread-safety-force line. Perhaps we'll get something a little more useful. (I've removed it from my ebuild here and it still comes out with an 'OK' response with your test.)
I've removed the thread safety force. Now my config checks are a little different, I have: checking thread safety of required library functions... yes which looks good. Still, I get the error, non-thread-safe response. I wonder if there's a way to dive in with gdb and see which library is not thread-safe... Do you have any idea?
(In reply to comment #14) > I've removed the thread safety force. Now my config checks are a little > different, I have: > > checking thread safety of required library functions... yes > > which looks good. Still, I get the error, non-thread-safe response. > > I wonder if there's a way to dive in with gdb and see which library is not > thread-safe... Do you have any idea? > The solution may be to use sys-apps/sandbox-2.2. (I'm currently working with some guys in #gentoo-dev-help on Freenode IRC.
I've hopped in to #gentoo-dev-help as "aatiis", feel free to ping me when you have the time to help me out a little.
Just to keep this thread updated: I've upgraded glibc, gcc and sandbox to the latest versions provided by portage (~amd64). Set the default gcc to 4.4.3, rebuilt `system' and postgresql-{base,server}, still getting the same error message. I will rebuild `world' tonight, but it'll going to take some time as I have plenty of stuff installed on this machine. I'll also try the thread-safety test provided in the postgresql tarball to see if it indicates anything suspicious. So far, I have no idea where the non-thread-safety comes from.
$ ./thread_test Your errno is thread-safe. Your system has sterror_r(); it does not need strerror(). Your system has getpwuid_r(); it does not need getpwuid(). Your system has getaddrinfo(); it does not need gethostbyname() or gethostbyname_r(). Your platform is thread-safe. Now I've also tried installing a custom postgresql to /home/someuser/postgresql, and repeated my thread-safety test with the following compile line: $ g++ pgtest.cpp -o pgtest -I/home/someuser/postgresql/include -L/home/someuser/postgresql/lib -lpq Still getting the error message. I also tried my thread safety test on a Debian system, with the same version of postgresql installed; that one seems to be thread-safe. I wonder if there is some leftover trash in my system that the linker picks up, or is this simply a bug in postgresql?
Hi, I'm trying out `pybugz -C' and `:read !emerge --info' in vim, hope this thing gets posted :) Here's my new `emerge --info': Portage 2.1.8.3 (default/linux/amd64/10.0, gcc-4.4.3, glibc-2.11-r1, 2.6.33-gentoo x86_64) ================================================================= System uname: Linux-2.6.33-gentoo-x86_64-AMD_Turion-tm-X2_Dual_Core_Mobile_RM-70-with-gentoo-2.0.1 Timestamp of tree: Fri, 02 Apr 2010 20:00:01 +0000 app-shells/bash: 4.0_p35 dev-java/java-config: 2.1.10 dev-lang/python: 2.5.4-r4, 2.6.5-r1, 3.1.2-r1 dev-util/cmake: 2.6.4-r3 sys-apps/baselayout: 2.0.1 sys-apps/openrc: 0.6.1-r1 sys-apps/sandbox: 2.2 sys-devel/autoconf: 2.13, 2.63-r1 sys-devel/automake: 1.8.5-r3, 1.9.6-r3, 1.10.3 sys-devel/binutils: 2.20.1 sys-devel/gcc: 4.3.4, 4.4.3 sys-devel/gcc-config: 1.4.1 sys-devel/libtool: 2.2.6b virtual/os-headers: 2.6.33 ACCEPT_KEYWORDS="amd64" ACCEPT_LICENSE="*" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-march=athlon64 -pipe -O2" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/share/X11/xkb /usr/share/config /var/lib/hsqldb" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/env.d/java/ /etc/eselect/postgresql /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo /etc/texmf/language.dat.d /etc/texmf/language.def.d /etc/texmf/updmap.d /etc/texmf/web2c" CXXFLAGS="-march=athlon64 -pipe -O2" DISTDIR="/usr/portage/distfiles" FEATURES="assume-digests distlocks fixpackages news parallel-fetch protect-owned sandbox sfperms strict unmerge-logs unmerge-orphans userfetch" GENTOO_MIRRORS="http://distfiles.gentoo.org" LANG="C" LDFLAGS="-Wl,-O1" MAKEOPTS="-j3" PKGDIR="/usr/portage/packages" PORTAGE_CONFIGROOT="/" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/var/lib/layman/akoya /var/lib/layman/kde" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="64bit X aac aalib acl acpi additions alsa amd64 animation-rtl ao bash-completion berkdb bluetooth bzip2 calendar cdda cddb cdr chm ciao cli consolekit cracklib crypt curl curses cxx daap dbus dga dhcp digitalradio djvu dri dv dvb dvd dvdr ebook embedded emovix encode exif extrafilters faac faad fame ffmpeg flac fontconfig fortran ftp gdbm gif gnutls gpg gpm graphviz gtk hal iceweasel iconv id3tag imagemagick ioctl jabber jbig jpeg jpeg2k kde lame laptop lastfm libnotify lua lzo mad md5sum mjpeg mmx mng modules mp3 mp3tunes mpeg mplayer msn mtp mudflap multicall multilib musicbrainz mxdatetime ncurses network nls nptl nptlonly nss nuv ogg opengl openmp oscar pam pccts pcre pdf perl pg-intdatetime pic png postgres pppd python qt3support qt4 quicktime radio rar raster readline redeyes reflection samba sasl schroedinger sdl session slang smp sndfile socks5 sox spl sse sse2 ssl startup-notification subversion svg symlink synaptics sysfs taglib tao tcpd tga theora threads thumbnail tiff truetype unicode usb v4l v4l2 vcd vim-syntax vorbis wavpack webkit wifi wmf x264 xanim xcb xml xorg xpm xvid yahoo yv12 zlib" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="alias asis auth_basic auth_digest authn_anon authn_file authz_host authz_owner authz_user log_config autoindex cache deflate dir disk_cache file_cache filter headers mem_cache mime mime_magic unique_id userdir vhost_alias version" APACHE2_MPMS="worker" ELIBC="glibc" INPUT_DEVICES="keyboard mouse evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" RUBY_TARGETS="ruby18" USERLAND="GNU" VIDEO_CARDS="fglrx radeonhd" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, FFLAGS, INSTALL_MASK, LC_ALL, LINGUAS, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
This appears to be a duplicate of bug 322597. Build postgresql with sandbox disabled.
I will try to do so and report back. You can go ahead and mark this as a dupe, I'll reopen if it isn't.
(In reply to comment #20) > This appears to be a duplicate of bug 322597. Build postgresql with sandbox > disabled. > This bug is not a duplicate. #322597 is related to the conftest failing because of Sandbox segfaulting. There's no segfault here. Though, the reporter could tell us if the issue persists.
It still persists for me. However, I suspect I'm using a wrong mechanism to test it. The result is the same if I include /usr/include/postgresql, /usr/include/postgresql-8.4 or /usr/include/postgresql-9.0. How can I make sure that the right files are included? Is there a way to "find" each file that matches postgresql but doesn't come from the ebuild? Or better yet. I'd be happy if I could just solve this issue for my PostgreSQL 9.0, as I use it in a development environment; the 9.0 beta is still good for me. I have 8.4 and 9.0 on my computer, how can I test if 9.0 is thread-safe or not? I'm using my test script from comment #2. Thanks for the support!
What's the output you get from the following command? nm /usr/lib/libpq.a | grep pthread_mutex_lock
$ nm /usr/lib/libpq.a | grep pthread_mutex_lock U pthread_mutex_lock U pthread_mutex_lock
Created attachment 239733 [details] Thread Safety Test Program I've written a new test program in C rather than C++. Try running this instead and see if the output is any different. (Shot in the dark, I know.)
$ gcc pg-thread-test.c -o pg-thread-test -I/usr/include/ -lpq $ ./pg-thread-test It isn't safe! I'm trying to think there's something wrong with my system here. How can I trace back which files are being included? Also, how can I try this same thing with PostgreSQL 9? Maybe that one works - then I don't care about 8.4 anymore.
There are two ways: eselect postgresql set 9.0 Or: gcc pg-thread-test.c -o pg-thread-test -I/usr/include/postgresql-9.0/ -lpq
$ sudo eselect postgresql set-all 9.0 $ gcc pg-thread-test.c -o pg-thread-test -I/usr/include/postgresql-9.0/ -lpq $ ./pg-thread-test It isn't safe! Seems like 9.0 is not thread-safe either. I wonder what the hell is happening here...
Well, I'm out of ideas. Everything else indicates that your system and PostgreSQL is thread safe except this one function. Take your issue to upstream (pgsql-bugs at postgresql.org) as they know their program much better than I do.
Hi This is not answering the first poster case but if it can help anybody : I had this symptom of "not thread safe" but it was stumbling on my recurring "bool" problem. I switch back to gcc-4.3 (from 4.4) and now it flows. That's on PPC. Hth
Upgrade to sandbox-2.2 (~x86) rather than 1-6. Problem solved, at least for me, on two separate installations of Gentoo.
(In reply to comment #31) > Hi > This is not answering the first poster case but if it can help anybody : > I had this symptom of "not thread safe" but it was stumbling on my recurring > "bool" problem. I switch back to gcc-4.3 (from 4.4) and now it flows. > That's on PPC. > Hth > To you, if your issue is not exactly as described, you should open a new bug. Attila Olah, have we tried different GCC versions? (In reply to comment #32) > Upgrade to sandbox-2.2 (~x86) rather than 1-6. > Problem solved, at least for me, on two separate installations of Gentoo. Please read the bug report before jumping to that conclusion, or at least search for some keywords. The reporter already has Sandbox 2.2 installed. Additionally, this is not a configure time error. The package builds and says that everything is good. It's only after the emerge has completed that there is the issue of not being thread safe. To everyone else, I need someone to confirm this issue to determine if the reporter is singular in his issue. Once more, it is not a configure time error, but the test program attached to this bug that returns not safe.
(In reply to comment #33) > Attila Olah, have we tried different GCC versions? I have tried 4.3.5 and 4.4.4-r1 so far. $ gcc-config -c x86_64-pc-linux-gnu-4.4.4 $ eix sys-devel/gcc [D] sys-devel/gcc Available versions: (2.95) *2.95.3-r9 ~*2.95.3-r10!s (3.1) *3.1.1-r2 (3.2) **3.2.2!s *3.2.3-r4 (3.3) (~)3.3.6-r1!s (3.4) 3.4.6-r2!s (4.0) ~*4.0.4!s (4.1) 4.1.2!s (4.2) (~)4.2.4-r1!s (4.3) 4.3.2-r3!s (~)4.3.2-r4!s (~)4.3.3-r2!s 4.3.4!s (4.4) (~)4.4.1!s (~)4.4.2!s {altivec bootstrap boundschecking build d doc fixed-point fortran gcj graphite gtk hardened ip28 ip32r10k java libffi mudflap multilib multislot n32 n64 nls nocxx nopie nossp nptl objc objc++ objc-gc openmp static test vanilla} Installed versions: 4.3.5(4.3)!s(06:39:05 06/19/10)(fortran gtk mudflap multilib nls nptl openmp -altivec -bootstrap -build -doc -fixed-point -gcj -hardened -libffi -multislot -n32 -n64 -nocxx -nopie -nossp -objc -objc++ -objc-gc -test -vanilla) 4.4.4-r1(4.4)!s(07:34:20 06/19/10)(fortran gtk mudflap multilib nls nptl openmp -altivec -bootstrap -build -doc -fixed-point -gcj -graphite -hardened -libffi -multislot -n32 -n64 -nocxx -nopie -nossp -objc -objc++ -objc-gc -test -vanilla) Homepage: http://gcc.gnu.org/ Description: The GNU Compiler Collection. Includes C/C++, java compilers, pie+ssp extensions, Haj Ten Brugge runtime bounds checking ... I have upgraded to 4.4 because of this issue, rebuilt my whole "world", and still I get the not-thread-safe message. Does the above configuration look ok? Should I migrate this bug to postgres? Note: same issue applies to PostgreSQL 9.0 beta.
Yes, take the bug upstream. They may have an answer for you. Either way, respond back here so we can track your progress with them.
It appears to me that some of the newer ebuilds have --disable-thread-safety hard-coded. Why can this no longer be controlled by a USE flag?
(In reply to comment #36) > It appears to me that some of the newer ebuilds have --disable-thread-safety > hard-coded. Why can this no longer be controlled by a USE flag? > It isn't hard coded in the -base ebuilds.
(In reply to comment #37) > It isn't hard coded in the -base ebuilds. Ahm, I see. My mistake.
Did you have any luck with upstream? Does this issue still persisting?
Thanks for reminding. I haven't had the time to bring this upstream, but I have found a workaround: if I include & link against PostgreSQL 9, my app will be thread-safe. 8.4 is still not thread-safe, but I can upgrade to 9.0. Since it is working for others, it might just be some bug in my system. Should I mark this as INVALID?
I'll have it marked as WORKSFORME as this bug really isn't INVALID, you're just the only one experiencing it.
Reopen if anyone else can reproduce this bug.
