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

Re: dpkg-architecture adaptations for e.g. uclibc and ABIs

Pjotr Kourzanov <peter.kourzanov@xs4all.nl> writes:

> Goswin von Brederlow wrote:
>> Pjotr Kourzanov <peter.kourzanov@xs4all.nl> writes:
>>> Updated patch can be found here:
>>> http://www.xs4all.nl/~kurzanov/debian/patches/dpkg-1.13.16-all-1.patch.
>>> Besides allowing CPU-uclibc architectures it also adds:
>>> 1. Specific ARM families armv4,armv5te,strongarm and xscale
>>> 2. ARM variations such as VFP and softfloat (old ABI)
>>> 3. EABI suffix for linux, linux-uclibc, hurd and hurd-uclibc
>>>    (last two are rather fictional though;-)
>> What about mips O32, N32 and N64 ABIs? Can they be differentiated with
>> that method too?
> Yes, I suppose they could. What I did for arm-eabi before armel was chosen
> is to add linux-eabi and linux-uclibc-eabi to ostable. The rest comes sort
> of automatically because of (.*) in split_debian from dpkg-architecture.
>   We do need a way still to prohibit certain combinations (eabi for MIPS,
> O32, N32 and N64 for ARM)... Maybe an abitable besides ostable and cputable
> would suffice with content such as:
> linux-i386(-uclibc)?
> linux-arm(-uclibc)?(-eabi)?
> linux-mips(el)?(-[on]32|-n64)?
>> MfG
>>         Goswin

With multiarch that solves itself. Every ABI is its own architecture
and dpkg/apt will (somehow, automatic? conffile? something anyway)
know what architectures the cpu can run.


Reply to: