After building from source in Python-2.7.1.tar.bz2 ,
I get this 'make test' failure :

test_commands
test test_commands failed -- Traceback (most recent call last): 
  File "/usr/src/Python-2.7/Lib/test/test_commands.py", line 61, in test_getstatus
    self.assertTrue(re.match(pat, commands.getstatus("/."),re.VERBOSE)) 
AssertionError: None is not True

I don't get this error when building from Python-2.7.tar.bz2

Oops, bash <TAB> completion was a bit over-eager, and I inadvertently
built /usr/src/Python-2.7 instead  of /usr/src/Python-2.7.1 .

Nevertheless, when I finally do build Python-2.7.1, I get the same 
error :

test_commands                                                                                                                                               
test test_commands failed -- Traceback (most recent call last):                                                                                             
  File "/usr/src/Python-2.7.1/Lib/test/test_commands.py", line 61, in test_getstatus                                                                        
    self.assertTrue(re.match(pat, commands.getstatus("/."), re.VERBOSE))                                                                                    
AssertionError: None is not True                                                                                                                            


I guess if python-2.7 cannot run command I'd know about it, and
it has the same bug.

I guess you ship a broken 'test_commands' test script for Python-2.7
AND Python-2.7.1 .

This does not increase my already meager confidence in Python's 
robustness and reliability.

We don't ship unless all tests pass on all of our test platforms (and we have quite a few).  If you look at that test it says the regex "should match 'ls -ld /.' on any posix system, however perversely configured".  Perhaps your system has managed a new brand of perversity :)

Seriously, though, it looks like the test is broken in the face of some edge case present on your system and not on any of our test machines.  Can you provide the output of 'ls -ld /.' from your system please?  And also your OS and filesystem types and versions.

$ uname -a
Linux jvdspc 2.6.38.2-jvd #1 SMP Sun Apr 3 00:55:29 BST 2011 x86_64 GNU/Linux
$ ls -ld /
drwxr-xr-x. 25 root root 4096 Apr 20 15:28 /
$ ls --version
ls (GNU coreutils) 8.10
...
$ eval {gcc,g++,cpp,ld,as,ar,ranlib,objdump,objcopy,make,bash,ldconfig}' --version;' | egrep '[(]G|bash'
gcc (GCC) 4.6.0
g++ (GCC) 4.6.0
cpp (GCC) 4.6.0
GNU ld (GNU Binutils) 2.21.51.20110407
GNU assembler (GNU Binutils) 2.21.51.20110407
GNU ar (GNU Binutils) 2.21.51.20110407
GNU ranlib (GNU Binutils) 2.21.51.20110407
GNU objdump (GNU Binutils) 2.21.51.20110407
GNU objcopy (GNU Binutils) 2.21.51.20110407
GNU bash, version 4.2.8(2)-release (x86_64-pc-linux-gnu)
ldconfig (GNU libc) 2.13

$ ldd /usr/bin/python
        linux-vdso.so.1 =>  (0x00007fff1edff000)
        libpython2.7.so.1.0 => /usr/lib64/libpython2.7.so.1.0 (0x00007f16aa8c0000)
        libpthread.so.0 => /usr/lib64/libpthread.so.0 (0x00007f16aa6a3000)
        libdl.so.2 => /usr/lib64/libdl.so.2 (0x00007f16aa49f000)
        libutil.so.1 => /lib64/libutil.so.1 (0x00007f16aa29c000)
        libm.so.6 => /lib64/libm.so.6 (0x00007f16aa01a000)
        libc.so.6 => /lib64/libc.so.6 (0x00007f16a9c92000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f16aac90000)

$ ls -ld /.
drwxr-xr-x. 25 root root 4096 Apr 20 15:28 /.

(oops, forgot the '.' suffix before)

The re matches for me if I call it manually with your ls -ld output.

What output do you get if you do a 'print commands.getstatus("/.")' using your build of the python interpreter?

By the way, this is a deprecated function under test here, so I'm setting this bug to low priority.  But I'm certainly curious as to what the problem is.

Seeing the source , I see some complicated RE - should this test
maybe be better off in the RE testing module ?

I'd have used a simple RE like '^.*(\/.*)$' .

Might my newly built & installed pcre-8.02 be a suspect here ?

Here is an strace of the installed python  2.7 (not 2.7.1!)
failing with test_commands.py :

$ strace -s8192 -f -e trace=execve python /usr/src/Python-2.7.1/Lib/test/test_commands.py
execve("/usr/bin/python", ["python", "/usr/src/Python-2.7.1/Lib/test/test_commands.py"], [/* 23 vars */]) = 0
test_getoutput (__main__.CommandTests) ... syscall_293(0x7fffa0d6a400, 0x80000, 0x7f4029a834dd, 0x7fffa0d6a200, 0x7f4029abf700, 0x100, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0) = 0                                                                                                                    
Process 30803 attached                                                                                                                                                
[pid 30803] execve("/bin/sh", ["sh", "-c", "{ echo xyzzy; } 2>&1"], [/* 23 vars */]) = 0                                                                              
Process 30803 detached                                                                                                                                                
--- SIGCHLD (Child exited) @ 0 (0) ---                                                                                                                                
syscall_293(0x7fffa0d6a550, 0x80000, 0x7f4029a834dd, 0, 0x7f4029abf700, 0x100, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0) = 0      
Process 30804 attached                                                                                                                                                
[pid 30804] execve("/bin/sh", ["sh", "-c", "{ echo xyzzy; } 2>&1"], [/* 23 vars */]) = 0                                                                              
Process 30804 detached                                                                                                                                                
--- SIGCHLD (Child exited) @ 0 (0) ---                                                                                                                                
syscall_293(0x7fffa0d6a550, 0x80000, 0x7f4029a834dd, 0, 0x7f4029abf700, 0x100, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0) = 0      
Process 30805 attached                                                                                                                                                
[pid 30805] execve("/bin/sh", ["sh", "-c", "{ cat /tmp/tmpZ2sqbO/foo; } 2>&1"], [/* 23 vars */]) = 0                                                                  
Process 30806 attached                                                                                                                                                
[pid 30806] execve("/bin/cat", ["cat", "/tmp/tmpZ2sqbO/foo"], [/* 21 vars */]) = 0                                                                                    
Process 30805 suspended                                                                                                                                               
Process 30805 resumed                                                                                                                                                 
Process 30806 detached
[pid 30805] --- SIGCHLD (Child exited) @ 0 (0) ---
Process 30805 detached
--- SIGCHLD (Child exited) @ 0 (0) ---
ok
test_getstatus (__main__.CommandTests) ... syscall_293(0x7fffa0d6a2b0, 0x80000, 0x7f4029a834dd, 0, 0x7f4029abf700, 0x100, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0) = 0
Process 30807 attached
[pid 30807] execve("/bin/sh", ["sh", "-c", "{ ls -ld \'/.\'; } 2>&1"], [/* 23 vars */]) = 0
Process 30808 attached
Process 30807 suspended
[pid 30808] execve("/bin/ls", ["ls", "-ld", "/."], [/* 21 vars */]) = 0
Process 30807 resumed
Process 30808 detached
[pid 30807] --- SIGCHLD (Child exited) @ 0 (0) ---
Process 30807 detached
--- SIGCHLD (Child exited) @ 0 (0) ---
FAIL

