Re: [OMPI users] openmpi 1.3.1: bind() failed: Permission denied (13)

[Jerome BENOIT]

Hello List,

Dirk Eddelbuettel wrote:

On 3 April 2009 at 06:35, Jerome BENOIT wrote:
| It appeared that the file /etc/openmpi/openmpi-mca-params.conf on node green 
was the only one
| into the cluster to contain the line
| 
| btl_tcp_port_min_v4 = 49152


Great -- so can we now put your claims of 'the Debian package is broken' to 
rest?




This claim is not mine:
in a former post it was suggested that the current Debian package (1.3-2) in 
Sid is broken,
and that I may check with the svn Debian package. So I tried: may be it was not 
such a good idea
as a lot thing was new for me: svn Debian stuff, OpenMPI, ...


This seems to be a local admin issue as such a line is unlikely to have been
added by either the Debian Open MPI or slurm packages.


This is clearly an admin issue: maintaining  a cluster of clones is quite a 
challenge  :-)

Thanks,
Jerome



Good to know you have it all working,   


Dirk

Re: [OMPI users] [Fwd: Re: Configure OpenMPI and SLURMon Debian (Lenny)]

[Jerome BENOIT]

Hello List !

George Bosilca wrote:
The range of ports for the OOB TCP has been removed by commit r20390. 
Apparently it was replaced by the static port functionality. Only the 
TCP BTL use the range mechanism.



if applicable, what is the parameter name for the this static port ?


Thanks in advance,
Jerome



  george.

On Mar 27, 2009, at 08:56 , Jeff Squyres wrote:


George --

Did we change anything about the fixed ports stuff between 1.3.0 and 
1.3.1?


Jerome -- can you send the full mpirun command / environment variables 
/ MCA file settings that you tried to run to generate the error 
message that you showed?



On Mar 27, 2009, at 5:52 AM, Manuel Prinz wrote:


Am Freitag, den 27.03.2009, 20:34 +0800 schrieb Jerome BENOIT:
> I have just tried the Sid package (1.3-2), but it does not work 
properly

> (when the firewall are off)

Though this should work, the version in Sid is broken in other respects.
I do not recommend using it.

> I have just read that the current stable version for OpenMPI is now 
1.3.1:

> I will give it a try once it will be packaged in Sid.

I'm the Open MPI maintainer in Debian and am planning to upload a fixed
version soon, possible around middle of next week. (It has to be
coordinated with the release team.) There is a working version availble
in SVN (try "debcheckout openmpi"). You can either build it yourself or
I could build it for you. You can mail me in private if you'd like me to
do so. Please not that installing the new version will break other
MPI-related Debian packages. I can explain you the details in private
mail since I think this is off-topic for the list.

Best regards
Manuel

___
users mailing list
us...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/users



--
Jeff Squyres
Cisco Systems

___
users mailing list
us...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/users


___
users mailing list
us...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/users

Re: [OMPI users] Issues on install 1.3.1

[Francesco Pietra]

As far as I understand,

apt-get install libnuma1 libnuma-dbg libnuma-dev

installs libnuma libraries 64 bit in /usr/lib there also two symlinks
/usr/lib32 and /usr/lib64 but there is no trace of the libnuma
libraries there.

That the computational codes I use run twice as fast at 64 bit than 32 bit

thanks
francescois well established.

On Fri, Apr 3, 2009 at 3:14 AM, Iain Bason  wrote:
>
> On Apr 2, 2009, at 2:45 PM, Gus Correa wrote:
>
>> Sorry, I don't have an answer about performance.
>> You may need to ask somebody else or google around
>> about the relative performance of 32-bit vs. 64-bit mode.
>
> It is worth trying 64-bit.  The performance is going to depend on the
> program.  Since 64 bit pointers take more cache space, a program that uses a
> lot of pointers will run more slowly.  However, the x64 architecture has
> more registers than the x86 architecture, and that can make a 64 bit program
> run faster.  Overall, it is probably more common for program to run faster
> in 64 bit mode, but your program could be in the minority.
>
> Iain
>
> ___
> users mailing list
> us...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/users
>

Re: [OMPI users] Issues on install 1.3.1

[Francesco Pietra]

