Я вижу что-то действительно странное в armel
окружении Debian с привязкой к теме .
Но сначала немного предыстории ... Это долго, но вопрос сложный, и любая потенциальная помощь зависит от знания всей истории.
У меня есть встроенный ARM SoC, который работает под Linux - точнее, Debian armel
Lenny на ядре 2.6.17. Сам дистрибутив Debian легко обновляется до более поздних версий ( sudo apt-get dist-upgrade
) и, следовательно, может быть переведен на более высокую скорость, до armel
версий
squeeze
или даже wheezy
.
Проблема в том, что ядро является кастомным ... Рассматриваемая SoC ARM не является частью основного ядра, поэтому в версии 2.6.17 от нее практически отказались.
Если вы знаете, как работают Linux и GLIBC, вы уже можете увидеть проблему - версии GLIBC скомпилированы с минимальной поддерживаемой версией ядра ... которая вышла далеко за 2.6.17. Так что, если мы попытаемся, например, сделать chroot для Debian ...
$ # From inside the little ARM machine running Debian Lenny
$ sudo debootstrap --arch armel squeeze /squeeze \
http://ftp.whateverCountry.debian.org/debian
$ sudo -i
# mount -t proc none /squeeze/proc
# mount -t sysfs none /squeeze/sys
# mount -t devpts none /squeeze/dev/pts
# chroot /squeeze
Fatal: Kernel too old
... мы видим сообщение от GLIBC о том squeeze
, что оно не было скомпилировано для работы с этим старым ядром (2.6.17).
Та же проблема возникает и с wheezy - поскольку он новее, чем squeeze - и фактически будет происходить с любой версией Debian, поскольку их GLIBC не будет работать на моем ядре 2.6.17.
Сначала я думал, что это нарушает условия сделки, но потом я понял, что теоретически могу перекомпилировать GLIBC для работы со старым ядром, которое использует мой SoC ... Но мне нужна среда, идентичная той, которая использовалась для сборки libc6 пакет, например, в Debian squeeze.
Я предполагаю, что компиляция GLIBC и подготовка файла libc6_2.11.3-4.deb выполняются с помощью автоматического механизма кросс-компиляции, изобретенного богами Debian.
Я не Бог ... и я не могу найти в Google ничего о том, как стать единым целым - то есть, как использовать мой Core i5 в качестве хоста, для кросс-компиляции GLIBC, используя те же настройки, что и в пакетной версии (внутри Debian squeeze
) с помощью.
Итак, я обманул - я понял, как настроить версию Debian ARM на моем Core i5 (метод, использующий статическую версию qemu-arm
двоичного файла).
После того, как я сделал chroot в моей x86-версии Debian-armel-squeeze
, я смог просто ...
$ cd /var/tmp
$ apt-get source libc6
...
$ # edit this in - compile for my kernel...
$ vi eglibc-2.11.3/debian/sysdeps/linux.mk
...
MIN_KERNEL_SUPPORTED := 2.6.17
...
$ export DEB_BUILD_OPTS="nocheck parallel=1"
$ cd eglibc-2.11.3
$ dpkg-buildpackage -b -d -us -uc
... и через 3 часа ( Debian-armel-squeeze
укорененная в Core i5 версия с
синхронизацией намного медленнее, чем на родной машине ...), я получил пакет libc6 .deb. Вероятно, потребуется 3 месяца, чтобы сделать эту сборку в моем SoC, поэтому я не жалуюсь.
Вернувшись в свой настоящий ARM SoC, я скопировал все файлы libc (.so) нового пакета поверх файлов squeeze по умолчанию и попытался выполнить chroot ...
# chroot squeeze/
root@ttsiodras:/#
Да! Это сработало! (или так казалось)
Мой пользовательский libc сообщил изнутри chroot:
# /lib/libc.so.6
GNU C Library (Debian EGLIBC 2.11.3-4) stable release version 2.11.3, by Roland McGrath et al.
Copyright (C) 2009 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
Compiled by GNU CC version 4.4.5.
Compiled on a Linux 2.6.26 system on 2014-10-23.
Available extensions:
crypt add-on version 2.1 by Michael Glad and others
GNU Libidn by Simon Josefsson
Native POSIX Threads Library by Ulrich Drepper et al
Support for some architectures added on, not maintained in glibc core.
BIND-8.2.3-T5B
For bug reporting instructions, please see:
<http://www.debian.org/Bugs/>.
Вещи, казалось, работали - я скопировал файл, вызвал ls
...
Но когда я попытался использовать apt-get
для установки некоторых приложений squeeze
, я начал получать ... некоторые неожиданные ошибки:
# apt-get install indent
Reading package lists... Done
Building dependency tree... Done
The following NEW packages will be installed:
indent
0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Need to get 110 kB of archives.
After this operation, 516 kB of additional disk space will be used.
Get:1 http://ftp.gr.debian.org/debian/ squeeze/main indent armel 2.2.11-1 [110 kB]
Fetched 110 kB in 0s (236 kB/s)
tar: ./control: Cannot utime: Function not implemented
tar: ./md5sums: Cannot utime: Function not implemented
tar: .: Cannot utime: Function not implemented
tar: Exiting with failure status due to previous errors
dpkg-deb: subprocess tar returned error exit status 2
dpkg: error processing /var/cache/apt/archives/indent_2.2.11-1_armel.deb (--unpack):
subprocess dpkg-deb --control returned error exit status 2
configured to not write apport reports
rm: cannot remove `/var/lib/dpkg/tmp.ci': Function not implemented
dpkg: error while cleaning up:
subprocess rm cleanup returned error exit status 1
Errors were encountered while processing:
/var/cache/apt/archives/indent_2.2.11-1_armel.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)
О-о ... куча Function not implemented
. Похоже, GLIBC сообщает, что основные вещи не работают ...
Мне удалось Трассирование (не спрашивайте , как) и выяснили , что все -at
функции терпят неудачу: openat
, mkdirat
, renameat
и т.д. - все они ENOSYS отчетности.
Похоже, что я добился лишь частичного успеха - некоторые системные вызовы не выполняются в моем новом GLIBC.
Нельзя ли скомпилировать a squeeze
или wheeze
GLIBC для выполнения под 2.6.17?
Любые идеи / указатели на то, что я сделал неправильно и / или как поступить, будут высоко оценены ...