Bug#648889: /usr/include/features.h(323): catastrophic error: could not open source file "bits/predefs.h"
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...
Reply to: