On Thu, 12 Mar 2009 10:31:03 +0100
Goswin von Brederlow <goswin-v-b@web.de> wrote:
> > I thought mulitarch wanted:
(this is making a lot more sense now.)
So, updating:
> > /usr/
> > |-- include/
> > | `-- $arch-linux-gnu/
> > | `-- foo.h
> > `-- lib/
> > `-- $arch-linux-gnu/
> > `-- libfoo.so
> >
> >
> > The problem, as I see it, with /usr/include/$arch-linux-gnu/foo.h is
> > that it makes it impossible to export one entire tree of all
> > cross-build stuff. i.e. make /usr/$arch-linux-gnu/ available and
> > everything is in a single place. Instead, three paths need to be
> > exported.
In the end, it's two paths.
> One reason against /usr/$arch-linux-gnu/ was that it pollutes the/usr
> namespace. In my opinion that is a pretty weak argument. The
> directories would only be there as needed and never many.
Agreed - it's also a tradition of long-standing with lots of existing
tools to support it, inside and outside Debian.
However, cross-dependencies need to use the multiarch methods to be
included into normal Debian which makes the specialised tools either
redundant or standard. I think that is a price worth paying. The
objective all along has been to have Debian supporting cross-building
and toolchains without specialised support.
> > So which layout do we need for LHS?
> >
> > /usr/
> > `-- $arch-linux-gnu/
> > |-- include/
> > | `-- foo.h
> > `-- lib/
> > `-- libfoo.so
> >
> > i.e. a complete hierarchy beneath /usr/arm-linux-gnu/ with files that
> > are normally in /bin/ in /usr/$arch-linux-gnu/bin and files that are
> > normally in /usr/bin/ in /usr/$arch-linux-gnu/usr/bin, similarly for
> > lib.
>
> That will not work. You can not for example but /bin/sh into
s/but/boot/
I don't think anyone wants to boot into that location, they want to be
able to export it complete to another system that has also booted
normally. It is only the 32bit/64bit multiarch usage where booting
becomes an issue.
> >> > Is there any information arround, maybe LHS, on how to setup <DIR>
> >> > layout?
> >> >
> >> > Nowadays we are using non multiarch structure as:
> >> >
> >> > usr/$arch-linux-gnu
> >> > |-- include
> >> > `-- lib
> >> >
> >> > But what it should look like in future? /usr/include/$arch-linux-gnu?
> >> > Would it be reasonable to be using a new layout like:
> >> >
> >> > usr/include/$arch-linux-gnu
> >> > usr/
> >> > |-- include
| `-- $arch-linux-gnu
> >> > `-- lib
`-- $arch-linux-gnu
> >> That is already standard on i386/amd64 at least. Many /usr/include/*
> >> files just include the right usr/include/$arch-linux-gnu file
> >> depending on wether __i386__ or __x86_64__ is set. gcc also looks into
> >> those dirs on its own. So yes, do use those.
> >
> > Is that /usr/include/$arch-linux-gnu/usr/include/foo.h ?
>
> No, just /usr/include/$arch-linux-gnu/foo.h.
and /usr/lib/$arch-linux-gnu/libfoo.so ?
> Special case as some of binutils behave differently depending on the
> arch they support. That is not something that is needed distribution
> wide.
True.
> Also isn't there an /usr/bin/arm-linux-gnu-objdump? Maybe just a link
> to /usr/arm-linux-gnu/bin/objdump?
-rwxr-xr-x 2 root root 882128 2008-07-01 16:41 /usr/arm-linux-gnu/bin/objdump
-rwxr-xr-x 2 root root 882128 2008-07-01 16:41 /usr/bin/arm-linux-gnu-objdump
Not a symlink, but it is there.
> > Hmm, so dpkg-cross would need to change the path to include/ for
> > headers but not change the path for libraries?
>
> dpkg-cross does not need to change anything. First gcc needs to
> change. Then packages. And last dpkg/apt/aptitude. And then dpkg-cross
> is obsolete.
This is the plan, yes. Once dpkg supports multiarch
in /usr/include/$arch-linux-gnu and /usr/lib/$arch-linux-gnu/ then
dpkg-cross becomes not only obsolete but counter-productive. That
version of dpkg will conflict with dpkg-cross, leading to the
inevitable removal of dpkg-cross from unstable.
> > We'd have:
> >
> > /usr/arm-linux-gnu/lib/libfoo.so
> > /usr/include/arm-linux-gnu/include/foo.h
> > or
> > /usr/arm-linux-gnu/usr/lib/libfoo.so
> > /usr/include/arm-linux-gnu/usr/include/foo.h
> >
So current dpkg-cross behaviour:
/usr/arm-linux-gnu/lib/libfoo.so
/usr/arm-linux-gnu/include/foo.h
Multiarch behaviour that doesn't need dpkg-cross:
/usr/lib/arm-linux-gnu/libfoo.so
/usr/include/arm-linux-gnu/foo.h
> > as a conversion of /usr/lib/libfoo.so
>
> The question is
>
> /arm-linux-gnu/lib/libfoo.so
l> /usr/arm-linux-gnu/[usr/]lib/libbla.so
> /usr/arm-linux-gnu/[usr/]include/foo.h
>
> or
>
> /lib/arm-linux-gnu/libfoo.so
> /usr/lib/arm-linux-gnu/libbla.so
> /usr/include/arm-linux-gnu/foo.h
>
> It has always been a question of where to put the tripplet, not
> whether or not to have an extra subdir below that. Although I'm
> against the subdirs. No need to duplicate that this is "usr".
I'd agree - [usr] below $arch-linux-gnu appears redundant to me. The
only difference between /lib and /usr/lib/ relates to the libraries
required to boot before /usr is mounted. That reasoning doesn't apply
to toolchain issues.
--
Neil Williams
=============
http://www.data-freedom.org/
http://www.linux.codehelp.co.uk/
http://e-mail.is-not-s.ms/
Attachment:
pgpmcZn8HloeF.pgp
Description: PGP signature