Bug 191722
Description
n0dalus
2006-05-15 14:18:19 UTC
Created attachment 129063 [details]
Build log
Error from the build log: cc -g -O -Wall `pkg-config --cflags glib-2.0` -Wall -D_FILE_OFFSET_BITS=64 -c -o diskdump_format.o diskdump_format.c diskdump_format.c:36:24: error: linux/swap.h: No such file or directory diskdump_format.c: In function 'device_is_swap': diskdump_format.c:513: error: dereferencing pointer to incomplete type diskdump_format.c:515: error: dereferencing pointer to incomplete type make: *** [diskdump_format.o] Error 1 /usr/include/linux/swap.h used to be part of the glibc-kernheaders package, so I thought that it would only take a "BuildRequires: glibc-kernheaders" to the diskdumputils.spec file to address the build problem. However, after trying that in the devel tree, the same error occurs. Upon further inspection, it looks like swap.h no longer is part of the latest glibc-kernheaders-3.0-32 package, whereas it used to be as recently as version 3.0-2. Perhaps it got dropped here: * Wed Apr 26 2006 David Woodhouse <dwmw2> 3.0-8 - Updated tarball from 'make headers_install' from 2.6.16-1.2166_FC6 This should match the contents of the 'kernel-headers' subpackage of the kernel, if I was brave enough to actually switch over to that for real. Let's just test it this way for now though... Anyway, I was just trying to be helpful, but at this point I have no idea what package contains swap.h. Note: I do understand that swap.h can be found in the kernel-devel package, but how would a user-package reference it? For example, the latest FC6 x86_64 kernel-devel-2.6.16-1.2204_FC6.x86_64.rpm package contains swap.h here: ./usr/src/kernels/2.6.16-1.2204_FC6-x86_64/include/linux/swap.h but how could a user package express the #include line? (In reply to comment #3) > Note: I do understand that swap.h can be found in the kernel-devel package, > but how would a user-package reference it? You don't. It's a _KERNEL_ header. Finding it in the kernel-devel package should be a big shouty warning to you that it's _NOT_ for you to use in userspace. In particular, swap.h contains structure with a dependency on PAGE_SIZE, which isn't even a constant -- it's system-dependent and has to be obtained with sysconf(3). I've committed a fix for this; diskdumputils-1.3.6-kernheaders.patch -- please review it and build a package. I also had to do diskdumputils-1.3.6-ppc.patch so that it would build on my test box; please review that too. I've also fixed the BuildRequires for glibc-kernheaders. That package name should never be used -- it provides kernel-headers, and is likely to disappear in favour of that package again some time soon. > I've committed a fix for this; diskdumputils-1.3.6-kernheaders.patch -- please > review it and build a package. I also had to do diskdumputils-1.3.6-ppc.patch > so that it would build on my test box; please review that too. Thanks Dave! I wasn't really trolling for a fix, but just trying to get an idea for what the Fujitsu team could do with their package if/when Brew is ever used for RHEL3 and RHEL4. Even though the Fujitsu guys are embedded in Westford, they cannot access CVS, do errata, etc., so I'm just a "proxy" maintainer. To the Fujitsu team: If you missed this, the QA group is validating all Fedora packages for proper BuildRequires usage in package spec files: http://post-office.corp.redhat.com/archives/os-devel-list/2006-May/msg00105.html Even though diskdumputils is not supported in Fedora, if the Beehive build system is replaced by Brew for future builds of RHEL3 and RHEL4, the build issue would have to be addressed. Can you guys verify the two patch files made by Dave Woodhouse, and fold them into future upstream packages? The two patches can be found in: porkchop:/home/boston/anderson/diskdumputils/devel And thanks again, Dave. Actually, this error wasn't really anything to do with the BuildRequires: effort -- it was just coincidence that this was the first time the diskdumputils package was built after the kernel-headers package got changed. The real problem is that <linux/swap.h> just isn't suitable for use in userspace now that PAGE_SIZE really is variable -- which is why I've done that part differently. The patch to support PPC32 was partly just so that I could get to the real problem on my laptop -- and partly because I object to the existence of _any_ package which doesn't build for PPC32. If we do start building for ppc32 in Fedora (and I think we should), then we may need some special installer magic to make sure the PPC64 version gets included for PPC64 machines -- like we do for gdb and the kernel. We don't want to end up installing the ppc32 version on 64-bit machines. Hi Dave, The ppc package won't build: ... echo "#define CMD_VERSION \"1.3.6\"" > version.h cc -g -O -Wall -Wall -D_FILE_OFFSET_BITS=64 -c -o diskdumpctl_proc.o diskdumpctl_proc.c cc -g -O -Wall -Wall -D_FILE_OFFSET_BITS=64 -c -o diskdumpcmn.o diskdumpcmn.c cc -o diskdumpctl_proc diskdumpctl_proc.o diskdumpcmn.o cc -g -O -Wall -Wall -D_FILE_OFFSET_BITS=64 -c -o savecore.o savecore.c savecore.c: In function 'main': savecore.c:539: warning: 'data[1]' may be used uninitialized in this function cc -g -O -Wall -Wall -D_FILE_OFFSET_BITS=64 -c -o elf.o elf.c cc -g -O -Wall -Wall -D_FILE_OFFSET_BITS=64 -c -o ppc/elf.o ppc/elf.c cc -g -O -Wall -Wall -D_FILE_OFFSET_BITS=64 -c -o dumpfile.o dumpfile.c if [ -d /usr/lib64 ]; \ then cc -o savecore savecore.o dumpfile.o elf.o ppc/elf.o diskdumpcmn.o /usr/lib64/libz.a ; \ else cc -o savecore savecore.o dumpfile.o elf.o ppc/elf.o diskdumpcmn.o /usr/lib/libz.a ; fi cc: /usr/lib64/libz.a: No such file or directory make: *** [savecore] Error 1 error: Bad exit status from /usr/src/build/751299-ppc/install-tmp/rpm-tmp.91285 (%build) Checking for the existence of /usr/lib64 isn't the best way to decide whether to use it. Why shouldn't we be allowed to build for 32-bit on a 64-bit machine. Use %{_libdir} in the RPM specfile instead. We should also be using $RPM_OPT_FLAGS. I'll attach a patch which starts this but still needs LDFLAGS to be set -- sorry, got to run. Created attachment 129430 [details]
patch
With added diskdumputils-1.3.6-libdir.patch and modified diskdumputils.spec file the build worked -- logs to be attached... Created attachment 129437 [details]
diskdumputils-751312-i386-hs20-bc1-1.build.redhat.com.log
Created attachment 129439 [details]
diskdumputils-751312-ia64-bullwinkle.build.redhat.com.log
Created attachment 129441 [details]
diskdumputils-751312-ppc-js20-bc1-11.build.redhat.com.log
Created attachment 129442 [details]
diskdumputils-751312-ppc64-js20-bc1-10.build.redhat.com.log
Created attachment 129443 [details]
diskdumputils-751312-x86_64-hs20-bc1-2.build.redhat.com.log
Created attachment 129447 [details]
diskdumputils-751312-i386-hs20-bc1-1.build.redhat.com.log
Created attachment 129448 [details]
diskdumputils-751312-ia64-bullwinkle.build.redhat.com.log
Created attachment 129449 [details]
diskdumputils-751312-ppc-js20-bc1-11.build.redhat.com.log
Created attachment 129450 [details]
diskdumputils-751312-ppc64-js20-bc1-10.build.redhat.com.log
Created attachment 129451 [details]
diskdumputils-751312-x86_64-hs20-bc1-2.build.redhat.com.log
> the build worked -- logs to be attached...
Sorry about that -- I thought "auto-detect" would figure out that the logs
were plain text.
Don't forget the build system magic. You don't want to ship ppc32 diskdumputils on ppc64 machines. This package is not even supported in Fedora. The only reason I got involved is just in case the same type of build issues were ever to raise their heads in a future RHEL3 or RHEL4 errata, i.e., if Brew replaces Beehive there. (I'm presuming that's going to happen?) Anyway, in RHEL3 and RHEL4, ppc will *never* make it into the ExclusiveArch lineup. That's assuming you deliberately change it and rebuild for RHEL5, instead of the Fedora packages just getting inherited into the RHEL5 tree. Better to fix it properly and never worry about it again -- and better for it to _work_ in Fedora too. Diskdump (and netdump) are being phased out in RHEL5, to be replaced by kexec/kdump. Also, there has never been *kernel* diskdump support the ppc platform, so a ppc32 diskdumputils package has nobody to talk to. |