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 -- Linux-cluster@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/linux-cluster
