Neil Williams <codeh...@debian.org> writes:
> On Thu, 12 Mar 2009 10:31:03 +0100
> Goswin von Brederlow <goswin-...@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.
s/but/put/
The design of multiarch is such that every arch builds its own package
but any arch can install it [limited only by the systems
configuration]. If you want arm-linux-gnu binaries to end up in
/usr/arm-linux-gnu/bin/ on i386 then they would also end up there on
native arm. And clearly that will not work.
If you want to keep dpkg-cross to do some path translations at install
time so arm binaries end up in /usr/arm-linux-gnu/bin/ on i386 then
that is fine. There has also been talk about having some path
translations in dpkg itself. Carefully designed they could do this
too. But that is a different matter from the situation with libraries,
where we want the native versions to move as well as when
cross-building.
So when I talk about paths I allways mean the path inside the deb. For
multiarch translating path at install time is not an option as locale
support, plugins and any other dynamic loading usualy has fixed paths
in the binaries or default conffiles and will fail with translated
paths.
>> > 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.
By the way, the include path should already be fully functional. Also
runtime support for /usr/lib/$arch-linux-gnu/ is fully there. It is
just gcc support to link from there that is missing.
As for dpkg support that can be emulated with a wrapper. A slimmed
down version of ia32-apt-get or dpkg-cross without the path
translations. For those that want to already play with
multiarch/cross-building before the normal dpkg supports it natively.
>> > 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.
But keep in mind that it does apply to multiarch. So the cross-build
scheme would not only polute the /usr hierachy but also /.
MfG
Goswin
--
To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
