Nice, I managed to misspell "unresolved" in the subject of this mail
*and* the title of the Wiki article. Any way to change that without
deleting the article and recreating it with the correct title? Luckily
it's spelled right in the body so the search engines will pick it up. :-/
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.
>
> Thanks,
> e.
>
>
