Did not work the way I implemented the suggestion.
./configure CC=/..cce..icc CXX/. cce..icpc F77=/..fce..ifort
FC=/..fce..ifort --with-libnuma=/usr --prefix=/usr --enable-static
./configure CC=/..cce..icc CXX/. cce..icpc F77=/..fce..ifort
FC=/..fce..ifort --with-libnuma=/usr --prefix=/usr
then e
You could try statically linking the Intel-provided libraries. Use
LDFLAGS=-static-intel
--Nysal
On Wed, 2009-04-15 at 21:03 +0200, Francesco Pietra wrote:
> On Wed, Apr 15, 2009 at 8:39 PM, Prentice Bisbal wrote:
> > Francesco Pietra wrote:
> >> I used --with-libnuma=/usr since Prentice Bisbal
On Wed, Apr 15, 2009 at 8:39 PM, Prentice Bisbal wrote:
> Francesco Pietra wrote:
>> I used --with-libnuma=/usr since Prentice Bisbal's suggestion and it
>> worked. Unfortunately, I found no way to fix the failure in finding
>> libimf.so when compiling openmpi-1.3.1 with intels, as you have seen
>
Francesco Pietra wrote:
> I used --with-libnuma=/usr since Prentice Bisbal's suggestion and it
> worked. Unfortunately, I found no way to fix the failure in finding
> libimf.so when compiling openmpi-1.3.1 with intels, as you have seen
> in other e-mail from me. And gnu compilers (which work well w
I used --with-libnuma=/usr since Prentice Bisbal's suggestion and it
worked. Unfortunately, I found no way to fix the failure in finding
libimf.so when compiling openmpi-1.3.1 with intels, as you have seen
in other e-mail from me. And gnu compilers (which work well with both
openmpi and the slower
On Apr 6, 2009, at 4:24 PM, Prentice Bisbal wrote:
> I would appreciate help in circumventing the problem.
I believe you need
--with-libnuma=/usr.
Sorry for the late reply.
FWIW, the above is correct -- you should use --with-libnuma=/usr, not
--with-libnuma=/usr/lib.
Please also note
Francesco Pietra wrote:
> 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/bi
"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 i
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
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
>> "/u
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 (SLE
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/i
12 matches
Mail list logo
