[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