Re: RFH: Multiarch capable toolchain as release goal
"Bernhard R. Link" <brlink@debian.org> writes:
> * Lennart Sorensen <lsorense@csclub.uwaterloo.ca> [080415 21:57]:
>> Now I suppose sparc and others might still like it if they have
>> performance advantages of 32bit code over 64bit code, in which case
>> keeping 64bit for only those programs where the extra address space is
>> worth it would be great.
>
> I guess most long-year sparc users are by now against any multiarch
> stuff by bad experience. Having 64 bit libraries installed on sparc
> was always the best way to get a broken system. Every other year
> some directory changes to a symlink, or a symlink to a directory,
> changes it name from ultra to sparc64 or there is some other reason
> breaking your upgrades. So at least I try as good as I can to avoid
> anything with the threathening "64" in its name.
>
> Hochachtungsvoll,
> Bernhard R. Link
Multiarch, for lack of a better unique identifier, currently uses the
gnu tripplet as directory name. If you change your abi name from ultra
to sparc64 then the tripplet would change and therefore the directory
name, right?
The problem you describe is exactly one of the reasons for the
multiarch design. Every library should have a unique location so
packages for different "architectures" will not create file conflicts
and can be installed in parallel. No moving, no linking. If you add a
new ABI you must make it end up in a new and unique location.
Also a change in the location would mean adding a new location,
changing the libs one by one and then remove the old location when it
is empty. Again no moving or linking.
To give some examples you can have
/usr/lib/i486-linux-gnu/
/usr/lib/i686-linux-gnu/
/usr/lib/i484-linux-uclibc/
/usr/lib/x86_64-linux-gnu/
/usr/lib/ppc-linux-gnu/
all on the same system.
MfG
Goswin
Reply to: