[Ocfs2-devel] libdlm_lt.so vs. libdlm_lt.so.3

[Ocfs2-devel] libdlm_lt.so vs. libdlm_lt.so.3

[Patrick J. LoPresti]

I have spent the weekend assembling a small OCFS2 cluster, under the
Pacemaker cluster stack, using nothing but Debian experimental
packages.

I found a few problems along the way -- and I have reported them as
bugs to the Debian maintainers -- but I do have it all working now.

The final problem I encountered was this one:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=587287

Briefly, mkfs.ocfs2 was bombing out with "Unable to access cluster
service while initializing the dlm".  This ultimately comes from lines
716-720 in ocfs2-tools-1.4.4/libo2dlm/o2dlm.c:

        ctxt->ct_lib_handle = dlopen("libdlm_lt.so",
                                     RTLD_NOW | RTLD_LOCAL);
        if (!ctxt->ct_lib_handle)
                goto out;

On Debian, ".so" symlinks are included in development ("-dev")
packages, not in production packages.  This is because they are
normally only used at compile time, not at run time; the compiler
always includes the major number for the dependency in the executable.
 (To see what I mean, run "ldd" on just about any executable; you will
find lots of dependencies on libfoo.so.N, but none on libfoo.so.)

I could submit this as a bug against the Debian redhat-cluster
package, asking them to move the libdlm_lt.so symlink from the
libdlm-dev package to the libdlm3 package.  But I do not actually
think that would be correct.  Just as "ldd /bin/cat" shows how cat
depends on libc.so.6 (not libc.so), in point of fact libo2dlm depends
on a particular major version of the libdlm_lt.so shared object (i.e.,
a particular major version of the binary API).

So, if I submit a patch changing the dlopen() in o2dlm.c to load
"libdlm_lt.so.3" instead of "libdlm_lt.so", will the OCFS2 maintainers
accept it?  If not, why not?

Thank you.

 - Pat

[Ocfs2-devel] libdlm_lt.so vs. libdlm_lt.so.3

[Coly Li]

On 06/28/2010 04:33 AM, Patrick J. LoPresti Wrote:
> I have spent the weekend assembling a small OCFS2 cluster, under the
> Pacemaker cluster stack, using nothing but Debian experimental
> packages.
> 
> I found a few problems along the way -- and I have reported them as
> bugs to the Debian maintainers -- but I do have it all working now.
> 
> The final problem I encountered was this one:
> 
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=587287
> 
> Briefly, mkfs.ocfs2 was bombing out with "Unable to access cluster
> service while initializing the dlm".  This ultimately comes from lines
> 716-720 in ocfs2-tools-1.4.4/libo2dlm/o2dlm.c:
> 
>         ctxt->ct_lib_handle = dlopen("libdlm_lt.so",
>                                      RTLD_NOW | RTLD_LOCAL);
>         if (!ctxt->ct_lib_handle)
>                 goto out;
> 
> On Debian, ".so" symlinks are included in development ("-dev")
> packages, not in production packages.  This is because they are
> normally only used at compile time, not at run time; the compiler
> always includes the major number for the dependency in the executable.
>  (To see what I mean, run "ldd" on just about any executable; you will
> find lots of dependencies on libfoo.so.N, but none on libfoo.so.)
> 
> I could submit this as a bug against the Debian redhat-cluster
> package, asking them to move the libdlm_lt.so symlink from the
> libdlm-dev package to the libdlm3 package.  But I do not actually
> think that would be correct.  Just as "ldd /bin/cat" shows how cat
> depends on libc.so.6 (not libc.so), in point of fact libo2dlm depends
> on a particular major version of the libdlm_lt.so shared object (i.e.,
> a particular major version of the binary API).
> 
> So, if I submit a patch changing the dlopen() in o2dlm.c to load
> "libdlm_lt.so.3" instead of "libdlm_lt.so", will the OCFS2 maintainers
> accept it?  If not, why not?

A similar patch has been in SLES11 HAE SP1 for a while (novell bugzilla bnc#543119), which is not upstream yet. FYI.

diff -rup ocfs2-tools.orig//libo2dlm/o2dlm.c ocfs2-tools/libo2dlm/o2dlm.c
--- ocfs2-tools.orig//libo2dlm/o2dlm.c  2008-10-27 01:10:50.000000000 +0800
+++ ocfs2-tools/libo2dlm/o2dlm.c        2009-11-03 16:49:38.000000000 +0800
@@ -713,7 +713,7 @@ static errcode_t load_fsdlm(struct o2dlm
                goto out;
        }

-       ctxt->ct_lib_handle = dlopen("libdlm_lt.so",
+       ctxt->ct_lib_handle = dlopen("libdlm_lt.so.3",
                                     RTLD_NOW | RTLD_LOCAL);
        if (!ctxt->ct_lib_handle)
                goto out;


-- 
Coly Li