Re: [RFC] [Cross Toolchain] Multiarch and sysrooted toolchain
Neil Williams <codehelp@debian.org> writes:
> On Wed, 11 Mar 2009 14:50:19 +0100
> Goswin von Brederlow <goswin-v-b@web.de> wrote:
>
>> >
>> > [*]
>> > I have been looking lately into making some cross toolchain
>> > improvements, one of them will be to change to a sysrooted cross
>> > toolchain, but the current layout we are using by dpkg-cross installs
>> > relevant bits under:
>> > <DIR>/{include,bin,lib,lib64}
>> > Mainstream code expects a different layout more LHS compliant,
>> > <DIR>/{usr/include,bin,lib,lib64}
>
> dpkg-cross currently does:
> /usr/
> `-- $arch-linux-gnu/
> |-- include/
> | `-- foo.h
> `-- lib/
> `-- libfoo.so
>
> $ ls /usr/arm-linux-gnu/
> bin include lib
>
> Very flat but quite simple.
>
> I thought mulitarch wanted:
> /usr/
> |-- bin/
> | `-- $arch-linux-gnu/
Doesn't work with #!/bin/whatever and is deemed unneccessary
anyway. There never need to be 2 flavours of the same binary as they
are supposed to do the same. Either one is sufficient.
> |-- include/
> | `-- $arch-linux-gnu/
> | `-- foo.h
> |-- lib64/
> | `-- $arch-linux-gnu/
What would we want that for? The $arch-linux-gnu already tells if it
is 32bit or 64bit. No need to duplicate that information in lib64.
> `-- 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.
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.
> So which layout do we need for LHS?
>
> /usr/
> `-- $arch-linux-gnu/
> |-- bin/
> |-- lib64/
> !-- lib/
> |-- usr/
> `-- |-- bin/
> |-- include/
> | `-- foo.h
> `-- lib/
> `-- libfoo.so
>
> $ ls /usr/arm-linux-gnu/
> bin lib64 lib usr
> $ ls /usr/arm-linux-gnu/usr
> bin include lib
> (with or without a symlink of /usr/arm-linux-gnu/usr/lib64
> to /usr/arm-linux-gnu/usr/lib) ?
>
> 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
/usr/$arch-linux-gnu/bin. There would be no shell before /usr is
mounted. You can not put libc6 into /usr/$arch-linux-gnu/lib for the
same catastrophic reason.
If you go with the cross-compile names then you also need
/$arch-linux-gnu/.... And if you handle bin this way you also need to
handle sbin.
>> > 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
>> > |-- bin
>> > |-- include
>> > |-- lib
>> > `-- lib64
>> >
>> > 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
>>
>> 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.
>> > |-- bin
>>
>> All binaries are assumed to do the same thing no matter what
>> architecture they are compiled for. As such there is no need to have
>> the same binary compiled for different archs at the same time. Also
>> any change here would play havock with shebang lines.
>
> binutils-multiarch puts stuff in /usr/$arch-linux-gnu/bin/
>
> $ ls /usr/arm-linux-gnu/bin/
> ar as ld nm objcopy objdump ranlib strip
Special case as some of binutils behave differently depending on the
arch they support. That is not something that is needed distribution
wide.
Also isn't there an /usr/bin/arm-linux-gnu-objdump? Maybe just a link
to /usr/arm-linux-gnu/bin/objdump?
>> > I am missing some papers on multiarch, are there any kind of
>> > information out there.
>>
>> You are missing the actual multiarch or cross-compile library dirs:
>>
>> /usr/$arch-linux-gnu/lib (cross-compile)
>> /usr/lib/$arch-linux-gnu (multiarch)
>>
>> I still haven't heart a good reason why multiarch can't use the
>> cross-compile dirs as the libraries for each are ment to be
>> interchangable (and in fact dpkg-cross demonstrates that already).
>
> 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.
> 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
>
> ?
>
> I thought the question was whether we would have:
>
> /usr/lib/arm-linux-gnu/lib/libfoo.so
> or
> /usr/lib/arm-linux-gnu/usr/lib/libfoo.so
> or
> /usr/arm-linux-gnu/usr/lib/libfoo.so
> or the current
> /usr/arm-linux-gnu/lib/libfoo.so
>
> as a conversion of /usr/lib/libfoo.so
The question is
/arm-linux-gnu/lib/libfoo.so
/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".
MfG
Goswin
Reply to: