I took the 2.6.0 ebuild made by Donnie Berkholz and fixed all the problems I found (I explained them in the ebuild), and I added init.d and conf.d scripts. I know that my fixes could be improved but they work. If anyone find a better way of doing this, please reply. Now it compiles and runs on amd64. The ebuild also uses the patches http://bugs.gentoo.org/attachment.cgi?id=103783 and the pvfs2-1.5.1-destdir.patch found in the portage tree Reproducible: Always
Created attachment 116286 [details] pvfs2-2.6.3.ebuild
Created attachment 116287 [details, diff] 2.6.3-soname.patch
Created attachment 116288 [details] pvfs2-server.rc
Created attachment 116290 [details] pvfs2-server.conf
Does this with LDFLAGS="-Wl,--as-needed"?
Well, my LDFLAGS are empty so I never thought about it. I hadn't written the src_compile() function so it was using the default linux-mod_src_compile() in /usr/portage/eclass/linux-mod.eclass , and it uses get_abi_LDFLAGS to pass your LDFLAGS to emake. That means emake only knew the ldflags of your profile. I made a new ebuild and a patch, and now it's working with LDFLAGS="-Wl,--as-needed". After testing the installation I don't find any runtime errors. For simplicity I uploaded your patch and the other one. Anyone interested in --as-needed might want to take a look at http://www.gentoo.org/proj/en/qa/asneeded.xml ,as that flag can give you some nasty problems Hope it helps!
Created attachment 116371 [details] pvfs2-2.6.3.ebuild
Created attachment 116372 [details, diff] 2.6.3-as-needed.patch
Created attachment 116373 [details, diff] 2.6.3-link-librt-properly.patch
Created attachment 116374 [details, diff] pvfs2-1.5.1-destdir.patch
(In reply to comment #11) > Does this with LDFLAGS="-Wl,--as-needed"? > Yes
*** Bug 141635 has been marked as a duplicate of this bug. ***
Created attachment 117745 [details, diff] 2.6.3-no-pointer-sign.patch -Patch for gcc < 4.0 kernel.m4 had -Wno-pointer-sign, which was not recognized by gcc. The test failed, a feature was disabled in pvfs2-config.h and the compilation crashed
Created attachment 117746 [details, diff] 2.6.3-register_sysctl_table.patch -Patch for kernel > 2.6.20 The function register_sysctl_table in kernel/sysctl.c now has 1 argument instead of 2 I also tested the gtk flag, it works
Created attachment 117747 [details] pvfs2-2.6.3.ebuild Tested on x86 and amd64, with and without -Wl,--as-needed
Created attachment 123060 [details, diff] pvfs2-2.6.3.ebuild.patch Wouldn't build for me on ppc64 until I made the above modifications. I added two lines to patch the Makefile.in to allow the required userland tools assoiciated with the module to be installed separately from the module. Then I was able to allow linux-mod to deal with all of the module stuff. For reference the errors I was seeing were: powerpc64-unknown-linux-gnu-gcc -D__GEN_POSIX_LOCKING__ -D__PVFS2_CLIENT__ -I./include -O2 -pipe -mcpu=G5 -maltivec -mabi=altivec -ftree-vectorize -D__PVFS2_USE_EPOLL__ -DGOSSIP_ENABLE_BACKTRACE -D__STATIC_METHOD_BMI_TCP__ -D__STATIC_FLOWPROTO_MULTIQUEUE__ -D_FILE_OFFSET_BITS=64 -D_LARGEFILE64_SOURCE -I . -I . -I./src/client/sysint -I./src/common/misc -I./src/common/quickhash -I./src/common/quicklist -I./src/common/id-generator -I./src/common/gossip -I./src/common/gen-locks -I./src/io/trove -I./src/io/bmi -I./src/io/description -I./src/io/buffer -I./src/io/job -I./src/io/dev -I./src/proto -DPVFS2_VERSION="\"2.6.3\"" -DUSE_MMAP_RA_CACHE -pipe -Wall -Wstrict-prototypes -fPIC -I./src/common/misc src/common/misc/server-config-mgr.c -c -o src/common/misc/server-config-mgr.po LD [M] /var/tmp/portage/sys-cluster/pvfs2-2.6.3/work/pvfs-2.6.3/src/kernel/linux-2.6/pvfs2.o ld: unrecognized option '-Wl,-O1' ld: use the --help option for usage information
Created attachment 123180 [details] pvfs2-2.6.3.ebuild (must be patched with Justin Bronder's patch) Thank you very much for your patch. It's working on x86 and amd64, however I found 2 problems which I fixed with the new ebuild (it's my last ebulid + your patch + my fix) **Problems: -I didn't like my previous AM_LDFLAGS hack (search "#This fixes the Makefile LDFLAGS being overriden by the LDFLAGS used by emake" in the old ebuild) -After your patch, make.conf LDFLAGS was not used to build kernapps (--as-needed was requested but with this patch it was just ignored) **Details: -About AM_LDFLAGS: At first I was not using src_compile(). When you do that linux-mod_src_compile is used automatically. linux-mod_src_compile calls emake with your profile LDFLAGS, ignoring make.conf LDFLAGS. Then I added src_compile() and I didn't notice the "LDFLAGS += @LDFLAGS@" in makefile.in. I didn't want the original LDFLAGS = -L @BUILD_ABSOLUTE_TOP@/lib to be overwritten with your custom LDFLAGS, so i renamed LDFLAGS to AM_LDFLAGS with that hack. After that I called emake with LDFLAGS variable. It was working, life was nice. However with your patch I found out my ebuild was working without the hack, and yours was not. The problem was the call to linux-mod_src_compile. As I said, it uses your profile LDFLAGS. That overwrites the makefile.in. The purpose of that call is building a module, but instead of that the makefile also builds kernapps with it. kernapps needs makefile.in LDFLAGS to be linked properly, and without AM_LDFLAGS hack, it crashes. Fix? changing BUILD_TARGETS="kmod" to BUILD_TARGETS="just_kmod" and adding emake kernapps. This way we can remove the ugly hack and it will work. makefile.in LDFLAGS are overwritten when you build the module, yes, but it doesn't need them anyway. This also fixes the next problem. -About make.conf LDFLAGS As kernapps was being built by linux-mod_src_compile, your custom LDFLAGS was overriden, and things like "--as-needed" requested by Donnie Berkholz, were not used when compiling kernapps. The previous fix makes it possible to build this with emake, preserving our custom LDFLAGS. **Result: No AM_LDFLAGS hack and custom LDFLAGS for everything. Please tell me if it's working on ppc64 and if you find any problem don't hesitate to modify the ebuild.
Created attachment 123191 [details, diff] pvfs2-2.6.3.ebuild.patch pvfs2-client and the module work for me with the new ebuild. The patch just takes out the ARCH setting which I believe isn't necessary when using linux-mod, and adds some init/conf scripts for pvfs2-client.
Created attachment 123192 [details] pvfs2-client.conf
Created attachment 123194 [details] pvfs2-client-init.d
Created attachment 123195 [details] pvfs2-server.rc A small enhancement to the original pvfs2-server.rc, this will optionally make sure that pvfs2-server continues to run, and if not, rebuild the local pvfs2 filesystem with pvfs2-server --mkfs.
Created attachment 123197 [details] pvfs2-server.conf
Both init scripts have small stylistic issues - please use a single tab for indentation pvfs2-client init.d: [ -n "$(lsmod | egrep '^pvfs2 ')" ] || modprobe pvfs2 It would be a little nicer to do this by asking egrep to be silent, and by checking the return value which indicates match or no-match. Also, I have no specific issues but modprobe in an init script is always slightly scary territory... Is it required for the daemon to launch? and if so, does it not try to load it itself? I can understand it being required by the mount, but I think mount -t pvfs2 would cause mount to attempt to load the module. Running umount and "modprobe -r" in the stop() section is also a little scary. I don't know anything about this filesystem but the concept here seems a little odd too -- an init script for a single mount. Are there no situations when someone would want to create 2 mounts? If a single mount does go hand-in-hand with the daemon, it seems a little odd that the daemon wouldn't take care of it for you.
Created attachment 132528 [details] Updated 2.6.3 ebuild We have included one more fix for kernels >= 2.6.22, enjoy. If no objections arise, i will include this ebuild into the tree this evening.
Created attachment 132530 [details, diff] Kmem patch Patch for updated 2.6.3 ebuild
Daniel: we just tried it - the daemon requires you to (1) load the module (2) start the client (3) mount PITA, but w/o further study of the code - not possible to let mount modprobe the pvfs2 module :( However i've changed the init.d script to egrep "^pvfs2" &> /dev/null.
I've comitted the 2.6.3 ebuild i attached with some minor quoting and whitespace fixes. I expect to be shot or torn into pieces either here or on -dev if something went wrong ;)
