This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author Jason.Vas.Dias
Recipients Jason.Vas.Dias, r.david.murray
Date 2011-04-28.22:48:28
SpamBayes Score 6.110971e-10
Marked as misclassified No
Message-id <1304030909.8.0.0296885125825.issue11946@psf.upfronthosting.co.za>
In-reply-to
Content
When I see messages like this in the "make test" log it makes me
want to remove python and all python using software from my system :

test_dl
test test_dl crashed -- <type 'exceptions.SystemError'>: module dl requires sizeof(int) == sizeof(long) == sizeof(char*)

NO, GEE, THAT'S RIGHT ! 

      ( sizeof( int ) == 4 ) == ( ( sizeof(long) == 8) == 
                                  (sizeof(void*) == 8 )
                                )

which actually makes sense in "C" on my system, and produces
a true value, ( 1 ) == ( ( 1 ) == ( 1 ) )
when gcc is run with the $CFLAGS given to the python build,
unlike the message's pseudo-code.

So I think some internal python components think they are getting
compiled in 32-bit mode, on a native 64-bit compiler - how ? 
Is anything in the python build appending any '-m32' flag ? 
Because my environment certainly does not contain '-m32' :

$ export -p | egrep 'CC|CXX|FLAG'
declare -x CC="/usr/bin/gcc"
declare -x CFLAGS="-march=x86-64 -mtune=k8 -O2 -g -fPIC -DPIC -pipe"
declare -x CXX="/usr/bin/g++"
declare -x CXXFLAGS="-march=x86-64 -mtune=k8 -O2 -g -fPIC -DPIC -pipe"


`uname -m` says 'x86_64' - a 64-bit arch . And the dl* objects 
are actually 64-bit:
$ find . -name 'dl*' -exec file '{}' ';'
./Modules/dlmodule.o: ELF 64-bit LSB relocatable, x86-64, version 1 (SYSV), not stripped
./build/temp.linux-x86_64-2.7/usr/src/Python-2.7.1/Modules/_ctypes/libffi/src/dlmalloc.o: ELF 64-bit LSB relocatable, x86-64, version 1 (SYSV), not stripped

So why this message :

test_dl
test test_dl crashed -- <type 'exceptions.SystemError'>: module dl requires sizeof(int) == sizeof(long) == sizeof(char*)

hmm, time to get out gdb I guess .
History
Date User Action Args
2011-04-28 22:48:29Jason.Vas.Diassetrecipients: + Jason.Vas.Dias, r.david.murray
2011-04-28 22:48:29Jason.Vas.Diassetmessageid: <1304030909.8.0.0296885125825.issue11946@psf.upfronthosting.co.za>
2011-04-28 22:48:28Jason.Vas.Diaslinkissue11946 messages
2011-04-28 22:48:28Jason.Vas.Diascreate