Ubuntu
libcap2 package

libcap2 FTBFS for lpia

Bug #375595 reported by Julien Lavergne
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
libcap2 (Fedora)
Fix Released
Medium
libcap2 (Ubuntu)
Fix Released
High
Colin Watson
Ubuntu karmic-alpha-3
linux (Ubuntu)
Invalid
High
Unassigned

Bug Description

Binary package hint: libcap2

libcap2 FTBFS for lpia on Karmic, see the build log : http://launchpadlibrarian.net/26640130/buildlog_ubuntu-karmic-lpia.libcap2_1%3A2.16-5_FAILEDTOBUILD.txt.gz

/usr/bin/make -C progs all
make[2]: Entering directory `/build/buildd/libcap2-2.16/progs'
gcc -fPIC -I/build/buildd/libcap2-2.16/progs/../libcap/include -I/build/buildd/libcap2-2.16/progs/../libcap/include -g -O2 -g -Wall -O2 -c getpcaps.c -o getpcaps.o
gcc -g -O2 -g -Wall -O2 -Wl,-Bsymbolic-functions -o getpcaps getpcaps.o -L../libcap -lcap
gcc -fPIC -I/build/buildd/libcap2-2.16/progs/../libcap/include -I/build/buildd/libcap2-2.16/progs/../libcap/include -g -O2 -g -Wall -O2 -c capsh.c -o capsh.o
In file included from /usr/include/bits/sigcontext.h:28,
                 from /usr/include/signal.h:333,
                 from /usr/include/sys/wait.h:31,
                 from capsh.c:19:
/usr/include/asm/sigcontext.h:28: error: expected specifier-qualifier-list before '__u64'
/usr/include/asm/sigcontext.h:191: error: expected specifier-qualifier-list before '__u64'

Revision history for this message
In , Kamil (kamil-redhat-bugs) wrote :

Description of problem:
In file included from /usr/include/bits/sigcontext.h:28,
                 from /usr/include/signal.h:333,
                 from ../lib/signal.h:32,
                 from ls.c:66:
/usr/include/asm/sigcontext.h:28: error: expected specifier-qualifier-list before '__u64'
/usr/include/asm/sigcontext.h:191: error: expected specifier-qualifier-list before '__u64'

Version-Release number of selected component (if applicable):
kernel-headers-2.6.29-0.74.rc3.git3.fc11

Actual results:
http://koji.fedoraproject.org/koji/getfile?taskID=1098835&name=build.log

Expected results:
http://kojipkgs.fedoraproject.org/packages/coreutils/7.0/7.fc11/data/logs/i386/build.log

Additional info:
works with kernel-headers-2.6.29-0.53.rc2.git1.fc11

Revision history for this message
In , Quentin (quentin-redhat-bugs) wrote :

The problem is introduced at rc3.git3 (i.e. rc3.git2 does not exhibit the problem).

The problem is caused by the following change:
--- 73/usr/include/asm/sigcontext.h 2009-01-31 02:40:27.000000000 +0000
+++ 74/usr/include/asm/sigcontext.h 2009-02-01 01:56:00.000000000 +0000
@@ -2,7 +2,7 @@
 #define _ASM_X86_SIGCONTEXT_H

-#include <asm/types.h>
+#include <linux/types.h>

 #define FP_XSTATE_MAGIC1 0x46505853U
 #define FP_XSTATE_MAGIC2 0x46505845U

which is referenced in the changelog as:
commit e59afe6a21dce7bb3c63ba4f894a3195ae3d5529
Author: Jaswinder Singh Rajput <email address hidden>
Date: Fri Jan 30 22:53:49 2009 +0530

    headers_check fix: x86, sigcontext.h

    fix the following 'make headers_check' warnings:

      usr/include/asm/sigcontext.h:5: include of <linux/types.h> is preferred over <asm/types.h>
      usr/include/asm/sigcontext.h:24: found __[us]{8,16,32,64} type without #include <linux/types.h>

    Signed-off-by: Jaswinder Singh Rajput <email address hidden>

Revision history for this message
In , Ondrej (ondrej-redhat-bugs) wrote :

Raising priority to high - this bug/regression still blocks coreutils builds in rawhide.

Revision history for this message
In , Kyle (kyle-redhat-bugs) wrote :

This is almost certainly a bug in the games coreutils is playing with signal.h, I'm looking at the preprocessed source (gcc -E) now, and __u64 isn't getting included. Why? I'm guessing because a header guard is duplicated.

Revision history for this message
In , Kyle (kyle-redhat-bugs) wrote :

Nope, bug in libcap-devel, which is just stupendously horrendously broken. It's defining header guards when it shouldn't be, which prevents the correct _LINUX_TYPES_H_ from being included.

In the meantime, coreutils can likely be fixed by moving the <sys/capability.h> include further down, or explicitly including <linux/types.h> early.

http://kyle.fedoraproject.org/libcap-sanitized-for-userspace.diff

Revision history for this message
In , Kyle (kyle-redhat-bugs) wrote :

Sorry, meant http://kyle.fedorapeople.org/libcap-sanitized-for-userspace.diff

Revision history for this message
In , Miroslav (miroslav-redhat-bugs) wrote :

This bug prevents also chrony package to build. Reversing the order of the signal.h and capability.h includes helps, but still would be nice to have this fixed properly.

Revision history for this message
In , Karsten (karsten-redhat-bugs) wrote :

please try again with libcap-2.16-2.fc11 and reopen if the problem still exists.
I was able to build the latest chrony vom cvs without the -cap patch.

Revision history for this message
In , Ralph (ralph-redhat-bugs) wrote :

Still breaks for me trying to compile VirtualBox, or a small test program. [I don't seem to have perms to re-open the bug, could someone else do it?]

$ cat temp.c
#include <sys/capability.h>

$ gcc -c temp.c
In file included from /usr/include/sys/capability.h:23,
                 from temp.c:1:
/usr/include/stdint.h:41: error: conflicting types for ‘int64_t’
/usr/include/linux/types.h:98: note: previous declaration of ‘int64_t’ was here
/usr/include/stdint.h:56: error: conflicting types for ‘uint64_t’
/usr/include/linux/types.h:96: note: previous declaration of ‘uint64_t’ was here

Revision history for this message
In , Ralph (ralph-redhat-bugs) wrote :

Looks like: (a) including linux/types.h then stdint.h is broken (kernel-headers / glibc problem).
(b) unistd.h or similar is needed for ssize_t

Bug Watch Updater (bug-watch-updater)
Changed in libcap2 (Fedora):
status: Unknown → Fix Released
Matthias Klose (doko)
Changed in libcap2 (Ubuntu):
importance: Undecided → High
milestone: none → karmic-alpha-3
status: New → Triaged
Changed in linux (Ubuntu):
importance: Undecided → High
milestone: none → karmic-alpha-3
status: New → Triaged
Revision history for this message
Colin Watson (cjwatson) wrote :

I don't think there's anything wrong with the kernel here - its version of <linux/capability.h> is sanitised for userspace, and I can't reproduce the problems mentioned at the end of the Fedora bug on Ubuntu. Kyle's patch looks good except that with the version of libcap we're shipping we also need to update its own local copy of <linux/capability.h> to something current. I'll take care of that.

Changed in linux (Ubuntu):
milestone: karmic-alpha-3 → none
status: Triaged → Invalid
Changed in libcap2 (Ubuntu):
assignee: nobody → Colin Watson (cjwatson)
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package libcap2 - 1:2.16-5ubuntu1

---------------
libcap2 (1:2.16-5ubuntu1) karmic; urgency=low

  * fix-capability-headers.diff: <linux/capability.h> is sanitised properly
    for userspace now, so stop trying to work around it in ways that break
    by failing to define __u64 properly (patch from Kyle McMartin of Red
    Hat; LP: #375595). In addition to the Red Hat patch, update our
    <linux/capability.h> from linux-libc-dev 2.6.31-1.13, thereby actually
    including said header sanitisation.

 -- Colin Watson <email address hidden> Thu, 02 Jul 2009 13:37:27 +0100

Changed in libcap2 (Ubuntu):
status: Triaged → Fix Released
Bug Watch Updater (bug-watch-updater)
Changed in libcap2 (Fedora):
importance: Unknown → Medium
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

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