Eric Brunson wrote:
I apologize if this goes out twice, I think I wrote it on my laptop at
work, then shut it down without hitting send.
While upgrading to 3.3 on Thursday I ran into the previously discussed
"pthread_*" unresolved symbol problem and used the
LD_PRELOAD=/lib/libc_r.so fix, which worked and seemed to get us most of
the way through our regression testing (such as it is).
We spent several hours tracking down why certain subprocesses were
failing when using Popen and after much trial and error, came to realize
that *any* module we compiled ourselves was failing, even the 3.1.4
version that we were originally running from ports. We started coming
to the conclusion that the threaded libc was causing problems with
subprocesses spawning subprocess ("spawn" in our expect scripts was the
culprit that pointed out the problem, then I was able to produce failing
test cases in bash and ksh scripts).
Comparing build environments between our vanilla source builds and the
ports tree, I found a patch to configure that changes PyLIBS to use the
same libraries that are linked when python is built in the ports tree.
The patch for 3.1.4 applies cleanly with a 'fuzz' warning to both the
3.2.10 source and the 3.3-svn source. The crux of the patch its to
change one line:
-PyLIBS=`grep "^LIB[SMC]=" ${PyLIBPL}/Makefile | cut -f2 -d= | tr
'\011\012\015' ' '`
+PyLIBS=`ldd $PYTHON_BIN | sed -n 's,^.* => [^ ]*/lib\(.*\)\.so[^ ]*
\((.*)\),-l\1,p' | grep -v '^-lc$' | xargs echo`
this enables any version we tried (3.1.4, 3.2.10 or 3.3) to be compiled
then run without modifying the LD_PRELOAD environment variable and also
fixed our problems with subprocess spawning.
Should we try to implement this change in the build environment? Or is
it enough to have it referenced in the documentation? I'll probably add
a wiki article on the problem.
The wiki is fine if people want to backport to 3.1.4 or 3.2.10, but it
should be fixed in the 3.3 source. Could you open a JIRA issue and
attach the patch so we don't loose track of it? I'd definitely like to
see a trouble-free build on FreeBSD.
Jim
