FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian Development

 
 
LinkBack Thread Tools
 
Old 11-16-2011, 02:50 AM
Jonathan Nieder
 
Default 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...



--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20111116035012.GA5889@elie.hsd1.il.comcast.net">ht tp://lists.debian.org/20111116035012.GA5889@elie.hsd1.il.comcast.net
 
Old 11-16-2011, 12:29 PM
Wolfgang Tichy
 
Default Bug#648889: /usr/include/features.h(323): catastrophic error: could not open source file "bits/predefs.h"

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



--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: CA+OowJ+g5TDcNX+u0UgEGhhabVokg-wtDiOL-m4RBKM+ez-wiw@mail.gmail.com">http://lists.debian.org/CA+OowJ+g5TDcNX+u0UgEGhhabVokg-wtDiOL-m4RBKM+ez-wiw@mail.gmail.com
 

Thread Tools




All times are GMT. The time now is 09:39 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org