[2013-10-08 17:33:36.662549] I [glusterfsd.c:1910:main] 0-/usr/sbin/glusterd: Started running /usr/sbin/glusterd version 3.4.1 (/usr/sbin/glusterd --debug)
...
[2013-10-08 17:33:36.664191] W [xlator.c:185:xlator_dynload] 0-xlator: /usr/lib64/glusterfs/3.4.0/xlator/mgmt/glusterd.so: cannot open shared object file: No such file or directory
I think the issue can be summarized with the above two log lines. glusterd binary is version 3.4.1 (PACKAGE_VERSION of glusterfsd is "3.4.1") but libglusterfs is trying to open ".../3.4.0/...glusterd.so" (i.e PACKAGE_VERSION during build of libglusterfs.so is "3.4.0").
The reality in code today is that glusterfsd and libglusterfs must be built from the same version of the source tree (for reasons like above), and this needs to be captured in the packaging.
I see that the glusterfs.spec.in in glusterfs.git has:
Requires: %{name}-libs = %{version}-%{release}
for the glusterfs-server RPM. That should have forced your glusterfs-libs to be updated to 3.4.1 as well.
Kaleb,
Can you confirm that the Fedora RPMs also have this "internal dependency" between packages? If it already does, I'm not sure how Jeff ended up with:
glusterfs-libs-3.4.0-8.fc19.x86_64
glusterfs-3.4.1-1.fc19.x86_64
without doing a --force and/or --nodeps install.
Avati
