quetz-mod_python-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jim Gallacher <...@jgassociates.ca>
Subject Re: FreeBSD, pthreads unresoved symbols and LD_PRELOAD revisited
Date Sat, 02 Dec 2006 20:34:12 GMT
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.


View raw message