Neil Williams <codehelp@debian.org> wrote:
> Jonas Meyer <quitte@gmail.com> wrote:
> To create toolchains that have a new debian name than an already existing
> > architecture it'd be useful if something like this worked:
> >
> > dpkg-cross -a uclibc-mipsel -i libc6_2.6.1-6_mipsel.deb
> > dpkg-cross: libc6_2.6.1-6_mipsel.deb has wrong architecture (mipsel)
> > dpkg-cross: conversion of libc6_2.6.1-6_mipsel.deb failed.
> >
> > Please consider adding an option to disable that check.
My chosen method, at the moment, is to allow uClibc as a special case
rather than provide a new option. This allows *only* uclibc-<cpu> to be
built from packages of the corresponding <cpu> architecture - it does
not allow the check to be forced in a way that would result in, e.g. arm
packages being prepared for uclibc-armel or mips for uclibc-i386 etc.
# check package architecture
my $control_arch = $control{"architecture"};
if (($control_arch ne $arch) and
($control_arch ne "all") and
($arch !~ /^uclibc-$control_arch$/)) {
warn "$progname: $package has wrong architecture ($control_arch)\n";
goto fail;
}
> $ dpkg-architecture -auclibc-mipsel
> unknown Debian architecture uclibc-mipsel, you must specify GNU system
> type, too at /usr/bin/dpkg-architecture line 159.
>
> As dpkg-cross merges back into dpkg, dpkg-cross will increasingly rely
> on dpkg code. Just disabling the check isn't going to be sufficient. I
> am unsure how much dpkg-cross 2.x will be able to support architectures
> that are not already supported in dpkg-architecture and adding code to
> dpkg-cross that cannot be supported by dpkg is futile as dpkg-cross
> is expected to be removed before Lenny is released.
That now has to be updated - dpkg-cross will persist into Lenny and
there is room for an update before Lenny is released so a fix for this
bug could be implemented in 2.2.5. (Actually, the collected fixes could
justify making the next release 2.3.0)
IMHO there are, therefore, grounds to introduce the uclibc additional
architectures into Debian::DpkgCross %archtable alongside the remaining
strings that denote differences between dpkg-cross and
dpkg-architecture:
# Conversion table for Debian GNU/Linux architecture name ('$arch') to GNU
# type. This lists additional arch names that are not already supported by
# dpkg-architecture.
# Need to support uclibc formats and remove those that differ from dpkg.
# Migrate these into the conffile and allow anything the user specifies
# in that file.
%archtable = (
'armeb' => 'armeb-linux-gnueabi', #XXX This differs from dpkg-architecture
'hurd-i386' => 'i386-gnu', #XXX This differs from dpkg-architecture
's390x' => 's390-linux-gnu', #XXX This differs from dpkg-architecture
'openbsd-i386' => 'i386-openbsd', #XXX This differs from dpkg-architecture
'freebsd-i386' => 'i386-freebsd', #XXX This differs from dpkg-architecture
'darwin-i386' => 'i386-darwin', #XXX This differs from dpkg-architecture
'win32-i386' => 'i386-cygwin'
);
Ron's suggestion of extending the eventual tables once dpkg-cross is
merged into dpkg can be implemented with the uclibc support as a
component of those tables.
Ron <ron@debian.org> wrote:
> So I think what we need here is for dpkg tools to also read
> from any foo-table.* files that exist in /usr/share/dpkg/.
> Then you can add these custom arch definitions in ostable.myarch
> etc. where they won't get stomped by dpkg updates, and enable
> them to be provided by a separate package that 'defines' the
> new arch that is desired in a fairly well defined way.
>
> It shouldn't be too hard to add support for this to dpkg, and
> it has been discussed on #emdebian to a reasonable state of
> consensus among the participants. If no-one else has a better
> suggestion, and Neil and the dpkg maintainers like it, I think
> this is the way we should go on this.
The only problem with doing this in Debian::DpkgCross is that each CPU
has to be listed separately - we need to decide which uclibc
architectures we want supported in dpkg-cross >> 2.2.4.
The current changes for this bug only implement arm, armel, mips and
mipsel.
Sample output:
$ ./dpkg-cross -a uclibc-mipsel -b libc6_2.7-12_mipsel.deb
Building libc6-uclibc-mipsel-cross_2.7-12_all.deb
neil@holly:dpkg-cross$ dpkg -c libc6-uclibc-mipsel-cross_2.7-12_all.deb
drwxr-xr-x root/root 0 2008-07-13 10:06 ./
drwxr-xr-x root/root 0 2008-07-13 10:06 ./usr/
drwxr-xr-x root/root 0 2008-07-13 10:06 ./usr/mipsel-linux-uclibc/
drwxr-xr-x root/root 0 2008-07-13 10:06 ./usr/mipsel-linux-uclibc/lib/
-rwxr-xr-x root/root 144876 2008-06-03 10:00 ./usr/mipsel-linux-uclibc/lib/ld-2.7.so
-rw-r--r-- root/root 14496 2008-06-03 10:00 ./usr/mipsel-linux-uclibc/lib/libanl-2.7.so
-rw-r--r-- root/root 5600 2008-06-03 10:00 ./usr/mipsel-linux-uclibc/lib/libBrokenLocale-2.7.so
-rwxr-xr-x root/root 1556000 2008-06-03 10:00 ./usr/mipsel-linux-uclibc/lib/libc-2.7.so
-rw-r--r-- root/root 187236 2008-06-03 10:00 ./usr/mipsel-linux-uclibc/lib/libcidn-2.7.so
-rw-r--r-- root/root 39640 2008-06-03 10:00 ./usr/mipsel-linux-uclibc/lib/libcrypt-2.7.so
-rw-r--r-- root/root 14728 2008-06-03 10:00 ./usr/mipsel-linux-uclibc/lib/libdl-2.7.so
-rw-r--r-- root/root 553844 2008-06-03 10:00 ./usr/mipsel-linux-uclibc/lib/libm-2.7.so
-rw-r--r-- root/root 18404 2008-06-03 10:00 ./usr/mipsel-linux-uclibc/lib/libmemusage.so
...
uClibc conversion tables, only in dpkg-cross:
# Conversion table for Debian GNU/Linux architecture name ('$arch') to GNU
# type. This lists additional arch names that are not already supported by
# dpkg-architecture.
# Need to support uclibc formats and remove those that differ from dpkg.
# Migrate these into the conffile and allow anything the user specifies
# in that file.
%archtable = (
'armeb' => 'armeb-linux-gnueabi', #XXX This differs from dpkg-architecture
'hurd-i386' => 'i386-gnu', #XXX This differs from dpkg-architecture
's390x' => 's390-linux-gnu', #XXX This differs from dpkg-architecture
'openbsd-i386' => 'i386-openbsd', #XXX This differs from dpkg-architecture
'freebsd-i386' => 'i386-freebsd', #XXX This differs from dpkg-architecture
'darwin-i386' => 'i386-darwin', #XXX This differs from dpkg-architecture
'win32-i386' => 'i386-cygwin',
'uclibc-arm' => 'arm-linux-uclibc',
'uclibc-mips' => 'mips-linux-uclibc',
'uclibc-mipsel' => 'mipsel-linux-uclibc',
'uclibc-armel' => 'armel-linux-uclibc',
);
Is the armel one correct?
The fix from http://wiki.debian.org/EmDebian/UclibcToolchainBootstrap doesn't provide uclibc-armel.
$ dpkg-architecture -auclibc-armel
unknown Debian architecture uclibc-armel, you must specify GNU system type, too at /usr/bin/dpkg-architecture line 143.
dpkg-cross -a armel puts files into ./usr/arm-linux-gnueabi/ whereas
dpkg-cross -a uclibc-armel would put files
into ./usr/armel-linux-uclibc/
Please keep the bug report in the CC when replying (sending to the bug
will also send to the list) - use -maintonly if preferred, duplicates
are handled automatically.
--
Neil Williams
=============
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/
Attachment:
signature.asc
Description: This is a digitally signed message part