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

Re: Multiarch and idea for improved diversions and alternatives handling



Neil Williams <codehelp@debian.org> writes:

> On Fri, 2008-07-04 at 08:33 +0200, Tollef Fog Heen wrote:
>> * Neil Williams 
>> 
>> | Just a thought - why use /usr/lib/$ARCH and /usr/include/$ARCH at all
>> | when it would (IMHO) be simpler to use /usr/$TRIPLET/ and put the entire
>> | package under that, as we do with dpkg-cross currently:
>> 
>> How would you then handle libraries that go in /lib?  (Apart from the
>> fact that I think just using a subdirectory of /usr/lib is much neater
>> than random subdirectories in /usr.
>
> /lib/
> /arm-linux-gnu/lib/
>
> (did I miss that bit?)
>
> A single subdirectory of /usr is, IMHO, neater than a subdirectory
> of /usr/include and /usr/lib/. It would also mean less changes for those
> who are currently using multiple architectures on one system for the
> purposes of cross building. I wouldn't want to go the whole hog though
> and have /arm-linux-gnu/usr/lib /arm-linux-gnu/lib because that would be
> ugly, at least to me.
>
>> 
>> | /usr/include/
>> | /usr/arm-linux-gnu/include/
>> 
>> Please note that the initial goal of multiarch at least has been just
>> running of packages from foreign architectures.  Not building them.
>
> True but the current usage of these mechanisms is in cross-building so
> sometimes the results of having to do something without major changes
> elsewhere can be helpful in designing the subsequent mechanism.

The current mechanism is a total mess and needs to be thrown out and
done right in any case.

binutils on amd64 uses /usr/i386-linux-gnu/lib while i386 uses
/usr/i486-linux-gnu/lib. So cross-building will fail there anyway.  It
also misses /i486-linux-gnu/lib making several core libraries go
missing. Not to mention that multilib gcc does not provide the cross
compiler binaries for the other supported archs,
i.e. i486-linux-gnu-gcc on amd64.

Further those directories are totaly wrong when compiling code for
e.g. uclibc.


The binutils upstream has further decided that it is not binutils
place to support multiarch directories. That is a job of the
compiler. As such binutils should be stoped from blindly adding the
(wrong) cross-compile dir and gcc should add the right directories.


So no matter what actual path you pick there has to be exactly the
same change. Both binutils and gcc need adapting.

 
>> | multiarch could even add:
>> | /usr/share/
>> | /usr/arm-linux-gnu/share
>> 
>> Pardon my language, but this is crack.  The point of /usr/share is you
>> can share it between systems.  If you go down this route, just use a
>> chroot and some wrapper scripts to bounce between them instead.
>
> It was only a suggestion for /usr/share - it was an alternative to
> renaming the package to get a different directory in /usr/share/ as the
> current tools do. Until all suitable packages have things like
> translations separated out into TDebs and other things like images in a
> -data or -common package instead of being packaged along with the
> architecture-dependent binaries, conflicts will occur if /usr/share is
> used as intended.

Then you could not just share /usr/share via nfs but would have to
share all the multiarch share dirs. bad bad bad.

MfG
        Goswin


Reply to: