Re: multiarch status update
"Matt Taggart and others" <taggart@debian.org> wrote in message
[🔎] 20060510090047.8A3931AA852@cyrix.home.bogus">news:[🔎] 20060510090047.8A3931AA852@cyrix.home.bogus...
Hi debian-devel,
For a couple years now a few of us have been talking about an idea called
"multiarch". This is a way to seamlessly allow support for multiple
different
binary targets on the same system, for example running both i386-linux-gnu
and
amd64-linux-gnu binaries on the same system (many other working
combinations
exist as well). I have created a new page in the wiki to track info and
status
My thoughts on a few multi-arch concepts.
It is important to differentiate between the types of non-native files.
There are files that are not native, but are intended to be used by native
programs targeting the non-native arch. These include things like
arch-specific header files.
It almost seems like these should be put in /usr/share/include/$arch-$os/.
(where $arch and $os represent the target arch) That is because headers for
cross compiling are normally dependent on the target arch, but not the host
arch.
On the other hand, if we continue that thought process we could end up with
all headers and libraries in /usr/share/, which is absurd.
Indeed, the current proposal almost seems to be reversing this.
Non-target specific libraries and header files remain in $prefix/lib and
$prefix/include.
It seems to me that libraries and headers that are not target specific are
supposed to go in /usr/share.
That is because if they are not target specific they are most certainly
cross-platform.
Hm... This entire concept seems messy. It seems that processors that support
multiple architectures,
as well as cross compilition are begining to blur the line between /usr and
/usr/share.
Reply to: