[openib-general] [Bug 146] OFED-1.0 DAPL fails to build on SLES10 on IA64 with IA64_FETCHADD error

John Partridge johnip at sgi.com
Wed Jul 12 09:35:27 PDT 2006


James Lentini wrote:
> 
> On Tue, 11 Jul 2006, John Partridge wrote:
> 
> 
>>The resulting build from your last patch has been installed and we 
>>are in the process of DAPL tests now. I do know that the libdat 
>>works with Intel MPI (although we had to manually create a symlink 
>>from libdat.so.1 to libdat.so - should this not already exist?)
> 
> 
> Did you install dapl rpm or dapl-devel rpm? The dapl rpm should have 
> libdat.so.1 inside it.

I installed the dapl rpm. I do have libdat.so.1 but I also expect a
symlink to libdat.so which does not exist (Intel MPI appears to need it)

I also noticed that the dat.conf points to
/usr/local/ofed/lib/libdaplcma.so but there is no symlink in the
/usr/local/ofed/lib directory for it, I do have the libdaplcma.so.1
am I missing something here ?

It's not a huge problem one can always create a symlink, but I'm just
concerned I have something messed in my rpm.

> 
> 
>>I do have one question about how the dapl RPM's are organized, we are
>>creating a DAPL interface for the ccNUMA xpmem on SGI Altix systems.
>>At the moment we have a libdat and libdapl(xpmem). It is our objective
>>to use the OFED-1.0 libdat, as libdat will be used for non-infiniband
>>interfaces I don't quite understand why libdat (dat.conf) are not a
>>separate RPM and the libdapl interfaces installed in a separate RPM ?
>>Would his not make more sense ?
> 
> 
> The DAPL provider library can have an arbitrary name. You should name 
> your DAPL provider something unique (e.g. libdaplxpmem).

OK that makes sense, but my point was should the libdat be a seperate
rpm from the libdapl libs ?

Thanks
John


-- 
John Partridge

Silicon Graphics Inc
Tel:	651-683-3428
Vnet:	233-3428
E-Mail:	johnip at sgi.com




More information about the general mailing list