Re: 7.2 branch, configure problem, --with-python

[Michael Snyder <msnyder@vmware.com>]

Thiago Jung Bauermann wrote:
> On Mon, 2010-07-26 at 16:45 -0700, Michael Snyder wrote:
>> Hey folks, I'm having a problem attempting to build the release branch
>> on a 32 bit RHEL5 system.  I've used "--with-python=xyz" to point to a
>> local install directory, but configure tells me it wasn't found.
>>
>> The exact same configuration worked fine in version 7.1.
>>
>> This is my configure command:
>> CFLAGS=-g \
>> LDFLAGS="-Wl,-R/build/toolchain/lin32/ncurses-5.5/lib 
>> -Wl,-R/build/toolchain/lin32/expat-1.95.8/lib 
>> -Wl,-R/build/toolchain/lin32/python-2.5/lib 
>> -Wl,-R/build/toolchain/lin32/zlib-1.2.3-3/lib \
>> $(srcdir)/configure --with-python=/build/toolchain/lin32/python-2.5
>>
>> ... and this is the error message:
>>
>> checking for python2.5... no
>> configure: error: no usable python found at 
>> /build/toolchain/lin32/python-2.5
>> make[1]: *** [configure-gdb] Error 1
> 
> You're getting lots of "undefined reference to `__ctype_b'" errors when
> statically linking with libpython2.5.a. I've never seen such error
> myself, but it looks like that it is related to using old versions of
> glibc (like version 2.3 or so). E.g., see:
> 
> http://lists.debian.org/debian-glibc/2002/10/msg00340.html
> http://lists.debian.org/debian-glibc/2002/10/msg00093.html
> 
> configure is trying to compile a trivial Python application using:
> 
> gcc -o conftest -g -DVMWARE_VMKGDB
> -I/build/toolchain/lin32/python-2.5/include
> -I/build/toolchain/lin32/python-2.5/include
> -Wl,-R/build/toolchain/lin32/ncurses-5.5/lib
> -Wl,-R/build/toolchain/lin32/expat-1.95.8/lib
> -Wl,-R/build/toolchain/lin32/python-2.5/lib
> -Wl,-R/build/toolchain/lin32/zlib-1.2.3-3/lib conftest.c -lncurses -lz
> -lm    -L/build/toolchain/lin32/python-2.5/lib/python2.5/config
> -lpthread -ldl -lutil -lm -lpython2.5 >&5
> 
> Which (apart from the -Wl,-R options) look harmless to me.
> My initial impression is that there's something fishy with your
> libpython2.5.a. I don't know why GDB 7.1 and GDB 7.2 would differ here.

Thanks for your analysis.
7.1 and 7.2 differ because 7.1 links against the dynamic library,
while 7.2 links against the static python library.  I don't know
why the change.