FTBFS in latest archive rebuild test

https://lists.ubuntu.com/archives/ubuntu-autotest/2007-December/000030.html
Automatic build of palo_1.16build1 on king by sbuild/amd64 1.170.5

cd palo && make
make[2]: Entering directory `/build/buildd/palo-1.16build1/palo'
gcc -g -O -I../include -I../lib -c -o diskpart.o ../lib/diskpart.c
gcc -g -O -I../include -I../lib -c -o elf64.o ../lib/elf64.c
In file included from ../lib/elf64.c:20:
/usr/include/linux/elf.h:396: error: expected declaration specifiers or '...' before 'loff_t'
make[2]: *** [elf64.o] Error 1
make[2]: Leaving directory `/build/buildd/palo-1.16build1/palo'
make[1]: *** [makepalo] Error 2
make[1]: Leaving directory `/build/buildd/palo-1.16build1'
make: *** [build-stamp] Error 2
dpkg-buildpackage: failure: debian/rules build gave error exit status 2

https://lists.ubuntu.com/archives/ubuntu-autotest/2007-December/000034.html
Automatic build of palo_1.16build1 on terranova by sbuild/i386 1.170.5

cd palo && make
make[2]: Entering directory `/build/buildd/palo-1.16build1/palo'
gcc -g -O -I../include -I../lib -c -o diskpart.o ../lib/diskpart.c
gcc -g -O -I../include -I../lib -c -o elf64.o ../lib/elf64.c
In file included from ../lib/elf64.c:20:
/usr/include/linux/elf.h:396: error: expected declaration specifiers or '...' before 'loff_t'
make[2]: *** [elf64.o] Error 1
make[2]: Leaving directory `/build/buildd/palo-1.16build1/palo'
make[1]: *** [makepalo] Error 2
make[1]: Leaving directory `/build/buildd/palo-1.16build1'
make: *** [build-stamp] Error 2
dpkg-buildpackage: failure: debian/rules build gave error exit status 2

new ->confirmed

I think this is a bug in linux-libc-dev, not in palo. The linux-libc-dev -provided /usr/include/linux/elf.h declares functions that take an loff_t * as an argument, and loff_t is defined in /usr/include/linux/types.h *only* when __KERNEL_STRICT_NAMES is undefined. But __KERNEL_STRICT_NAMES must be defined for palo to avoid conflicts with other userspace type definitions. linux/elf.h should be usable even when __KERNEL_STRICT_NAMES is set; loff_t should be replaced with __kernel_loff_t in this header.

As a workaround for palo though, palo can include the userspace sys/types.h before linux/elf.h.

I think this needs to be checked further. It may be perfectly acceptable for linux/elf.h to use loff_t. It is also strictly correct that sys/types.h is needed when loff_t is needed to be defined. So the bug may just be that linux/elf.h needs to include sys/types.h when __KERNEL_STRICT_NAMES is defined. I believe this define is set when -ansi is used.

Actually, the bug here may just be that elf64.c needs to include <elf.h> and not <linux/elf.h>

Since this has a work around for palo and whether and which change could be made for the kernel is rather open, I mark this won't fix for Hardy.

Steve, since you have a workaround, could you upload that?

Preparing an upload of palo with the workaround. BTW, elf.h is not a usable substitute for linux/elf.h, because:

gcc -g -O -I../include -I../lib -c -o elf64.o ../lib/elf64.c
../lib/elf64.c: In function 'prepare_ELF64_loadable':
../lib/elf64.c:51: error: storage size of 'eh' isn't known
../lib/elf64.c:81: error: storage size of 'ep' isn't known
make[2]: *** [elf64.o] Error 1

It's still not correct for linux/elf.h to use loff_t. Well, for all I imagine any consumers of the published header are concerned, elf_coredump_extra_notes_*() may not need to be defined at all, so /that/ may be the real bug - but in any case there's no reason that all of a sudden users of linux/elf.h should have to pre-include sys/types.h, linux-libc-dev headers really oughtn't depend on type definitions from glibc...

This bug was fixed in the package palo - 1.16ubuntu1

---------------
palo (1.16ubuntu1) hardy; urgency=low

  * Include <sys/types.h> before <linux/elf.h>, to work around type
    issues in linux-libc-dev. LP: #184216.
  * Modify Maintainer value to match the DebianMaintainerField
    specification.

 -- Steve Langasek <email address hidden> Wed, 02 Apr 2008 08:24:17 +0000

The Ubuntu Kernel Team is planning to move to the 2.6.27 kernel for the upcoming Intrepid Ibex 8.10 release. As a result, the kernel team would appreciate it if you could please test this newer 2.6.27 Ubuntu kernel. There are one of two ways you should be able to test:

1) If you are comfortable installing packages on your own, the linux-image-2.6.27-* package is currently available for you to install and test.

--or--

2) The upcoming Alpha5 for Intrepid Ibex 8.10 will contain this newer 2.6.27 Ubuntu kernel. Alpha5 is set to be released Thursday Sept 4. Please watch http://www.ubuntu.com/testing for Alpha5 to be announced. You should then be able to test via a LiveCD.

Please let us know immediately if this newer 2.6.27 kernel resolves the bug reported here or if the issue remains. More importantly, please open a new bug report for each new bug/regression introduced by the 2.6.27 kernel and tag the bug report with 'linux-2.6.27'. Also, please specifically note if the issue does or does not appear in the 2.6.26 kernel. Thanks again, we really appreicate your help and feedback.

Per a decision made by the Ubuntu Kernel Team, bugs will longer be assigned to the ubuntu-kernel-team in Launchpad as part of the bug triage process. The ubuntu-kernel-team is being unassigned from this bug report. Refer to https://wiki.ubuntu.com/KernelTeamBugPolicies for more information. Thanks.

This bug report is being closed because we received no response to the previous inquiry for information. Please reopen if this is still an issue in the current Ubuntu release, Jaunty Jackalope 9.04 - http://www.ubuntu.com/getubuntu/download. If the issue remains in Jaunty, please test the latest upstream kernel build - https://wiki.ubuntu.com/KernelMainlineBuilds . To reopen the bug, click on the current status under the Status column and change the status back to "New". Thanks.

That's inappropriate. All the information required to fix this bug is already here in the report.

I've checked linux/elf.h on karmic, and it appears that it no longer includes any references to loff_t; so marking this bug as fixed.