Bug#648889: /usr/include/features.h(323): catastrophic error: could not open source file "bits/predefs.h"
thank you for your explaination. I think your proposal for a
compatibility package is very good.
On Tue, Nov 15, 2011 at 10:50 PM, Jonathan Nieder <email@example.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
> 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
> 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 ) 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.)
> Of course, I would be even happier to see tools like icc learn about
> the new paths.
> Hope that helps,
>  /usr/share/doc/dpkg-dev/triggers.txt.gz
>  http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=40;bug=634821
>> 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...