FTBFS in latest archive rebuild test

Bug #184216 reported by Adam Conrad on 2008-01-19
6
Affects Status Importance Assigned to Milestone
linux (Debian)
Fix Released
Unknown
linux (Ubuntu)
High
Unassigned
Hardy
High
Unassigned
palo (Debian)
Fix Released
Unknown
palo (Ubuntu)
High
Steve Langasek
Hardy
High
Steve Langasek

Bug Description

Binary package hint: palo

This package failed to build from source in a recent archive rebuild
test. The logs for the rebuild test can be found at:

https://lists.ubuntu.com/archives/ubuntu-autotest/2007-December/thread.html

Related branches

Adam Conrad (adconrad) on 2008-01-19
Changed in palo:
importance: Undecided → High
Caroline Ford (secretlondon) wrote :

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

Caroline Ford (secretlondon) wrote :

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

Caroline Ford (secretlondon) wrote :

new ->confirmed

Changed in palo:
status: New → Confirmed
Steve Langasek (vorlon) wrote :

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.

Changed in linux:
importance: Undecided → High
status: New → Confirmed
Changed in palo:
status: Unknown → New
Changed in linux:
assignee: nobody → ubuntu-kernel-team
status: Confirmed → Triaged
Ben Collins (ben-collins) wrote :

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.

Ben Collins (ben-collins) wrote :

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

Stefan Bader (smb) wrote :

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.

Changed in linux:
status: Triaged → Won't Fix
Colin Watson (cjwatson) wrote :

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

Changed in palo:
assignee: nobody → vorlon
Steve Langasek (vorlon) wrote :

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...

Launchpad Janitor (janitor) wrote :

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

Changed in palo:
status: Confirmed → Fix Released
Changed in linux:
status: Unknown → New

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.

Changed in palo:
status: New → Fix Released

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.

Bryan Wu (cooloney) wrote :

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.

Changed in linux (Ubuntu):
status: Triaged → Won't Fix
Steve Langasek (vorlon) wrote :

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

Changed in linux (Ubuntu):
status: Won't Fix → Triaged
Steve Langasek (vorlon) wrote :

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.

Changed in linux (Ubuntu):
status: Triaged → Fix Released
Changed in linux (Debian):
status: New → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.