Sorry for such pedestrian misprint.

Corrected, the configure ended with error:

"Expected file /usr/lib/include/numa.h"

In debian amd64 lenny it has a different location:

"/usr/include/numa.h"


Can the configure script be modified safely to account for the
different location?
thanks

francesco

On Thu, Apr 2, 2009 at 1:46 PM, Jeff Squyres  wrote:
> On Apr 2, 2009, at 7:21 AM, Francesco Pietra wrote:
>
>> Hi:
>> With debian linux amd64 lenny I tried to install openmpi-1.3.1 instead
>> of using the executables openmpi-1.2.6 of previous disks. I configured
>> as for 1.2.6 (wrong ?)
>>
>> CC=/opt/intel/cce/10.1.015/bin/icc CXX=opt/intel/cce/10.1.015/bin/icpc
>>
>
> Don't you need a / in the beginning of the CXX definition?
>
>> F77=/opt/intel/fce/10.1.015/bin/ifort
>> FC=/opt/intel/fce/10.1.015/bin/ifort --with-libnuma=/usr/lib
>>
>> getting:
>>
>> checking whether using GNU C++ compiler .. yes
>>
>> dependency style icpc ...  gcc3
>>
>> checking how to run C++ preprocessor ... /lib/cpp
>>
>> checking for compiler vendor ... intel
>>
>> cheching if C++ compiler works .. NO
>>
>> it is not clear to me to which compiler NO refers: gcc or intel? I
>>
>
> I would assume the C++ compiler is icpc since it's in your (abbreviated)
> output shown above.
>
>> would also appreciate very much a direction how to chech gcc and intel
>> C++ independently.
>>
>
> I'm not sure what you're asking here..?  Open MPI's configure has 2
> independent sections checking characteristics of the C and C++ compilers.
>
> --
> Jeff Squyres
> Cisco Systems
>
> ___
> users mailing list
> us...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/users
>

Re: [OMPI users] openmpi 1.3.1: bind() failed: Permission denied (13)

[Jeff Squyres]

On Apr 3, 2009, at 3:36 AM, Jerome BENOIT wrote:

> This seems to be a local admin issue as such a line is unlikely to  
have been

> added by either the Debian Open MPI or slurm packages.

This is clearly an admin issue: maintaining  a cluster of clones is  
quite a challenge  :-)





It certainly is.  You might want to look into getting some software to  
help manage your cluster; there are several decent packages out  
there.  SLURM is good for workload management (I use it myself, but of  
course, there are many others); there are others that help manage the  
software side of your cluster (e.g., helping ensure you have the same  
software installed on all nodes in the cluster, etc.).  I personally  
use Perceus, but there are several available.


--
Jeff Squyres
Cisco Systems

Re: [OMPI users] [Fwd: Re: Configure OpenMPIand SLURMon Debian (Lenny)]

[Jeff Squyres]

What George is saying is that OMPI has two different systems that use  
sockets: the BTL (MPI communications) and the OOB (OMPI's internal  
management communications).


We've been talking about the TCP BTL parameters over the rest of this  
thread.


For the TCP OOB, it looks like the parameter name is  
"oob_tcp_static_ports".  I think it takes a comma-delimited list of  
ports.  You can probably specify, say, 1 for btl_tcp_port_min_v4  
and 9000 for oob_tcp_static_ports.  For example:


mpirun --mca oob_tcp_static_ports 9000 --mca oob_tcp_static_ports  
1 --mca btl tcp,self ring


If you don't want to put those two variables on every mpirun command,  
you can set them in your environment, put them in your personal params  
file, or in the master params file.  Just make sure that those files  
are either the same on all nodes or visible on all nodes.  :-)


http://www.open-mpi.org/faq/?category=tuning#setting-mca-params


On Apr 3, 2009, at 4:33 AM, Jerome BENOIT wrote:


Hello List !

George Bosilca wrote:
> The range of ports for the OOB TCP has been removed by commit  
r20390.
> Apparently it was replaced by the static port functionality. Only  
the

> TCP BTL use the range mechanism.


if applicable, what is the parameter name for the this static port ?




--
Jeff Squyres
Cisco Systems

