On 03/12/2006, at 7:34 AM, Jim Gallacher wrote:
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.
The 'ldd' program doesn't exist everywhere and so that change can't
be used.
Can you explain properly what that one line is achieving.
If you are trying to force the linking in of additional libraries,
eg, -lc_r, what happens
when you set LIBS when running configure. Eg.
LIBS=-lc_r ./configure ...
Even if this doesn't work but it is what you are hoping to achieve,
it would be better
to still require it to be a manual override rather than automatic.
That could mean
making LIBS be used, or have a special configure option to enable
linking in of
other libraries.
Anyway, please explain what the change is doing.
Thanks.
Graham
