Debian Bug report logs - #648889
/usr/include/features.h(323): catastrophic error: could not open source file "bits/predefs.h"

Package: general; Maintainer for general is debian-devel@lists.debian.org;

Reported by: Wolfgang Tichy <wtichy43@gmail.com>

Date: Tue, 15 Nov 2011 21:51:02 UTC

Severity: important

Merged with 637232, 639214, 644986, 682678

Reply or subscribe to this bug.

Toggle useless messages

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to debian-bugs-dist@lists.debian.org, GNU Libc Maintainers <debian-glibc@lists.debian.org>:
Bug#648889; Package libc6-dev. (Tue, 15 Nov 2011 21:51:05 GMT) Full text and rfc822 format available.

Acknowledgement sent to Wolfgang Tichy <wtichy43@gmail.com>:
New Bug report received and forwarded. Copy sent to GNU Libc Maintainers <debian-glibc@lists.debian.org>. (Tue, 15 Nov 2011 21:51:07 GMT) Full text and rfc822 format available.

Message #5 received at submit@bugs.debian.org (full text, mbox):

From: Wolfgang Tichy <wtichy43@gmail.com>
To: Debian Bug Tracking System <submit@bugs.debian.org>
Subject: /usr/include/features.h(323): catastrophic error: could not open source file "bits/predefs.h"
Date: Tue, 15 Nov 2011 16:30:14 -0500
Package: libc6-dev
Version: 2.13-21
Severity: normal

Dear Maintainer,

I just tried to comiple some code with the intel compiler and got:
/usr/include/features.h(323): catastrophic error: could not open source file
"bits/predefs.h"
  #include <bits/predefs.h>

The reason seems to be that /usr/include/features.h includes bits/predefs.h
which does not exist in  /usr/include/ . However, it exists in
/usr/include/x86_64-linux-gnu/ . If I also install libc6-dev-i386 the problem
goes away since this seems to create a symlink /usr/include/bits -> x86_64
-linux-gnu/bits .

Shouldn't we be able to use features.h without also installing  libc6-dev-i386?

Thanks a lot,
Wolfgang