[OMPI users] Problems Compiling OpenMPI with Sun Studio 12 compilers on RHEL 5

[Segovia, Andrea]

> Hello,
> 
> I am trying to compile OpenMPI on a Red Hat Enterprise Linux 5 platform with 
> the Sun Studio 12 compiler suite. (I currently have the Red Hat-bundled 
> OpenMPI w/GNU compilers running). 
> 
> I have already encountered and addressed the problem of the C++ compiler not 
> working in 64 bit mode with the Red Hat-bundled GNU ld by not including sunCC 
> in the OpenMPI compilation, since we do not need C++ support.
> 
> However, I have encountered another problem when attempting to compile (at 
> the "make all" stage):
> 
> asm/.libs/libasm.a(atomic-asm.o): In function `opal_atomic_mb':
> (.text+0x0): multiple definition of `opal_atomic_mb'
> asm/.libs/libasm.a(asm.o):asm.c:(.text+0x0): first defined here
> asm/.libs/libasm.a(atomic-asm.o): In function `opal_atomic_rmb':
> (.text+0x6): multiple definition of `opal_atomic_rmb'
> asm/.libs/libasm.a(asm.o):asm.c:(.text+0x10): first defined here
> 
> ..(small excerpt)
> 
> Sun has published bug information about a similar error here:  
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6567405 but I don't know 
> if it applies. Besides, their suggested fix is to change the source code, 
> something I would be extremely reluctant to do.
> 
> The OpenMPI users mailing list has at one reference to this problem here: 
> http://www.open-mpi.org/community/lists/users/2008/10/6908.php but I have not 
> been able to find a solution.
> 
> I am enclosing a gzipped tar file with the configure output, config.log and 
> make output as suggested.
> 
> >  <> 
> 
> I am using the following options to configure (based on the recommendations 
> on the OpenMPI FAQ here: 
> http://www.open-mpi.org/faq/?category=building#build-sun-compilers )This 
> section references the errors found above but does not provide a work-around. 
> 
  $ ./configure CC=suncc F77=sunf77 FC=sunf90 
--prefix=/export/home/segovia/RunTime_Environ/ --enable-heterogeneous 
--enable-shared--enable-orterun-prefix-by-default --enable-mpi-f90 
--with-mpi-f90-size=small --disable-mpi-threads --disable-progress-threads 
--disable-debug --with-openib --without-udapl --disable-openib-ibcm

> Has anyone been successful with this build? What options/workarounds were 
> necessary to compile?
> 
> Any help or information would be greatly appreciated.
> 
> Andrea Segovia
> IM&TS,  Data Centre Services, East / GIST, Services du Centre de traitement 
> des données de l' est
> Fisheries and Oceans Canada | Pêches et Océans Canada


ompi_output.tar.gz
Description: ompi_output.tar.gz

Re: [OMPI users] [Fwd: Re: Configure OpenMPIand SLURMon Debian (Lenny)]

[Jerome BENOIT]

Thanks for the reply !


I asked because

ompi_info --param all all | grep static

gave nothing.

This feature is certainly for the coming version.

Jeff Squyres wrote:
What George is saying is that OMPI has two different systems that use 
sockets: the BTL (MPI communications) and the OOB (OMPI's internal 
management communications).


We've been talking about the TCP BTL parameters over the rest of this 
thread.


For the TCP OOB, it looks like the parameter name is 
"oob_tcp_static_ports".  I think it takes a comma-delimited list of 
ports.  You can probably specify, say, 1 for btl_tcp_port_min_v4 and 
9000 for oob_tcp_static_ports.  For example:


mpirun --mca oob_tcp_static_ports 9000 --mca oob_tcp_static_ports 
1 --mca btl tcp,self ring


If you don't want to put those two variables on every mpirun command, 
you can set them in your environment, put them in your personal params 
file, or in the master params file.  Just make sure that those files are 
either the same on all nodes or visible on all nodes.  :-)


I had my lesson !

Thanks,
Jerome



http://www.open-mpi.org/faq/?category=tuning#setting-mca-params


On Apr 3, 2009, at 4:33 AM, Jerome BENOIT wrote:


Hello List !

