[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [Linux-cluster] cluster-1.01.00



David Teigland a écrit :
A new source tarball from the STABLE branch has been released; it builds
and runs on 2.6.13:

I've been working on making a rpm of this tarball.
Now I have one main rpm which contains all the usuals binaries, one for
the librairies, one for the devel, one for the kernel module.
For the kernel modules, I choose to create a dkms rpm. This allow to not
provide a binary kernel module but a rpm which rebuilt the modules on
the target host.
This is very usefull, i.e dkms is just able to rebuild automatically the
gfs module if you reboot on another kernel. It doesn't needs any
user/admin helps.
This makes our lifes easiest. ;o)
You can find my specfile and the SRPMS at
http://www.seanodes.com/~erwan/SRPMS
This rpms have been tested successfully on the withebox 4 and mandriva
2006 & cooker.
The SRPMS is now included in mandriva repository, an "urpmi" is enough
to have a runnable gfs ;o)
This could be cool to integrate the specfile to the cvs tree.

Making a rpm of this tarball shows me several troubles:

1- The configure architecture doesn't allow to choose all options
I mean the main configure is calling a set of sub configure with the
same options to all of them.
Some "sub configure" accept additionnal options, like "--plugindir=" for
magma.
If I call the main configure with --plugindir it fails because the other
sub configure doesn't implement "--plugindir.
It could be better to ignore un-implemented options which prevent failures.

2-make dependencies
In my case, I'd like to separate the binary and the kernel module build.
This could allow me to build the rpm by just compiling the binary and
then provides the dkms rpm where the kernel modules are located. This
provides a faster build process.
Today, it seems we must make the kernel modules before the binaires else
you can't build the binairies.
Instead of having a "all:" target, it could be cool to have a
"binaries:" and a "kernel-modules:" targets.

Today, if my rpm building machine doesn't have a kernel source where the
make has been done I have
from /home/nis/guibo/rpm/BUILD/cluster-1.01.00/cman-kernel/src/cnxman.c:15:
   include/linux/config.h:4:28: error: linux/autoconf.h: No such file
or directory

3-soname troubles
I'm not an expert about this part but some binaires are linked with the
.so library whereas it should be with the .so.x.

ccsd is a good example:
[root max4 ~]# ldd /sbin/ccsd
   libxml2.so.2 => /usr/lib64/libxml2.so.2 (0x00002aaaaabc1000)
   libz.so.1 => /lib64/libz.so.1 (0x00002aaaaadd1000)
   libpthread.so.0 => /lib64/tls/libpthread.so.0 (0x00002aaaaaee6000)
   libm.so.6 => /lib64/tls/libm.so.6 (0x00002aaaaaffb000)
   libmagma.so => /usr/lib64/libmagma.so (0x00002aaaab153000)
   libmagmamsg.so => /usr/lib64/libmagmamsg.so (0x00002aaaab25b000)
   libdl.so.2 => /lib64/libdl.so.2 (0x00002aaaab35f000)
   libc.so.6 => /lib64/tls/libc.so.6 (0x00002aaaab462000)
   /lib64/ld-linux-x86-64.so.2 (0x00002aaaaaaab000)

I was told that binaries must be linked with .so.x because .so are only
for development. In the mandriva rpm's policy .so must be in
lib%name-devel rpms and .so.x in lib%name rpms. This error make it
impossible.

I don't know if its related or not but 3 librairies doesn't provides
enought informations to help rpm finding what they provides.
I've add a workaround to my spec file by defining
%ifarch x86_64
Provides:       libmagma.so()(64bit) libmagmamsg.so()(64bit)
libmagma_nt.so()(64bit)
%endif

-
Erwan Velu


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]