-- System Information:
Debian Release: wheezy/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 3.0.0-1-amd64 (SMP w/6 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages libc6-dev depends on:
ii  libc-dev-bin    2.13-21
ii  libc6           2.13-21
ii  linux-libc-dev  3.0.0-3

Versions of packages libc6-dev recommends:
ii  gcc [c-compiler]      4:4.6.1-3
ii  gcc-4.6 [c-compiler]  4.6.1-15 

Versions of packages libc6-dev suggests:
ii  glibc-doc     <none>  
ii  manpages-dev  3.32-0.2

-- debconf-show failed




Information forwarded to debian-bugs-dist@lists.debian.org, GNU Libc Maintainers <debian-glibc@lists.debian.org>:
Bug#648889; Package libc6-dev. (Tue, 15 Nov 2011 22:03:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Jonathan Nieder <jrnieder@gmail.com>:
Extra info received and forwarded to list. Copy sent to GNU Libc Maintainers <debian-glibc@lists.debian.org>. (Tue, 15 Nov 2011 22:03:04 GMT) Full text and rfc822 format available.

Message #10 received at 648889@bugs.debian.org (full text, mbox):

From: Jonathan Nieder <jrnieder@gmail.com>
To: Wolfgang Tichy <wtichy43@gmail.com>
Cc: 648889@bugs.debian.org
Subject: Re: /usr/include/features.h(323): catastrophic error: could not open source file "bits/predefs.h"
Date: Tue, 15 Nov 2011 15:59:43 -0600
# affects most development libraries, not just libc
reassign 648889 general
forcemerge 637232 648889
quit

Hi Wolfgang,

Wolfgang Tichy wrote:

> I just tried to comiple some code with the intel compiler and got:
> /usr/include/features.h(323): catastrophic error: could not open source file
> "bits/predefs.h"
>   #include <bits/predefs.h>
>
> The reason seems to be that /usr/include/features.h includes bits/predefs.h
> which does not exist in  /usr/include/ . However, it exists in
> /usr/include/x86_64-linux-gnu/ .

See [1] for some background.

/usr/share/doc/libc6/NEWS.Debian.gz explains:

  Starting with the eglibc package version 2.13-5, the libraries are
  shipped in the multiarch directory /lib/<triplet> instead of the more
  traditional /lib, where <triplet> is the multiarch triplet and can be
  retrieved with 'dpkg-architecture -qDEB_HOST_MULTIARCH'. Similarly the
  includes are now shipped in /usr/include/<triplet> instead of the more
  traditional /usr/include.

  The toolchain in Debian has been updated to cope with that, and most
  build systems should be unaffected. If you are using a non-Debian
  toolchain to build your software and it is not able to cope with
  multiarch, you might try to pass the following option to your
  compiler:

    -B/usr/lib/<triplet> -I/usr/include/<triplet>

I believe the best long-term solution would be to teach the Intel
compiler to use the /usr/{lib,include}/<triplet> directories so it can
find libraries and header files for the target architecture as they
move to the new location.

In the short term, however, you will probably need to configure your
compiler differently (perhaps by adding appropriate flags to your
definition of the CC variable).  Does the Intel compiler support the
-B and -I options?

Thanks for writing,
Jonathan

[1] http://wiki.debian.org/Multiarch




Bug reassigned from package 'libc6-dev' to 'general'. Request was from Jonathan Nieder <jrnieder@gmail.com> to control@bugs.debian.org. (Tue, 15 Nov 2011 22:03:09 GMT) Full text and rfc822 format available.

Bug No longer marked as found in versions eglibc/2.13-21. Request was from Jonathan Nieder <jrnieder@gmail.com> to control@bugs.debian.org. (Tue, 15 Nov 2011 22:03:09 GMT) Full text and rfc822 format available.

Forcibly Merged 637232 639214 644986 648889. Request was from Jonathan Nieder <jrnieder@gmail.com> to control@bugs.debian.org. (Tue, 15 Nov 2011 22:03:12 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, debian-devel@lists.debian.org:
Bug#648889; Package general. (Wed, 16 Nov 2011 03:51:15 GMT) Full text and rfc822 format available.

Acknowledgement sent to Jonathan Nieder <jrnieder@gmail.com>:
Extra info received and forwarded to list. Copy sent to debian-devel@lists.debian.org. (Wed, 16 Nov 2011 03:51:15 GMT) Full text and rfc822 format available.

Message #21 received at 648889@bugs.debian.org (full text, mbox):

From: Jonathan Nieder <jrnieder@gmail.com>
To: Wolfgang Tichy <wtichy43@gmail.com>
Cc: 648889@bugs.debian.org
Subject: Re: /usr/include/features.h(323): catastrophic error: could not open source file "bits/predefs.h"
Date: Tue, 15 Nov 2011 21:50:12 -0600
Wolfgang Tichy wrote:

> Thanks for your answer. I think the intel compiler does support the -B
> and -I options. So I think your suggestion would work. However, I am
> not sure if I like this solution.

It's only a workaround.  A fix would involve contacting the Intel
developers to get icc to search the new paths by default.

> I always loved debian for the fact
> that libraries and include files were in standard places (unlike say
> in redhat based distributions). So it was always easy to compile with
> any compiler.

Yes, I understand.

> Moving them to other places seems to complicate things.
> I mean I am no expert on multiarch and guess there are good reasons
> for that. But why can't there be symlinks to the files you need for
> your own architecture in standard places? Would that break something?

There are two sides to that question: would adding such symlinks be
feasible?  And would the resulting behavior of the system be desirable?

Compatibility symlinks for multiarch: the use case
--------------------------------------------------

Let's take the second question first.  If /usr/lib and /usr/include
were filled with symlinks to the corresponding architecture-specific
files for the native architecture, there would be some nice benefits:

 - multiarch-unaware compilers would continue to work
 - programs hard-coding paths to libraries would continue to work

On the other hand, binaries and builds for foreign architectures
would be likely to misbehave when libraries for that arch are missing
(/usr/lib/<arch>/foo.so is missing and /usr/lib/foo.so is not).  So
for someone using only multiarch-aware programs, the net effect is
negative.

Compatibility symlinks for multiarch: feasibility
-------------------------------------------------

Now the first question.  In wheezy, packages that are marked as such
can be installed on multiple architectures at once.  So, for example,
I can install the i386 and the amd64 versions of libavcodec at the
same time.

Which package would get to put a symlink to its library in /usr/lib?

It's tempting to say "the native one", but it is not always clear
which one that is.  In fact, one of the goals of multiarch is to be
able to (gradually) upgrade an i386 system to an amd64 one.  At what
point has the native architecture switched?

A proposal
----------

The above suggests to me a possible way forward.  To be clear, I do
not want to work on this; this is just a sketch of one way that people
who do want to work on it could try.

The idea is that there would be a separate package that installs
compatibility symlinks pointing to /usr/lib/<triplet>/* and
/usr/include/<triplet>/* to help people still using multiarch-unaware
tools.

Its post-installation script would be a simple script that scans
/usr/lib/<triplet> and /usr/include/<triplet> for added or removed
libraries and updates the corresponding symlinks in /usr/lib and
/usr/include.  Using triggers (see [1]) it would ensure that this
script is run for each apt run in which a file is installed to or
removed from /usr/lib/<triplet> or /usr/include/<triplet>.

This compatibility package could be removed at any time and
multiarch-aware packages would continue to work.

(Based on an idea from Matthias Klose[2].)

Of course, I would be even happier to see tools like icc learn about
the new paths.

Hope that helps,
Jonathan

[1] /usr/share/doc/dpkg-dev/triggers.txt.gz
[2] http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=40;bug=634821

> Thanks,
> Wolfgang
>
> PS: I do not mean to complain. I think Debian is great and I am
> grateful for the job you maintainers do. I only write because I like
> Debian, and thought this might be helpful...




Information forwarded to debian-bugs-dist@lists.debian.org, debian-devel@lists.debian.org:
Bug#648889; Package general. (Wed, 16 Nov 2011 13:33:06 GMT) Full text and rfc822 format available.

Acknowledgement sent to Wolfgang Tichy <wtichy43@gmail.com>:
Extra info received and forwarded to list. Copy sent to debian-devel@lists.debian.org. (Wed, 16 Nov 2011 13:33:06 GMT) Full text and rfc822 format available.

Message #26 received at 648889@bugs.debian.org (full text, mbox):

From: Wolfgang Tichy <wtichy43@gmail.com>
To: Jonathan Nieder <jrnieder@gmail.com>
Cc: 648889@bugs.debian.org
Subject: Re: /usr/include/features.h(323): catastrophic error: could not open source file "bits/predefs.h"
Date: Wed, 16 Nov 2011 08:29:43 -0500
Hi Jonathan,

thank you for your explaination. I think your proposal for a
compatibility package is very good.

Thanks,
Wolfgang

On Tue, Nov 15, 2011 at 10:50 PM, Jonathan Nieder <jrnieder@gmail.com> wrote:
> Wolfgang Tichy wrote:
>
>> Thanks for your answer. I think the intel compiler does support the -B
>> and -I options. So I think your suggestion would work. However, I am
>> not sure if I like this solution.
>
> It's only a workaround.  A fix would involve contacting the Intel
> developers to get icc to search the new paths by default.
>
>> I always loved debian for the fact
>> that libraries and include files were in standard places (unlike say
>> in redhat based distributions). So it was always easy to compile with
>> any compiler.
>
> Yes, I understand.
>
>> Moving them to other places seems to complicate things.
>> I mean I am no expert on multiarch and guess there are good reasons
>> for that. But why can't there be symlinks to the files you need for
>> your own architecture in standard places? Would that break something?
>
> There are two sides to that question: would adding such symlinks be
> feasible?  And would the resulting behavior of the system be desirable?
>
> Compatibility symlinks for multiarch: the use case
> --------------------------------------------------
>
> Let's take the second question first.  If /usr/lib and /usr/include
> were filled with symlinks to the corresponding architecture-specific
> files for the native architecture, there would be some nice benefits:
>
>  - multiarch-unaware compilers would continue to work
>  - programs hard-coding paths to libraries would continue to work
>
> On the other hand, binaries and builds for foreign architectures
> would be likely to misbehave when libraries for that arch are missing
> (/usr/lib/<arch>/foo.so is missing and /usr/lib/foo.so is not).  So
> for someone using only multiarch-aware programs, the net effect is
> negative.
>
> Compatibility symlinks for multiarch: feasibility
> -------------------------------------------------
>
> Now the first question.  In wheezy, packages that are marked as such
> can be installed on multiple architectures at once.  So, for example,
> I can install the i386 and the amd64 versions of libavcodec at the
> same time.
>
> Which package would get to put a symlink to its library in /usr/lib?
>
> It's tempting to say "the native one", but it is not always clear
> which one that is.  In fact, one of the goals of multiarch is to be
> able to (gradually) upgrade an i386 system to an amd64 one.  At what
> point has the native architecture switched?
>
> A proposal
> ----------
>
> The above suggests to me a possible way forward.  To be clear, I do
> not want to work on this; this is just a sketch of one way that people
> who do want to work on it could try.
>
> The idea is that there would be a separate package that installs
> compatibility symlinks pointing to /usr/lib/<triplet>/* and
> /usr/include/<triplet>/* to help people still using multiarch-unaware
> tools.
>
> Its post-installation script would be a simple script that scans
> /usr/lib/<triplet> and /usr/include/<triplet> for added or removed
> libraries and updates the corresponding symlinks in /usr/lib and
> /usr/include.  Using triggers (see [1]) it would ensure that this
> script is run for each apt run in which a file is installed to or
> removed from /usr/lib/<triplet> or /usr/include/<triplet>.
>
> This compatibility package could be removed at any time and
> multiarch-aware packages would continue to work.
>
> (Based on an idea from Matthias Klose[2].)
>
> Of course, I would be even happier to see tools like icc learn about
> the new paths.
>
> Hope that helps,
> Jonathan
>
> [1] /usr/share/doc/dpkg-dev/triggers.txt.gz
> [2] http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=40;bug=634821
>
>> Thanks,
>> Wolfgang
>>
>> PS: I do not mean to complain. I think Debian is great and I am
>> grateful for the job you maintainers do. I only write because I like
>> Debian, and thought this might be helpful...
>




Severity set to 'important' from 'critical' Request was from Holger Levsen <holger@layer-acht.org> to control@bugs.debian.org. (Tue, 29 May 2012 08:03:07 GMT) Full text and rfc822 format available.

Added indication that 648889 affects release-notes Request was from Jonathan Nieder <jrnieder@gmail.com> to control@bugs.debian.org. (Sun, 22 Jul 2012 17:54:14 GMT) Full text and rfc822 format available.

Merged 637232 639214 644986 648889 682678 Request was from Jonathan Nieder <jrnieder@gmail.com> to control@bugs.debian.org. (Tue, 24 Jul 2012 16:51:06 GMT) Full text and rfc822 format available.

Merged 637232 639214 644986 648889 682678 Request was from Aurelien Jarno <aurel32@debian.org> to control@bugs.debian.org. (Wed, 25 Jul 2012 07:15:03 GMT) Full text and rfc822 format available.

Send a report that this bug log contains spam.


Debian bug tracking system administrator <owner@bugs.debian.org>. Last modified: Fri Apr 18 13:44:04 2014; Machine Name: buxtehude.debian.org

Debian Bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.