George Bosilca wrote:
> The range of ports for the OOB TCP has been removed by commit r20390.
> Apparently it was replaced by the static port functionality. Only the
> TCP BTL use the range mechanism.


if applicable, what is the parameter name for the this static port ?

Re: [OMPI users] Problems Compiling OpenMPI with Sun Studio 12 compilers on RHEL 5

[Brian W. Barrett]

Hi -

Unfortunately, as the bug at Sun's web site points out, their compiler is 
borked.  There's not a lot we can do about that fact, without causing a 
whole host of other problems.


If you aren't using C++, I'd recommend compiling Open MPI with GCC and 
then reseting the wrapper compilers to invoke the Sun C compiler for 
applications.  The two compilers are link-time compatible, so this won't 
cause any problems and you're unlikely to see any performance difference 
depending on which compiler you use to compile Open MPI (applications are, 
of course, a different story).  Have a look at the following FAQ entry for 
a quick how-to.


http://www.open-mpi.org/faq/?category=mpi-apps#override-wrappers-after-v1.0

Brian


On Fri, 3 Apr 2009, Segovia, Andrea wrote:



Hello,

I am trying to compile OpenMPI on a Red Hat Enterprise Linux 5 platform
with the Sun Studio 12 compiler suite. (I currently have the Red
Hat-bundled OpenMPI w/GNU compilers running).

I have already encountered and addressed the problem of the C++ compiler
not working in 64 bit mode with the Red Hat-bundled GNU ld by not
including sunCC in the OpenMPI compilation, since we do not need C++
support.

However, I have encountered another problem when attempting to compile
(at the "make all" stage):

asm/.libs/libasm.a(atomic-asm.o): In function `opal_atomic_mb':
(.text+0x0): multiple definition of `opal_atomic_mb'
asm/.libs/libasm.a(asm.o):asm.c:(.text+0x0): first defined here
asm/.libs/libasm.a(atomic-asm.o): In function `opal_atomic_rmb':
(.text+0x6): multiple definition of `opal_atomic_rmb'
asm/.libs/libasm.a(asm.o):asm.c:(.text+0x10): first defined here

..(small excerpt)

Sun has published bug information about a similar error here: 
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6567405 but I don't
know if it applies. Besides, their suggested fix is to change the source
code, something I would be extremely reluctant to do.

The OpenMPI users mailing list has at one reference to this problem here:
http://www.open-mpi.org/community/lists/users/2008/10/6908.php but I have
not been able to find a solution.

I am enclosing a gzipped tar file with the configure output, config.log
and make output as suggested.

<>

I am using the following options to configure (based on the
recommendations on the OpenMPI FAQ here:
http://www.open-mpi.org/faq/?category=building#build-sun-compilers )This
section references the errors found above but does not provide a
work-around.

  $ ./configure CC=suncc F77=sunf77 FC=sunf90
--prefix=/export/home/segovia/RunTime_Environ/ --enable-heterogeneous
--enable-shared--enable-orterun-prefix-by-default --enable-mpi-f90
--with-mpi-f90-size=small --disable-mpi-threads
--disable-progress-threads --disable-debug --with-openib --without-udapl
--disable-openib-ibcm

Has anyone been successful with this build? What options/workarounds were
necessary to compile?

Any help or information would be greatly appreciated.

Andrea Segovia
IM&TS,  Data Centre Services, East / GIST, Services du Centre de
traitement des données de l' est
Fisheries and Oceans Canada | Pêches et Océans Canada

Re: [OMPI users] [Fwd: Re: ConfigureOpenMPIand SLURMon Debian (Lenny)]

[Jeff Squyres]

Gahh -- you're right.  I accidentally checked our development trunk,  
not the released v1.3 series...  Sorry for the confusion.


George, too, was referring to something that happened on our  
development trunk, not the v1.3 series.



On Apr 3, 2009, at 10:16 AM, Jerome BENOIT wrote:


Thanks for the reply !


I asked because

 ompi_info --param all all | grep static

gave nothing.

This feature is certainly for the coming version.

Jeff Squyres wrote:
> What George is saying is that OMPI has two different systems that  
use

> sockets: the BTL (MPI communications) and the OOB (OMPI's internal
> management communications).
>
> We've been talking about the TCP BTL parameters over the rest of  
this

> thread.
>
> For the TCP OOB, it looks like the parameter name is
> "oob_tcp_static_ports".  I think it takes a comma-delimited list of
> ports.  You can probably specify, say, 1 for  
btl_tcp_port_min_v4 and

> 9000 for oob_tcp_static_ports.  For example:
>
> mpirun --mca oob_tcp_static_ports 9000 --mca  
oob_tcp_static_ports

> 1 --mca btl tcp,self ring
>
> If you don't want to put those two variables on every mpirun  
command,
> you can set them in your environment, put them in your personal  
params
> file, or in the master params file.  Just make sure that those  
files are

> either the same on all nodes or visible on all nodes.  :-)

