This will be list of issues that I found while creating the shore-storage-manager-devel package. Everything that I talk about could be found in the srpm at . That srpm was built in my system and it contains all the patches and build calls necessary to to build in f13. I have tested the build process in RHEL and only minor modifications are needed.
Installation directory specification
Generally, to create the rpm package, one needs to tell the process to install the package into a dummy directory. After having all the files “installed” in the dummy dir, one can put them where one wants the in the system with %file.
When the rpmbuild got to the %install, it exploded telling me that it could access /usr/include because it did not have permissions. I wondered for some time why the using the DESTDIR argument to `make install` did not specify the destination directory correctly. I followed it to the Makefile.am in the src directory. There I had to add a the DESTDIR variable to each line that contained the header directory in order for it to work properly. In this way, if one specifies DESTDIR, /usr/include will be in DESTDIR/usr/include. The file named shore-storage-manager-6.0.1-Beta-builddir.patch contains what I did to solve this issue.
Do not distribute Makefile nor configure
I noticed that the src tarball  contained the Makefiles and the configure file. These files are system dependent and should not be distributed with the source. They should be created with autotools commands. I discovered this while trying to solve the problem above. When I looked for places where the string “includedir”, the ack command spit out a bunch of Makefiles, which seemed to me very strange since I had not run ./bootstrap nor ./configure.
The fix for this issue is simple to erase all the Makefiles from all the subdirectories in the sources. The diff itself looks very big, but the only thing i did was “rm -rfv `find .|grep Makefile`”. Additional from that we need to make sure to call ./boostrap and ./configure in the spec file.
I’ve talked with the person in charge of the tarball and she told me that the Makefiles and configure file were in the src because they wanted to avoid problems with the use of autotools. I think making people’s life easier is always good. But in this case I think that the tools are being misused. I have suggested the creation of packages for RHEL and Solaris. Unfortunately I do not know how to create a Solaris package so I can’t be much help there. I’m pretty confident that the spec file contained in  can be used to create a package for RHEL.
Some casting issue.
After getting everything packaged I moved to installing the package on my system (levono w500, 2 cores) and it began to scream again when I compiled a file that contained a “#include “. I looked at the error message and it seems that there is an issue when doing a cast from unsigned long long int* to uint64_t*. I googled it a bit and found nothing similar to my situation. I decided to do an explicit cast and it seem to put my compiler at easy (gcc-c++-4.4.4-10.fc13.x86_64).
whether the compiler is right or wrong in erroring out for this issue is one question. But regardless of that fact, shore should be consistent with the use of uint64_t. IMO, it should replace all the unsigned long long int with uint64_t. This fix is contained in the file named shore-storage-manager-6.0.1-Beta-uint64.patch
Crash in the /usr/include directory
In my system the package that contains the glibc headers (glibc-headers-2.12-3.x86_64) contained a file named regex.h. When I went to install the shore rpm in my system there was a header crash and the package was not installed. I chose to solve it in the short and ugly way: I renamed shore’s regex.h file to shore_regex.h. There was not a lot of changes that needed to be done but this exposes another issue that should be addressed. Shore is basically a library and its contents is header files and the library generated. There are 185 header files related to shore and they are all placed in the /usr/include directory by default. IMO it would be much cleaner to put everything in a directory called shore and change the include lines from “#include something” to “#include shore/something” (But that’s just me).
I’m guessing that there could be something else that could be done in the build that would prevent the crash and, at the same time, be a “cleaner” solution to the problem. But, as I said, I chose the ugly easy way out :).
Multiple library files
After building shore one ends up with 5 libraries (libatomic_ops.a, libcommon.a, libfc.a, libsm.a, libsthread.a). These libraries depend on each other. For example libsthread depends on libfc. I find it better to have just one generated library called shore (or something more specific). After talking with the person in charge I was told that there was a way to create a single library with some configure or make argument. But that it will be included in the next version.
For now I’m building everything with 3 or 4 -l options. One for every library that is needed in a specific situation. http://www.itu.dk/people/jogr/shore/  http://www.cs.wisc.edu/~nhall/shore-mt/releases/shore-storage-manager-6.0.1-Beta.tar.bz2