quetz-mod_python-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Graham Dumpleton <grah...@dscpl.com.au>
Subject Re: FreeBSD, pthreads unresoved symbols and LD_PRELOAD revisited
Date Sun, 03 Dec 2006 00:20:44 GMT

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.



View raw message