======================================================================
FAIL: test_getstatus (__main__.CommandTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/src/Python-2.7.1/Lib/test/test_commands.py", line 61, in test_getstatus
    self.assertTrue(re.match(pat, commands.getstatus("/."), re.VERBOSE))
AssertionError: None is not True

----------------------------------------------------------------------
Ran 2 tests in 0.202s

FAILED (failures=1)
Traceback (most recent call last):
  File "/usr/src/Python-2.7.1/Lib/test/test_commands.py", line 70, in <module>
    test_main()
  File "/usr/src/Python-2.7.1/Lib/test/test_commands.py", line 65, in test_main
    run_unittest(CommandTests)
  File "/usr/lib/python2.7/test/test_support.py", line 1055, in run_unittest
    _run_suite(suite)
  File "/usr/lib/python2.7/test/test_support.py", line 1038, in _run_suite
    raise TestFailed(err)
test.test_support.TestFailed: Traceback (most recent call last):
  File "/usr/src/Python-2.7.1/Lib/test/test_commands.py", line 61, in test_getstatus
    self.assertTrue(re.match(pat, commands.getstatus("/."), re.VERBOSE))
AssertionError: None is not True

Hmm.. investigating that "syscall_293..." stuff - I did 
  $ cd /usr/src/linux; make headers_install
and then built glibc-2.13 with the new header OK, but
strace is rather old . I'll rebuild strace ...

$ python
Python 2.7 (r27:82500, Jul  4 2010, 23:30:10)
[GCC 4.4.2 20090927 (prerelease)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import os
>>> import re
>>> import sys
>>> import commands
>>> print commands.getstatus("/.")
drwxr-xr-x. 25 root root 4096 Apr 20 15:28 /.
>>>

new strace 4.6 of newly built python 2.7.1 failing test_commands.py

$ LD_LIBRARY_PATH=`pwd` LD_PRELINK=`pwd`/libpython2.7.so.1.0 strace -s8192 -f -e trace=execve ./python /usr/src/Python-2.7.1/Lib/test/test_commands.py
execve("./python", ["./python", "/usr/src/Python-2.7.1/Lib/test/test_commands.py"], [/* 25 vars */]) = 0                                              
test_getoutput (__main__.CommandTests) ... Process 1327 attached                                                                                      
[pid  1327] execve("/bin/sh", ["sh", "-c", "{ echo xyzzy; } 2>&1"], [/* 25 vars */]) = 0                                                              
Process 1327 detached                                                                                                                                 
--- {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=1327, si_status=0, si_utime=0, si_stime=1} (Child exited) ---                                       
Process 1328 attached                                                                                                                                 
[pid  1328] execve("/bin/sh", ["sh", "-c", "{ echo xyzzy; } 2>&1"], [/* 25 vars */]) = 0                                                              
Process 1328 detached                                                                                                                                 
--- {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=1328, si_status=0, si_utime=0, si_stime=1} (Child exited) ---                                       
Process 1329 attached                                                                                                                                 
[pid  1329] execve("/bin/sh", ["sh", "-c", "{ cat /tmp/tmp2EkRJK/foo; } 2>&1"], [/* 25 vars */]) = 0                                                  
Process 1330 attached                                                                                                                                 
Process 1329 suspended                                                                                                                                
[pid  1330] execve("/bin/cat", ["cat", "/tmp/tmp2EkRJK/foo"], [/* 23 vars */]) = 0
Process 1329 resumed
Process 1330 detached
[pid  1329] --- {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=1330, si_status=1, si_utime=0, si_stime=0} (Child exited) ---
Process 1329 detached
--- {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=1329, si_status=1, si_utime=0, si_stime=1} (Child exited) ---
ok
test_getstatus (__main__.CommandTests) ... Process 1338 attached
[pid  1338] execve("/bin/sh", ["sh", "-c", "{ ls -ld '/.'; } 2>&1"], [/* 25 vars */]) = 0
Process 1339 attached
Process 1338 suspended
[pid  1339] execve("/bin/ls", ["ls", "-ld", "/."], [/* 23 vars */]) = 0
Process 1338 resumed
Process 1339 detached
[pid  1338] --- {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=1339, si_status=0, si_utime=0, si_stime=0} (Child exited) ---
Process 1338 detached
--- {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=1338, si_status=0, si_utime=0, si_stime=1} (Child exited) ---
FAIL

======================================================================
FAIL: test_getstatus (__main__.CommandTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/src/Python-2.7.1/Lib/test/test_commands.py", line 61, in test_getstatus
    self.assertTrue(re.match(pat, commands.getstatus("/."), re.VERBOSE))
AssertionError: None is not True

----------------------------------------------------------------------
Ran 2 tests in 0.289s

FAILED (failures=1)
Traceback (most recent call last):
  File "/usr/src/Python-2.7.1/Lib/test/test_commands.py", line 70, in <module>
    test_main()
  File "/usr/src/Python-2.7.1/Lib/test/test_commands.py", line 65, in test_main
    run_unittest(CommandTests)
  File "/usr/src/Python-2.7.1/Lib/test/test_support.py", line 1087, in run_unittest
    _run_suite(suite)
  File "/usr/src/Python-2.7.1/Lib/test/test_support.py", line 1070, in _run_suite
    raise TestFailed(err)
test.test_support.TestFailed: Traceback (most recent call last):
  File "/usr/src/Python-2.7.1/Lib/test/test_commands.py", line 61, in test_getstatus
    self.assertTrue(re.match(pat, commands.getstatus("/."), re.VERBOSE))
AssertionError: None is not True

So, now with strace-4.6, that syscall_293* is shown to be an old strace anomaly.

Newly built python 2.7.1 commands.getstatus succeeds :

$ LD_LIBRARY_PATH=`pwd` LD_PRELINK=`pwd`/libpython2.7.so.1.0 ./python
Python 2.7.1 (r271:86832, Apr 28 2011, 15:53:47)
[GCC 4.6.0] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import os
>>> import re
>>> import sys
>>> import commands
>>> print commands.getstatus("/.")
drwxr-xr-x. 25 root root 4096 Apr 20 15:28 /.
>>>

Hmm.  This is very odd.  The output from getstatus is the same as your ls output, and that output passes the re.  Python has its own regular expression implementation, so your pcre version shouldn't have anything to do with it.

That complicated re, by the way, is trying to confirm that what comes back from getstatus is something that looks like the output of ls, so no, it can't really be simplified and still be testing getstatus.

It looks like something weird is going on inside the test machinery.  Are you willing to do a little Python hacking?  If I were seeing this error on my box I'd split up that assert statement.  Get the value of the getstatus call, print it out.  Then pass the output to the re, and print the result (which should be None, given that the test is failing).  If the getstatus output looks right at that point, then something very odd indeed is going on.

You are running selinux, right?  Have you checked for things in the log that might indicate selinux is blocking the ls call for some reason?

Aha ! Fixed ! : patch :

[ root@jvdspc:/mnt/sda3/Python-2.7 18:02:22 1685:1178 ]
$ LD_LIBRARY_PATH=`pwd` LD_PRELINK=`pwd`/libpython2.7.so.1.0 ./python /tmp/test_commands.py
test_getoutput (__main__.CommandTests) ... ok
test_getstatus (__main__.CommandTests) ... ok

----------------------------------------------------------------------
Ran 2 tests in 0.068s

OK
[ root@jvdspc:/mnt/sda3/Python-2.7 18:03:34 1686:1179 ]
$ diff -U0 /usr/src/Python-2.7/Lib/test/test_commands.py /tmp/test_commands.py
--- /usr/src/Python-2.7/Lib/test/test_commands.py       2010-03-31 23:01:03.000000000 +0100
+++ /tmp/test_commands.py       2011-04-28 18:03:27.821395320 +0100
@@ -27,2 +27,2 @@
-        self.assertEquals(commands.getoutput('echo xyzzy'), 'xyzzy')
-        self.assertEquals(commands.getstatusoutput('echo xyzzy'), (0, 'xyzzy'))
+        self.assertEqual(commands.getoutput('echo xyzzy'), 'xyzzy')
+        self.assertEqual(commands.getstatusoutput('echo xyzzy'), (0, 'xyzzy'))
@@ -39 +39 @@
-            self.assertNotEquals(status, 0)
+            self.assertNotEqual(status, 0)
@@ -52,5 +52 @@
-        pat = r'''d.........   # It is a directory.
-                  \+?          # It may have ACLs.
-                  \s+\d+       # It has some number of links.
-                  [^/]*        # Skip user, group, size, and date.
-                  /\.          # and end with the name of the file.
+        pat = r'''^.*(\/\.)[\ ]*[\n\r]*$

oops, over-eager bash <tab> again - 
I've certainly had one too many bash <tab>s today :-)
Here's the patch against 2.7.1's test_commands.py, not 2.7's :


[ root@jvdspc:/mnt/sda3/Python-2.7 18:04:15 1687:1180 ]
$ diff -U0 /usr/src/Python-2.7.1/Lib/test/test_commands.py /tmp/test_commands.py
--- /usr/src/Python-2.7.1/Lib/test/test_commands.py     2010-11-21 13:34:58.000000000 +0000
+++ /tmp/test_commands.py       2011-04-28 18:03:27.821395320 +0100
@@ -52,5 +52 @@
-        pat = r'''d.........   # It is a directory.
-                  \+?          # It may have ACLs.
-                  \s+\d+       # It has some number of links.
-                  [^/]*        # Skip user, group, size, and date.
-                  /\.          # and end with the name of the file.
+        pat = r'''^.*(\/\.)[\ ]*[\n\r]*$
[ root@jvdspc:/mnt/sda3/Python-2.7 18:05:52 1688:1181 ]

Not sure if relevant, but ls is appending a ' ' (0x20 == space) after
the filename :

$ ls -ld -d /. | od -x
0000000 7264 7877 2d72 7278 782d 202e 3532 7220
0000020 6f6f 2074 6f72 746f 3420 3930 2036 7041
0000040 2072 3032 3120 3a35 3832 2f20 0a2e
0000056

See the ending "200a2e" - maybe there should not be an 0x20 there .
Should I raise a GNU coreutils 8.10 bug about this ?

Wow, GNU have respun two major releases of coreutils since I built
coreutils-2.10 two weeks ago !

Now moving to latest version of coreutils : 8.12 and retesting .

$ ls -dl /. | od -x
0000000 7264 7877 2d72 7278 782d 202e 3532 7220
0000020 6f6f 2074 6f72 746f 3420 3930 2036 7041
0000040 2072 3032 3120 3a35 3832 2f20 0a2e
0000056
[ root@jvdspc:/tmp 19:15:01 1730:1223 ]
$ ls --version
ls (GNU coreutils) 8.12


Either GNU coreutils 8.12 's ls is wrong to append a ' ', or 
test_commands.py is wrong not to be expecting it.

I would say that coreutils is wrong to be appending a space.  If a program were to parse the output of ls, it would reasonably expect the filename to be rendered exactly as it appears in the directory.  That is, a program should treat a trailing space as *part* of the filename, which it clearly isn't in this case.

By the way, I wouldn't expect most programs to ever notice that trailing space parsing -l output, but if it also attaches the trailing space in regular ls output, *that* I would expect more programs would trip over.

Oops, Paul is right here - I asked bug-coreutils@gnu.org, and Paul
responds:
<quote>
Re: bug#8578: 8.12 and 8.10 'ls -dl' appends ' ' (0x20: space) to file  output lines
From:  Paul Eggert <eggert@cs.ucla.edu>  (UCLA Computer Science Department)
  To: jason.vas.dias@gmail.com
  CC: 8578@debbugs.gnu.org
Date: 2011-04-28 20:34
   
On 04/28/11 11:34, Jason Vas Dias wrote:

> $ ls -dl /. | od -cx
> ...
> 0000040   r       2   0       1   5   :   2   8       /   .  \n
>            2072    3032    3120    3a35    3832    2f20    0a2e
> 0000056
> 
> Please could the ls developer let me know if it 100% POSIXLY correct
> that ls appends 0x20 to the filename '/.'  here ?

I don't see any space appended there.  The last four bytes of
output are 0x20, 0x2f, 0x2e, 0x0a (space, /, ., newline).
Perhaps you're misunderstanding the little-endian nature of
od -x output?
</quote>

Yes, of course, when 'od' says ' 2f20    0a2e' it means it received:
  0x20 0x2f 0x2e 0x0a
sorry - I'm just trying to understand why your original RE fails -
it isn't because of the spaces !

I imagine lots of other python REs fail if this one is failing ? :

$ cat test.py

import os
import sys
import re

pat = r'''d.........   # It is a directory.
          \+?          # It may have ACLs.
          \s+\d+       # It has some number of links.
          [^/]*        # Skip user, group, size, and date.
          /\.          # and end with the name of the file.
       '''
str = 'drwxr-xr-x. 25 root root 4096 Apr 20 15:28 /.'
if re.match(pat, str, re.VERBOSE) :
   print "MATCHED\n"
else :
   print "DID NOT MATCH"

$ LD_LIBRARY_PATH=`pwd` LD_PRELINK=`pwd`/libpython2.7.so.1.0 ./python ./test.py
DID NOT MATCH

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 .

Oh, drat.  We could have figured this out much sooner if I'd been paying closer attention.  I was testing based on current 2.7 tip instead of 2.7.1, and indeed this test bug was only recently (April 4th!) fixed.  And the issue is indeed selinux; the fix was to the regex to take into account the selinux extra attributes.  My apologies for dragging you through unnecessary debugging :(

As for the other issue, please open a new ticket.  (The pseudo-code, by the way, is saying that all three sizes must be the same.)

RE: msg134737 :
 > indeed this test bug was only recently (April 4th!) fixed.  
Please can you let me know how to get the patch / source / that fixes this ? The bug # of the original bug ? Should I be building from GIT ? Which GIT tag ? I'll try that next ...
 
> And the issue is indeed selinux; the fix was to the regex to take 
> into account the selinux extra attributes.  

selinux is disabled on my system, there were no SELinux attributes
in the string emitted by 'ls -dl' - and the python executable does
not link to libselinux - so you're saying that, in this code :
        pat = r'''d.........   # It is a directory.
                  \+?          # It may have ACLs.
'\+?' is incorrectly requiring '+' ?
Surely this is a bug in the regexp code ?

Nope, I don't think it has anything to do with SELinux attributes -
when I remove the '\+?', the RE still fails :


$ cat test.py

import os
import sys
import re

pat = r'''d.........   # It is a directory.
          \s+\d+       # It has some number of links.
          [^/]*        # Skip user, group, size, and date.
          /\.          # and end with the name of the file.
       '''
str = 'drwxr-xr-x. 25 root root 4096 Apr 20 15:28 /.'
if re.match(pat, str, re.VERBOSE) :
   print "MATCHED\n"
else :
   print "DID NOT MATCH"

$ LD_LIBRARY_PATH=`pwd` LD_PRELINK=`pwd`/libpython2.7.so.1.0 ./python ./test.py
DID NOT MATCH

RE:
>  As for the other issue, please open a new ticket.  (The pseudo-code, 
>  by the way, is saying that all three sizes must be the same.)

This really frightens me - do you really believe that 
   "all three sizes must be the same" on an x86_64 ? :
test_dl
test test_dl crashed -- <type 'exceptions.SystemError'>: module dl requires sizeof(int) == sizeof(long) == sizeof(char*)

That your dynamic linking module should give the impression in its
test script that it thinks 'sizeof(int)' (==4) should be equal to
'sizeof(char*)' (==8) is rather disconcerting to say the least -
and terrifying if it actually acts on this fundamental misconception
in its code - the fact that it crashed suggests maybe this is the
case. I'll see what happens with this test for the new code build
and raise another issue if not fixed.

Aha ! Yes, I see, it is the extra '.' - this test now works :


$ cat test.py

import os
import sys
import re

pat = r'''d.........   # It is a directory.
          [+.@]?
          \s+\d+       # It has some number of links.
          [^/]*        # Skip user, group, size, and date.
          /\.          # and end with the name of the file.
       '''
str = 'drwxr-xr-x. 25 root root 4096 Apr 20 15:28 /.'
if re.match(pat, str, re.VERBOSE) :
   print "MATCHED\n"
else :
   print "DID NOT MATCH"

[ root@jvdspc:/mnt/sda3/Python-2.7 11:19:30 1758:1251 ]
$ LD_LIBRARY_PATH=`pwd` LD_PRELINK=`pwd`/libpython2.7.so.1.0 ./python ./test.py
MATCHED


I still think that RE belongs in a 'test_re' script, not in the
'test_commands' script - this whole series of issues could have
been avoided if the programmer had refrained from "showing off"
their RE prowess for no purpose here and just used a simple RE
like '^.*/\.$' .

In case you don't believe me, believe a "C" compiler :

$ echo -e '#include <stdio.h>\nint main(){ printf("%u %u\\n",sizeof(int),sizeof(void*));}' > si.c
$ gcc -o si si.c
$ ./si
4 8

Any code that assumes that "sizeof(int) == sizeof(char*)" on
an x86_64 is broken, and any test that emits messages to this
effect is profoundly disconcerting . I wish I didn't have to
support python on my system.

Furthermore, look at your configure script output :

checking for int32_t... yes                                                                                                                                           
checking for int64_t... yes                                                                                                                                           
checking for ssize_t... yes                                                                                                                                           
checking size of int... 4                                                                                                                                             
checking size of long... 8                                                                                                                                            
checking size of void *... 8                                                                                                                                          
checking size of short... 2                                                                                                                                           
checking size of float... 4                                                                                                                                           
checking size of double... 8                                                                                                                                          
checking size of fpos_t... 16                                                                                                                                         
checking size of size_t... 8                                                                                                                                          
checking size of pid_t... 4                                                                                                                                           
checking for long long support... yes                                                                                                                                 
checking size of long long... 8       



So why does your test_dl script say "sizeof(int)==sizeof(char*)" ??

OK, the test failures reported for this bug now succeed with Python-3.3
from latest HG head . 
But Python-3.3 now has its own new test failures :



[149/354] test_import                                                                                                                                                 
test test_import failed -- Traceback (most recent call last):                                                                                                         
  File "/usr/src/cpython/Lib/test/test_import.py", line 545, in test_unwritable_directory                                                                             
    '__pycache__', '{}.{}.pyc'.format(TESTFN, self.tag))))                                                                                                            
AssertionError: True is not false                                                                                                                                     

Hmm, don't want a python that can't do 'import' .

So my choices are, in order to get a working modern python release  :

  o fix the broken dynamic loader in Python-2.7
  o fix the broken import mechanism in Python-3.3

Thanks !  



BTW, this error occurs because I don't have RPM :
[ 93/354] test_distutils
error: error creating temporary file ${prefix}/var/tmp/rpm-tmp.amzIxR: No such file or directory
error: Unable to open temp file.
error: error creating temporary file ${prefix}/var/tmp/rpm-tmp.nwKS2z: No such file or directory
error: Unable to open temp file.
test test_distutils failed -- multiple errors occurred; run in verbose mode for details

this is because I don't have RPM (or maybe an old broken RPM inst) -
I suggest this test should test for the existence and usability
of rpm before using rpm - and should skip itself if rpm not usable.

No, if you take a look at tip, the problem is that bit of re is not covering all cases, and should look like this:

  [.+@]?       # It may have special attributes.

I assumed the "." was selinux, but I don't actually know, as I don't see them on my system (I don't use selinux or, apparently, any other special attributes).

So, the reason the re is failing is the trailing '.' in the first token in your ls -ld result, whatever that comes from.  The fixed test re allows for the '.'.

Sorry, didn't see that you'd figured it out in the midst of your other comments not relevant to this bug.

If the re were simpler it wouldn't actually be *testing* the function under test, and so would be a useless test.  (It would show that the function produced output, but not that the output was from the ls -ld command)

Jason, that the dl module requires sizeof(int) == sizeof(char *) does not mean that it (or we) thinks this to be true on every platform.  Rather, the module is written in a way that requires this equality, and rather than crashing it does this check beforehand.

As you may have noticed, the dl module is deprecated anyway in favor of ctypes, and removed in Python 3.x.

RE: msg134751 - Thanks for responding, George -

This bug is still an issue for me, as even though I now have Python-3.3
having passed its test suite, installed and running OK, and even
went so far as to 'cd /usr/bin; rm -f python; ln -s python3.3 python;'
(/usr/bin/python2.7 executable still exists) all the software
I now attempt to build insists on using python2 , which is built
against an old glibc and has started giving anomalous results
after upgrade to newer glibc - see : 
https://bugzilla.gnome.org/show_bug.cgi?id=648863
where I found that my python-2.7 was failing to 
 'from . import config'
whereas the FC-14 python 2.7 got past this .

So I still need to find a way of building python 2.7.1 to replace
my broken old system python2 .

When I tried this, doing :
$ /usr/src/Python-2.7.1/configure --prefix=/usr --libdir=/usr/lib64 --enable-shared CXX=${CXX} CXXFLAGS="$CXXFLAGS"

(I only added the CXX= args because configure complained that while
 I did have $CXX set to /usr/bin/g++ , "c++" would be used )

the build failed complaining that the 'bsddb185 dl gdbm' modules
could not be built; I had to change the $CPPFLAGS to contain
'-I/usr/include/db4' and --libs to contain '-ldb-4.5 -lgdbm' and
comment out and modify the lines in Module/Setup :

  #dl dlmodule.c
...
  #gdbm gdbmmodule.c -I/usr/local/include -L/usr/local/lib -lgdbm
...
  #_bsddb _bsddb.c -I$(DBINC) -L$(DBLIB) -ldb-$(DBLIBVER)

and then the build succeeded , but with these errors from dlmodule :

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

My point is, if this test_dl works only in 32-bit mode, it should
have failed during its build, not during test !
If it is meant to be 32-bit only, say something like :

#if __LONG_MAX__ > 0xffffffff
#error dlmodule only works in 32-bit mode.
#endif

Not sure why you would prefer an unstable, unreleased hg trunk version to a stable, released one.

And as you've seen, Python 2 and Python 3 are quite different things.

As for dl failing on build, you've already stated that it does *not* build, together with bsddb185 and gdbm (for which the library headers are missing).  setup.py does exactly that test for 64-bit platforms.  Then you activate it explicitly, and complain that it does build...

And lastly, all these things are *not* a build failure of Python: missing modules just means that, well, these modules won't be there.  And failing tests just means that there *may* be a problem when using the respective module -- but for platform-dependent modules it could just as well mean that your system is configured in a special way.

Now I'm really confused.

After linked /usr/bin/python to python3.3  :

  $ cd /usr/bin; rm -f python; ln -s python3.3 python;

the 2.7.1 build now succeeds ! 
(with the patched Lib/test/test_commands.py and the 'make test'
 run as non-root ).
This time I don't get any build errors for missing modules
and don't have to edit Module/Setup .
BTW, the missing modules that caused the build to fail before
was :
    'bsddb185 dl gdbm imageop'
; after the new ./python executable was built, it did some 
'configure modules' stage which DID fail with these missing
modules, but now /usr/bin/python is python3.3, it DOESN'T fail.

I don't think the current state of the installed system python
should be able to affect in any way the build of a new python -
that to me is a fundamental, critical bug in the build system.

Maybe I should open a new bug on that issue ?

But yes, the issue of this specific bug is now closed -
python-2.7.1 now builds OK - but PLEASE, put these 
lines or something like them in dlmodule.c :

#if __LONG_MAX__ > 0xffffffffU /* cpp -dM  builtin : __LONG_MAX__ */
#error dlmodule only works in 32-bit mode.
#endif

BTW, while I'm here :

Any advice on how to setup a truly multi-architecture python installation? 

I'm considering doing something like :

1. build same python source for both 32-bit and 64-bit, with
   64-bit installing /usr/lib/python-$V as /usr/lib64/python-$V  &
   32-bit installing /usr/lib/python-$V as /usr/lib32/python-$V

2. Replace /usr/bin/python with a shell script or program which does
   something like (in shell):
  
   #!/bin/sh
   if "`uname -m`" = i686 ; then # I'm in a 'setarch i686' env
      exec /usr/bin/32/python${0#python} $*
   else
      exec /usr/bin/python${0#python} $*
   fi

Any thoughts about / advice on doing something like this ?

Aha ! Is the above multi-arch config what would result if I did :

  --with-universal-archs=ARCH
                          select architectures for universal build  
                         ("32-bit",
                          "64-bit", "3-way", "intel" or "all")

ie: --with-univeral-archs='64-bit 32-bit' 

??

The fact that the python --configure ignores my '--libdir=/usr/lib64'
setting and installs files under /usr/lib regardless suggest this
would NOT work as I expect.

So to get python multi-arch working as I expect I'd have to wrap the C header:

   /usr/include/python-2.7/pyconfig.h

with something like:

#ifdef __i386__
#include <python-2.7/32/pyconfig.h>
#else
#include <python-2.7/64/pyconfig.h>
#endif

and that's it ! After building i686-Python-2.7.1,  I can do
"my standard python post-install script" :

$ ABI=64; V=2.7
$ DESTDIR=`pwd`/inst make install
$ cd inst/usr
$ mv lib${ABI}/python${V}/* lib/python$V
$ rmdir lib${ABI}/python-${V}
$ mv lib/python-${V} lib$ABI
$ rmdir lib

And then:
$ cd inst/usr/include/python$V
$ for f in *; do cmp $f /usr/include/python2.7/$f; done
pyconfig.h /usr/include/python2.7/pyconfig.h differ: char 11124, line 393
$ $ diff -U0 pyconfig.h /usr/include/python2.7/pyconfig.h
--- pyconfig.h  2011-04-30 13:34:21.000000000 +0100
+++ /usr/include/python2.7/pyconfig.h   2011-04-30 12:34:23.000000000 +0100
@@ -393 +393 @@
-#define HAVE_LARGEFILE_SUPPORT 1
+/* #undef HAVE_LARGEFILE_SUPPORT */
@@ -989 +989 @@
-#define SIZEOF_LONG 4
+#define SIZEOF_LONG 8
@@ -992 +992 @@
-#define SIZEOF_LONG_DOUBLE 12
+#define SIZEOF_LONG_DOUBLE 16
@@ -1004 +1004 @@
-#define SIZEOF_PTHREAD_T 4
+#define SIZEOF_PTHREAD_T 8
@@ -1010 +1010 @@
-#define SIZEOF_SIZE_T 4
+#define SIZEOF_SIZE_T 8
@@ -1013 +1013 @@
-#define SIZEOF_TIME_T 4
+#define SIZEOF_TIME_T 8
@@ -1016 +1016 @@
-#define SIZEOF_UINTPTR_T 4
+#define SIZEOF_UINTPTR_T 8
@@ -1019 +1019 @@
-#define SIZEOF_VOID_P 4
+#define SIZEOF_VOID_P 8
@@ -1069 +1069 @@
-/* #undef VA_LIST_IS_ARRAY */
+#define VA_LIST_IS_ARRAY 1
@@ -1121 +1121 @@
-#define X87_DOUBLE_ROUNDING 1
+/* #undef X87_DOUBLE_ROUNDING */

so this is the ONLY file that needs to be wrapped to work in a 
multi-arch environment.

BTW, I know you can't use runtime expressions such as 
  'sizeof(char*)' 
in cpp macros, but you CAN get much the same effect by
using cpp 'builtin macros' :
e.g. you could write :

#if __LONG_MAX__ > 0xffffffffU 
#define SIZEOF_LONG 8 /*works until you want to support 128 / 256 bit */
#else
#define SIZEOF_LONG 4 /* guess you don't want to support 16 or 8 bit ?*/
#endif

and then pyconfig.h would not need to be wrapped .

I'm going to state this one again: missing modules are *NOT* a build failure.

It is pretty common to not install a certain library (or headers for them), if you don't need/want the Python module using it.  (And editing Modules/Setup to add modules that setup.py detects as not buildable won't make them buildable in 99% of cases.)

As for the dl module, the existing check in setup.py is just fine, especially since dl is deprecated and not present anymore in 3.x.  There will always be ways to shoot yourself in the foot.

OK, the last two comment contained complete instructions for setting
up a working dual 64-bit + 32-bit python installation.

Final, working /usr/bin/python :

$ cat /usr/bin/python
#!/bin/sh
ME=$0
ME=${ME##*/}
VERSION=${ME#python}
VERSION=${VERSION:-2.7}
ARCH=`uname -m`
case $ARCH in
  i686)
     exec /usr/bin/32/${ME} $*
     ;;
  *)
     exec /usr/bin/python${VERSION} $*
     ;;
esac

So now, in a native 64-bit env :

$ python
Python 2.7.1 (r271:86832, Apr 30 2011, 11:55:52)
[GCC 4.6.0] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>>
^D
$ setarch i686
$ python
Python 2.7.1 (r271:86832, Apr 30 2011, 13:29:12)
[GCC 4.6.0] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>>

See the build times, they are different executables !

And final, complete working /usr/include/python2.7/pyconfig.h :

$ echo '#include <python2.7/pyconfig.h>' > pyc.c
$ cpp pyc.c
$ cpp pyc.c
# 1 "pyc.c"
# 1 "<built-in>"
# 1 "<command-line>"
# 1 "pyc.c"
# 1 "/usr/include/python2.7/pyconfig.h" 1 3 4



# 1 "/usr/include/python2.7/64/pyconfig.h" 1 3 4
# 5 "/usr/include/python2.7/pyconfig.h" 2 3 4
# 1 "pyc.c" 2
$ cpp -m32 pyc.c
# 1 "pyc.c"
# 1 "<built-in>"
# 1 "<command-line>"
# 1 "pyc.c"
# 1 "/usr/include/python2.7/pyconfig.h" 1 3 4

# 1 "/usr/include/python2.7/32/pyconfig.h" 1 3 4
# 3 "/usr/include/python2.7/pyconfig.h" 2 3 4
# 1 "pyc.c" 2


$ cat /usr/include/python2.7/pyconfig.h
#ifdef __i386__
#include <python2.7/32/pyconfig.h>
#else
#include <python2.7/64/pyconfig.h>
#endif

Oops, thought there may be gotchas to that multi-arch python wrapper -
it wasn't quoting its arguments properly - here is now what I have as
/usr/bin/python :

$ cat python
#!/bin/bash
ME=$0
ME=${ME##*/}
VERSION=${ME#python}
VERSION=${VERSION:-2.7}
ARCH=`uname -m`
CMD=''
case $ARCH in
  i686)
     CMD="/usr/bin/32/${ME}"
     ;;
  *)
     CMD="/usr/bin/python${VERSION}.bin"
     ;;
esac
for((a=1;a<=$#;a++));do CMD="${CMD} '"$(eval 'echo -n "$'$a'"')"' ";done
eval "exec $CMD"

I had to move the /usr/bin/python${VERSION} executables to 
/usr/bin/python${VERSION}.bin , and replace them with copies
of this python script (which runs whichever version it is named by).

And I can do:

$ python -c 'import os
import sys
import commands
print commands.getstatus("ls -ld /.")
'
drwxr-xr-x. 25 root root 4096 Apr 20 15:28 /.

under both the native x86_64 and a 'setarch i686' environment with
the same results.

final python wrapper script :

$ cat python
#!/bin/bash
ME=$0
ME=${ME##*/}
VERSION=${ME#python}
VERSION=${VERSION:-2.7.1}
ARCH=`uname -m`
CMD=''
case $ARCH in
  i686)
     CMD="/usr/bin/32/${ME}"
     ;;
  *)
     CMD="/usr/bin/python${VERSION}.bin"
     ;;
esac
for((a=1;a<=$#;a++));do CMD="${CMD} '$(eval 'echo -e "$'$a'"' | sed 's/['"'"']/'"'"'"'"'"'"'"'"'/g')' " ;done
eval "exec $CMD"


now handles:

$ ./python -c 'import os
import sys
import commands
print commands.getstatus('"'"'/.'"'"')
'
drwxr-xr-x. 25 root root 4096 Apr 20 15:28 /.

I got the same test_commands fail when building a Python2.7.1 which I downloaded yesterday; it's on an FC13 x86_64 server.
I've built python2.7 before using a similar machine, but it's not picking up my external libraries on a Sun Grid Engine, leaving me with import errors. Probably problems with the environment ($PYTHONHOME & $PYTHONPATH), but playing with these don't fix my batch jobs, so I've decided to build a cross-compiled version, which I've done on a Mac Pro before, but not a linux server, where --with-universal-archs doesn't work. I'm not a guru with using CFLAGS args during compilation, so I think I'll end up compiling it twice (long, I need this to work yesterday), using Jason's configure arguments (that -m32 is the ticket), and taking Jason's wrapper script, modifying it for my home dir. Thanks for posting that Jason!! I'd already started implementing something similar in my batch script, but yours looks much more thorough.
Whilst here, I wanted to advocate python a bit. I think it's awesome, and an article that articulates it's awesomeness fairly amusingly, can be found here:-
http://www.linuxjournal.com/article/3882
Still, I'm also disappointed with these build problems. I left `make test` running overnight and it had hung, using 100% of a CPU the whole night. I'm not even half-way to getting python compiled... :( Will probably also need to recompile ATLAS as well as numpy / biopython for both archs - no quick or easy feat.

The test_commands fix will be in 2.7.2.  2.7.1 was released well before the fix was made.

RE: comment msg137266 - thanks for responding, Alex - though
don't get misled by that wrapper script I wrote, though - I
ended up replacing it with a short "C" program, which I'll attach
after this comment.

RE: > I think Python is awesome ...

I think Python is awesome too - I've been programming with it for nearly
eight years now - but I HATE the modern propensity for replacing
perfectly OK "C" programs and shell scripts with Python , or any
other interpreter, "Just for the sake of it", 
- let's be clear what an interpreter or compiler's job is :
   it is to present the correct machine code to the computer for
   execution to perform a certain well defined task
. So I don't think an "interpreter script" is automatically, by
definition, preferable to a compiled executable.  And I don't
like significant white-space and PERL will always be my preferred
script interpreter, sorry Python, that's just the way it is .

I'm appending the "C" source python wrapper program that I use after this.

so I can do:

$ setarch i686 
$ strace -s8192  -e trace=execve /usr/bin/python
execve("/usr/bin/python", ["/usr/bin/python"], [/* 65 vars */]) = 0
execve("/usr/bin//32/python", ["/usr/bin//32/python"], [/* 66 vars */]) = 0
[ Process PID=3559 runs in 32 bit mode. ]
Python 2.7.1 (r271:86832, Apr 30 2011, 13:29:12)
[GCC 4.6.0] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>>
$ strace -s8192  -e trace=execve /usr/bin/python2.7
execve("/usr/bin/python2.7", ["/usr/bin/python2.7"], [/* 65 vars */]) = 0
execve("/usr/bin//32/python2.7", ["/usr/bin//32/python2.7"], [/* 66 vars */]) = 0
[ Process PID=3571 runs in 32 bit mode. ]
Python 2.7.1 (r271:86832, Apr 30 2011, 13:29:12)
[GCC 4.6.0] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>>

This is necessary because the 32-bit /usr/bin/32/python*'s PYTHONHOME is /usr/lib32/python2.7 , where 32-bit shared library python modules
are installed under lib-dynload/, while the native 64-bit's /usr/bin/python2.7's PYTHONHOME is /usr/lib64/python2.7 which has 64-bit 
libraries in lib-dynload . The 32-bit python uses /etc/32/ as its
$SYSCONFDIR .

Hey Jason,

Thanks for replying so quickly, and on a bank holiday! :)
This has completely diverged from the original bug, but whatever..

Thanks for the C wrapper too! It's not appropriate for my build environment, and I know no C, having only got so far as writing a hello world program with it, so I'll probably stick with my bash wrapper script for now.
Currently re-compiling python2.7.1 to support i686 machines. The first build wasn't allowing me to compile numpy with the supplied atlas libraries, failing to pick up the extension .so.3 / .so.3.0 which I think has something to do with position independent code, so I'm recompiling this 32 bit python with the following commands:-
$ export CFLAGS="-O2 -fPIC"
$ export CXXFLAGS=$CFLAGS
$ OPT=-m32 LDFLAGS=-m32 ./configure --prefix=$HOME/32

Does that seem sensible to you??
The relevant part of my bash wrapper script (for sun grid engine) is then something like:-

#!/bin/bash
if [[ "`uname -m`" = "x86_64" ]] ; then
        export PYTHONHOME=$HOME/
else   
        echo "arch = `uname -m`"
        export PYTHONHOME=$HOME/32
fi

RE: msg137311 : Alex - you wrote :
> I'm recompiling this 32 bit python with the following commands:-
> $ export CFLAGS="-O2 -fPIC"
> $ export CXXFLAGS=$CFLAGS
> $ OPT=-m32 LDFLAGS=-m32 ./configure --prefix=$HOME/32
> Does that seem sensible to you??

Well, it depends on the output of these commands on your system :
$ gcc -print-search-dirs | grep '^libraries'
libraries: =/usr/lib64/gcc/x86_64-pc-linux-gnu/4.6.0/:/usr/lib64/gcc/x86_64-pc-linux-gnu/4.6.0/../../../../x86_64-pc-linux-gnu/lib/x86_64-pc-linux-gnu/4.6.0/:/usr/lib64/gcc/x86_64-pc-linux-gnu/4.6.0/../../../../x86_64-pc-linux-gnu/lib/../lib64/:/usr/lib64/gcc/x86_64-pc-linux-gnu/4.6.0/../../../x86_64-pc-linux-gnu/4.6.0/:/usr/lib64/gcc/x86_64-pc-linux-gnu/4.6.0/../../../../lib64/:/lib/x86_64-pc-linux-gnu/4.6.0/:/lib/../lib64/:/usr/lib/x86_64-pc-linux-gnu/4.6.0/:/usr/lib/../lib64/:/usr/lib64/gcc/x86_64-pc-linux-gnu/4.6.0/../../../../x86_64-pc-linux-gnu/lib/:/usr/lib64/gcc/x86_64-pc-linux-gnu/4.6.0/../../../:/lib/:/usr/lib/

$ gcc -print-multi-os-directory
../lib64

Your C compiler should be appending an option such as :
  '--dynamic-linker=/lib32/ld-linux.so.2 -rpath /usr/lib32:/lib32' 
to it's ld(1) command line - if you have C compilation problems, look
at the output of adding '--verbose' to the $CFLAGS you
gave and looking at what options are used by gcc's 'collect' phase:
$ gcc -o /tmp/t ~jason/t.c --verbose 2>&1 | tail -n 2
COLLECT_GCC_OPTIONS='-o' '/tmp/t' '-v' '-mtune=k8' '-march=x86-64'
 /usr/libexec/gcc/x86_64-pc-linux-gnu/4.6.0/collect2 --eh-frame-hdr -m elf_x86_64 -dynamic-linker /lib64/ld-linux-x86-64.so.2 -o /tmp/t /usr/lib64/gcc/x86_64-pc-linux-gnu/4.6.0/../../../../lib64/crt1.o /usr/lib64/gcc/x86_64-pc-linux-gnu/4.6.0/../../../../lib64/crti.o /usr/lib64/gcc/x86_64-pc-linux-gnu/4.6.0/crtbegin.o -L/usr/lib64/gcc/x86_64-pc-linux-gnu/4.6.0 -L/usr/lib64/gcc/x86_64-pc-linux-gnu/4.6.0/../../../../lib64 -L/lib/../lib64 -L/usr/lib/../lib64 -L/usr/lib64/gcc/x86_64-pc-linux-gnu/4.6.0/../../../../x86_64-pc-linux-gnu/lib -L/usr/lib64/gcc/x86_64-pc-linux-gnu/4.6.0/../../.. /tmp/ccoSip93.o -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed /usr/lib64/gcc/x86_64-pc-linux-gnu/4.6.0/crtend.o /usr/lib64/gcc/x86_64-pc-linux-gnu/4.6.0/../../../../lib64/crtn.o

$ gcc -m32 -o /tmp/t ~jason/t.c --verbose 2>&1 | tail -n 2
COLLECT_GCC_OPTIONS='-m32' '-o' '/tmp/t' '-v' '-mtune=i686' '-march=x86-64'
 /usr/libexec/gcc/x86_64-pc-linux-gnu/4.6.0/collect2 --eh-frame-hdr -m elf_i386 -dynamic-linker /lib32/ld-linux.so.2 -o /tmp/t /usr/lib64/gcc/x86_64-pc-linux-gnu/4.6.0/../../../../lib32/crt1.o /usr/lib64/gcc/x86_64-pc-linux-gnu/4.6.0/../../../../lib32/crti.o /usr/lib64/gcc/x86_64-pc-linux-gnu/4.6.0/32/crtbegin.o -L/usr/lib64/gcc/x86_64-pc-linux-gnu/4.6.0/32 -L/usr/lib64/gcc/x86_64-pc-linux-gnu/4.6.0/../../../../lib32 -L/lib/../lib32 -L/usr/lib/../lib32 -L/usr/lib64/gcc/x86_64-pc-linux-gnu/4.6.0 -L/usr/lib64/gcc/x86_64-pc-linux-gnu/4.6.0/../../../../x86_64-pc-linux-gnu/lib -L/usr/lib64/gcc/x86_64-pc-linux-gnu/4.6.0/../../.. /tmp/ccZzwAuw.o -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed /usr/lib64/gcc/x86_64-pc-linux-gnu/4.6.0/32/crtend.o /usr/lib64/gcc/x86_64-pc-linux-gnu/4.6.0/../../../../lib32/crtn.o

'~jason/t.c' is just :
$ echo -e '#include <stdio.h>\nint main(){ printf("hello world!\n");}' > ~jason/t.c




If you are on a RedHat derived system, where /lib/ld-linux.so.2 is
32-bit ,  you should be OK;  if, however, you are on a Gentoo
derived or "my style" system, your

Oops, cut myself off mid-sentence in that previous comment ... AIWS :

If you are on a RedHat derived system, where /lib/ld-linux.so.2 is
32-bit ,  you should be OK;  if, however, you are on a Gentoo
derived or "my style" system, you need to make sure your 
gcc is compiled with '--enable-multilib' and '--enable-targets=all',
as mine is , and that you have applied something like this patch
to gcc's gcc/config/i386/linux*.h files:

$ gendiff gcc/config '~'
diff -up gcc/config/i386/linux.h~ gcc/config/i386/linux.h
--- gcc/config/i386/linux.h~    2011-01-14 18:45:06.000000000 +0000
+++ gcc/config/i386/linux.h     2011-04-05 22:17:10.000000000 +0100
@@ -92,7 +92,7 @@ along with GCC; see the file COPYING3.

 /* These macros may be overridden in k*bsd-gnu.h and i386/k*bsd-gnu.h. */
 #define LINK_EMULATION "elf_i386"
-#define GLIBC_DYNAMIC_LINKER "/lib/ld-linux.so.2"
+#define GLIBC_DYNAMIC_LINKER "/lib32/ld-linux.so.2"

 #undef  ASM_SPEC
 #define ASM_SPEC \
diff -up gcc/config/i386/linux64.h~ gcc/config/i386/linux64.h
--- gcc/config/i386/linux64.h~  2011-03-02 22:35:36.000000000 +0000
+++ gcc/config/i386/linux64.h   2011-04-05 22:17:33.000000000 +0100
@@ -62,7 +62,7 @@ see the files COPYING3 and COPYING.RUNTI
    When the -shared link option is used a final link is not being
    done.  */

-#define GLIBC_DYNAMIC_LINKER32 "/lib/ld-linux.so.2"
+#define GLIBC_DYNAMIC_LINKER32 "/lib32/ld-linux.so.2"
 #define GLIBC_DYNAMIC_LINKER64 "/lib64/ld-linux-x86-64.so.2"

 #if TARGET_64BIT_DEFAULT

The alternative is to use a "GCC Spec File" , such as
that printed by 
 $ gcc -dumpspecs

Here is one such I've used in the past to overcome similar problems:

$ cat /home/jason/local32.spec
*lib:
+ -lc_nonshared

*startfiles:
+ /lib32/crti.o

*endfiles:
+ /lib32/crtn.o

*link:
+ -dynamic-linker /usr/local/lib%{!m32:64}%{m32:32}/ld-linux-%{!m32:x86_64}%{m32:i386}.so.2 -L/usr/local/lib/gcc-lib/%{!m32:x86_64-redhat-linux}%{m32:i386-redhat-linux}/4/%{m32:32} -L/usr/local/lib/%{!m32:64}%{m32:32} -R/usr/local/lib/gcc/%{!m32:x86_64-redhat-linux}%{m32:i386-redhat-linux}/4 -R/usr/local/lib%{m32:32}%{!m32:64} -R/usr/local/lib

*cpp:
+ -isystem /usr/local/include