I had my lesson !

Thanks,
Jerome

>
> http://www.open-mpi.org/faq/?category=tuning#setting-mca-params
>
>
> On Apr 3, 2009, at 4:33 AM, Jerome BENOIT wrote:
>
>> Hello List !
>>
>> George Bosilca wrote:
>> > The range of ports for the OOB TCP has been removed by commit  
r20390.
>> > Apparently it was replaced by the static port functionality.  
Only the

>> > TCP BTL use the range mechanism.
>>
>>
>> if applicable, what is the parameter name for the this static  
port ?

>>
>
>
___
users mailing list
us...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/users



--
Jeff Squyres
Cisco Systems

Re: [OMPI users] Problems Compiling OpenMPI with Sun Studio 12

[Terry Dontje]

Which version of the Sun Studio compilers are you using also which 
version of OMPI are you trying to build.  I am successful with building 
OMPI with the Sun Studio Express release 200811 on Linux systems if I 
don't use the C++ compiler.  Prior releases we did suffer from some 
issues.  A "cc -V" will give you the exact version of Sun Studio you are 
using.


I noticed in your configure line below you don't have a space between 
"--enable-shared" and "--enable-orterun-prefix-by-default ".  Not sure 
this has anything to do with your problem but it might cause unintended 
results.


--td


Date: Fri, 03 Apr 2009 10:58:00 -0300 From: "Segovia, Andrea" 
 Subject: [OMPI users] Problems Compiling 
OpenMPI with Sun Studio 12 compilers on RHEL 5 To: us...@open-mpi.org 
Message-ID: 
 
Content-Type: text/plain; charset="iso-8859-1"

> Hello,
> 
> I am trying to compile OpenMPI on a Red Hat Enterprise Linux 5 platform with the Sun Studio 12 compiler suite. (I currently have the Red Hat-bundled OpenMPI w/GNU compilers running). 
> 
> I have already encountered and addressed the problem of the C++ compiler not working in 64 bit mode with the Red Hat-bundled GNU ld by not including sunCC in the OpenMPI compilation, since we do not need C++ support.
> 
> However, I have encountered another problem when attempting to compile (at the "make all" stage):
> 
> asm/.libs/libasm.a(atomic-asm.o): In function `opal_atomic_mb':

> (.text+0x0): multiple definition of `opal_atomic_mb'
> asm/.libs/libasm.a(asm.o):asm.c:(.text+0x0): first defined here
> asm/.libs/libasm.a(atomic-asm.o): In function `opal_atomic_rmb':
> (.text+0x6): multiple definition of `opal_atomic_rmb'
> asm/.libs/libasm.a(asm.o):asm.c:(.text+0x10): first defined here
> 
> ..(small excerpt)
> 
> Sun has published bug information about a similar error here:  http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6567405 but I don't know if it applies. Besides, their suggested fix is to change the source code, something I would be extremely reluctant to do.
> 
> The OpenMPI users mailing list has at one reference to this problem here: http://www.open-mpi.org/community/lists/users/2008/10/6908.php but I have not been able to find a solution.
> 
> I am enclosing a gzipped tar file with the configure output, config.log and make output as suggested.
> 

> >  <> 
  
