OK, so I reconfigured, made, etc:
137 14:29 ./configure CFLAGS=-m32 FFLAGS=-m32
--build=i586-suse-linux --enable-static --disable-shared
--without-threads --prefix=/home/ndebard/local/ompi
--with-devel-headers --disable-io-romio --disable-f77
138 14:48 make clean all install
But mpicc now segfaults immediately:
[sparkplug]~/ompi > /home/ndebard/local/ompi/bin/mpicc
Segmentation fault
[sparkplug]~/ompi > gdb /home/ndebard/local/ompi/bin/mpicc
GNU gdb 6.1
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and
you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for
details.
This GDB was configured as "x86_64-suse-linux"...DW_FORM_strp pointing
outside of .debug_str section [in module
/home/ndebard/local/ompi/bin/mpicc]
Using host libthread_db library "/lib64/tls/libthread_db.so.1".
(gdb) run
Starting program: /home/ndebard/local/ompi/bin/mpicc
(no debugging symbols found)...(no debugging symbols found)...(no
debugging symbols found)...(no debugging symbols found)...(no
debugging symbols found)...(no debugging symbols found)...(no
debugging symbols found)...
Program received signal SIGSEGV, Segmentation fault.
0x0000000000408d4a in ?? ()
(gdb) where
#0 0x0000000000408d4a in ?? ()
Cannot access memory at address 0xbfffecf8
(gdb)
[sparkplug]~/ompi > /home/ndebard/local/ompi/bin/mpic++
Segmentation fault
[sparkplug]~/ompi >
-- Nathan
Correspondence
---------------------------------------------------------------------
Nathan DeBardeleben, Ph.D.
Los Alamos National Laboratory
Parallel Tools Team
High Performance Computing Environments
phone: 505-667-3428
email: ndeb...@lanl.gov
---------------------------------------------------------------------
Brian Barrett wrote:
On Aug 12, 2005, at 3:22 PM, Nathan DeBardeleben wrote:
Thanks, trying that now. While I'd like those things in the long run,
they're not needed right now to test what I'm trying to test. Will
let
you know how it goes! (What's the problem, by the way?)
The problem is that I key off the target host string to decide what
assembly to use for the atomic operations. For most 64 bit
platforms, the architecture string is the same for 32/64 bit and then
you use sizeof(long) to determine whether to use 32 or 64 bit
instructions. So what I need to add to the configure script is a
check if we're on x86_64 that if sizeof(long) == 4, we use the
assembly for x86, not x86_64.
Brian
