From: Coly Li <i@coly.li>
To: ocfs2-devel@oss.oracle.com
Subject: [Ocfs2-devel] libdlm_lt.so vs. libdlm_lt.so.3
Date: Mon, 28 Jun 2010 12:02:18 +0800 [thread overview]
Message-ID: <4C281ECA.1010207@coly.li> (raw)
In-Reply-To: <AANLkTilaQlW3H_24fwrKbMHrBhk-rWv7_4jWr12e4RzL@mail.gmail.com>
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
prev parent reply other threads:[~2010-06-28 4:02 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-06-27 20:33 [Ocfs2-devel] libdlm_lt.so vs. libdlm_lt.so.3 Patrick J. LoPresti
2010-06-28 4:02 ` Coly Li [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4C281ECA.1010207@coly.li \
--to=i@coly.li \
--cc=ocfs2-devel@oss.oracle.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.