> 
> I am using the following options to configure (based on the recommendations on the OpenMPI FAQ here: http://www.open-mpi.org/faq/?category=building#build-sun-compilers )This section references the errors found above but does not provide a work-around. 
> 


  $ ./configure CC=suncc F77=sunf77 FC=sunf90 
--prefix=/export/home/segovia/RunTime_Environ/ --enable-heterogeneous 
--enable-shared--enable-orterun-prefix-by-default --enable-mpi-f90 
--with-mpi-f90-size=small --disable-mpi-threads --disable-progress-threads 
--disable-debug --with-openib --without-udapl --disable-openib-ibcm

  

> Has anyone been successful with this build? What options/workarounds were 
necessary to compile?
> 
> Any help or information would be greatly appreciated.
> 
> Andrea Segovia

> IM&TS,  Data Centre Services, East / GIST, Services du Centre de traitement 
des donn?es de l' est
> Fisheries and Oceans Canada | P?ches et Oc?ans Canada

[OMPI users] libnuma issue

[Francesco Pietra]

I am posting again more specifically because it may have been buried
in a more generic thread.

With debian linux amd64 lenny and openmpi-1.3.1

./configure cc=/opt/intel/cce/10.1.015/bin/icc
cxx=/opt/intel/cce/10.1.015/bin/icpc
F77=/opt/intel/fce/10.1.015/bin/ifort
FC=/opt/intel/fce/10.1.015/bin/ifort --with-libnuma=/usr/lib

failed because

"expected file /usr/lib/include/numa.h was not found"

In debian amd64 lenny numa.h has a different location
"/usr/include/numa.h". Attached is the config.log.

I would appreciate help in circumventing the problem.

Thanks
francesco pietra
This file contains any messages produced by compilers while
running configure, to aid debugging if configure makes a mistake.

It was created by Open MPI configure 1.3.1, which was
generated by GNU Autoconf 2.63.  Invocation command line was

  $ ./configure cc=/opt/intel/cce/10.1.015/bin/icc cxx=/opt/intel/cce/10.1.015/bin/icpc F77=/opt/intel/fce/10.1.015/bin/ifort FC=/opt/intel/fce/10.1.015/bin/ifort --with-libnuma=/usr/lib

## - ##
## Platform. ##
## - ##

hostname = tya64
uname -m = x86_64
uname -r = 2.6.26-1-amd64
uname -s = Linux
uname -v = #1 SMP Fri Mar 13 17:46:45 UTC 2009

/usr/bin/uname -p = unknown
/bin/uname -X = unknown

/bin/arch  = unknown
/usr/bin/arch -k   = unknown
/usr/convex/getsysinfo = unknown
/usr/bin/hostinfo  = unknown
/bin/machine   = unknown
/usr/bin/oslevel   = unknown
/bin/universe  = unknown

PATH: /usr/local/sbin
PATH: /usr/local/bin
PATH: /usr/sbin
PATH: /usr/bin
PATH: /sbin
PATH: /bin


## --- ##
## Core tests. ##
## --- ##

configure:3412: checking for a BSD-compatible install
configure:3480: result: /usr/bin/install -c
configure:3491: checking whether build environment is sane
configure:3534: result: yes
configure:3559: checking for a thread-safe mkdir -p
configure:3598: result: /bin/mkdir -p
configure:3611: checking for gawk
configure:3641: result: no
configure:3611: checking for mawk
configure:3627: found /usr/bin/mawk
configure:3638: result: mawk
configure:3649: checking whether make sets $(MAKE)
configure:3671: result: yes
configure:3841: checking how to create a ustar tar archive
configure:3854: tar --version
tar (GNU tar) 1.20
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by John Gilmore and Jay Fenlason.
configure:3857: $? = 0
configure:3897: tardir=conftest.dir && eval tar --format=ustar -chf - "$tardir" >conftest.tar
configure:3900: $? = 0
configure:3904: tar -xf - &5
gcc (Debian 4.3.2-1.1) 4.3.2
Copyright (C) 2008 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

configure:6272: $? = 0
configure:6279: gcc -v >&5
Using built-in specs.
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.3.2-1.1' --with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.3 --program-suffix=-4.3 --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --enable-mpfr --enable-cld --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.3.2 (Debian 4.3.2-1.1) 
configure:6283: $? = 0
configure:6290: gcc -V >&5
gcc: '-V' option must have argument
configure:6294: $? = 1
configure:6317: checking for C compiler default output file name
configure:6339: gcc -DNDEBUGconftest.c  >&5
configure:6343: $? = 0
configure:6381: result: a.out
configure:6400: checking whether the C compiler works
configure:6410: ./a.out
configure:6414: $? = 0
configure:6433: result: yes
configure:6440: checking whether we are cross compiling
configure:6442: result: no
configure:6445: checking for suffix of executables
configure:6452: gcc -o conftest -DNDEBUGconftest.c  >&5
configure:6456: $? = 0
configure:6482: result: 
configure:6488: checking for suffix of object files
configure:6514: gcc -c -DNDEBUG   conftest.c >&5
configure:6518: $? = 0
configure:6543: result: o
configure:6547: checking whether we are using the GNU C compiler
configure:6576: gcc -c -DNDEBUG   conftest.c >&5
configure:6583: $? = 0
configure:6600: result: yes
configure:6609: checking whether gcc accepts -g
configure:6639: gcc -c -g  conftest.c >&5
configure:6646: $? = 0
configure:6747: result: yes
configure:6764: checking for gcc option to accept ISO C89
configure:6838: gcc  -c -DNDEBUG   conftest.c >&5
configure:6845: $? = 0
configure:6868: result: none needed
configure:6888: checking dependency style of gcc
configure:6

Re: [OMPI users] libnuma issue

[John Hearns]

2009/4/3 Francesco Pietra :
> > "expected file /usr/lib/include/numa.h was not found"
>
> In debian amd64 lenny numa.h has a different location
> "/usr/include/numa.h". Attached is the config.log.
>
> I would appreciate help in circumventing the problem.

It is /usr/include/numa.h on SuSE also (SLES 9 and SLES 10 to be
exact, I just checked).

I guess if the configure option ./configure
--with-libnuma=/path/to/libnuma/installation
does not help then you could
set a link from /usr/lib/include/numa.h to the real file
But I didn't say that, right? You don't know me. A nod is good as a
wink to a blind man.

Re: [OMPI users] libnuma issue

[Francesco Pietra]

I was not sure whether that is a technically correct procedure. It works. Thanks
francesco

On Fri, Apr 3, 2009 at 6:05 PM, John Hearns  wrote:
> 2009/4/3 Francesco Pietra :
>> > "expected file /usr/lib/include/numa.h was not found"
>>
>> In debian amd64 lenny numa.h has a different location
>> "/usr/include/numa.h". Attached is the config.log.
>>
>> I would appreciate help in circumventing the problem.
>
> It is /usr/include/numa.h on SuSE also (SLES 9 and SLES 10 to be
> exact, I just checked).
>
> I guess if the configure option ./configure
> --with-libnuma=/path/to/libnuma/installation
> does not help then you could
> set a link from /usr/lib/include/numa.h to the real file
> But I didn't say that, right? You don't know me. A nod is good as a
> wink to a blind man.
> ___
> users mailing list
> us...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/users
>

Re: [OMPI users] libnuma issue

[John Hearns]

2009/4/3 Francesco Pietra :
> I was not sure whether that is a technically correct procedure. It works. 
> Thanks
>

It most certainly is not. But I have been a Unix system admin for many
years. I have done things which I am
not proud of
If I ever offer to let you use my keyboard, wash your hands afterwards.

Re: [OMPI users] libnuma issue

[Francesco Pietra]

"I was not sure" before your mail. I was sure after that.

I'm a chemist with little knowledge of systems. I used in the past to
make symlinks to outdated or upgraded libraries. It worked, but I was
aware of the risk. This case has no risk. I was in a mess, now partly
out. The code I'm interested in does not want to be compiled. Now,
with the parallel support in order, I hope.
francesco

On Fri, Apr 3, 2009 at 7:04 PM, John Hearns  wrote:
> 2009/4/3 Francesco Pietra :
>> I was not sure whether that is a technically correct procedure. It works. 
>> Thanks
>>
>
> It most certainly is not. But I have been a Unix system admin for many
> years. I have done things which I am
> not proud of
> If I ever offer to let you use my keyboard, wash your hands afterwards.
> ___
> users mailing list
> us...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/users
>