[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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: