[ofa-general] Re: Dapl 2 question/issue

[Doug Ledford]

On Tue, 2008-01-29 at 13:46 -0800, Arlin Davis wrote:
> Doug Ledford wrote:
> > 
> > You *should* be claiming that regardless.  The API between dapl-1 and
> > dapl-2 changed, some of which is fixed simply be recompiling and some of
> > which requires actual code changes.  Just because the library name is
> > the same doesn't mean that code built and compiled against dapl-1 could
> > or should attempt to run against dapl-2 (unless I'm wrong here, Arlin
> > should really speak to this issue...if the dapl-2 libraries provide
> > backward compatible symbols via so symbol versions, then it might be
> > possible for a dapl-1 program to run against the dapl-2 library, but
> > then that would beg the question of why we are still distributing dapl-1
> > libraries in a separate package, so I'm guessing there is not a back
> > compatible layer in the dapl-2 library).
> 
> You are correct. dapl-1 programs cannot run against dapl-2. That is why 
> both v1 and v2 packages are provided. We have to support existing v1 
> applications while providing a transition path to v2.

OK, then that brings us back around to what I said earlier, which is
that in order to be able to recompile any application that uses udapl
prior to that application being ported to dapl2, you have to be able to
install both devel environments.

After talking with some other engineers inside Red Hat, this is what I'm
going to be doing for our distribution.

I'll be building a devel environment for both dapl-1.2 and dapl-2.0.  I
won't need to change the library name for dapl-2.0, but I am going to
use a different directory for it's .so link.  Specifically, since source
code must be ported to dapl-2.0 (in the form of changing #include
<dat/dat.h> to dat2/dat.h in the source code), it would seem reasonable
to me that the code can also be ported to link to a library in a
different location (in this case, it will be %{_libdir}/dat/libdat.so,
so the LDFLAGS will need to be updated with -L%{_libdir}/dat -ldat in
order to get the new library).  So, in our setup, code that wants to
compile against the later dapl-2.0 library will need two changes (in
addition to the port itself) in order to compile.  All unported
applications will still compile and link against the dapl-1.2 libraries.
I'd be more than happy to send you guys the spec file I'm using to
accomplish this if you wish.

-- 
Doug Ledford <dledford at redhat.com>
              GPG KeyID: CFBFF194
              http://people.redhat.com/dledford

Infiniband specific RPMs available at
              http://people.redhat.com/dledford/Infiniband
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://lists.openfabrics.org/pipermail/general/attachments/20080129/6c9cf75e/attachment.sig>