Mipsel linux ��� ���

Building and packaging a mipsel-linux cross-compilation toolchain

The goal here is to build, from scratch, a suitable GNU compilation toolchain for some of our targets, based on little endian MIPS processors and running Linux (hence the mipsel-*-linux-gnu , or mipsel-linux for short architecture), though it is likely that the following would also work to build (big endian) mips-linux cross toolchains too.

The host computer will be a regular PC running Arch Linux. When building a cross compiler toolchain, a more complex terminology is used to refer to the involved architectures:

Versions

We want to reproduce the building environment of the rest of the target computer. We stick to the same version of the tools:

Building

As we plan future packaging, the files will be laid out in /usr for the host tools, and /usr/mipsel-linux for the needed target files (i.e. mostly the libc and include files).

binutils

The binutils are the simplest tools to build, only specifying the target and prefix will marvelously do the job.

Compilation problem

When compiling for the target using the freshly built binutils , one may enconter the following error message:

The problem is simple, as this only means that the binutils have not been correctly installed (or the autotools haven’t found them in the $PATH ), and the toolchain is using the host’s binutils instead of the mipsel-linux ones. A simple solution is to check the proper installation of the new utilities, eventually rebuilding them with the correct prefixes.

The C cross-compiler has to be compiled first, in order to be able to build the glibc for the target. It is mandatory to build gcc out of the original source tree (i.e. not even in a subdirectory of the source tree as it is “unsupported”). The building dir will be, originally, called gcc-build and share the same parent directory as the sources.

This will be a lightweight version of the compiler (no shared libraries nor threads support). The following assumes that the source tree has been extracted from the gcc-core package. In case the complete gcc source package has been fetched instead, be sure to provide the additional –enable-languages=c flag to the configure script.

It may be advisable to make symbolic links to the binaries in the target files directory:

glibc

The shared libraries support has been disabled in the bootstrap compiler, but we want to build a shared-libs enabled glibc. This will lead to problems as the linker will unsuccessfully search for libgcc_eh.a . A simple solution is to first make a dummy symbolic link to libgcc.a which will trick the linker.

As stated in this post on the linux-mips mailing list, applying a patch may be be necessary before compiling the c library. Practically, it turned out that this wasn’t necessary.

As for gcc, glibc has to be built in a separate directory. We’ll be using the same layout. After unpacking the glibc sources, one must remember, as the target is a Linux host, to extract the linuxthreads sources too.

The C library also needs kernel headers for the target machine. In this cas, this is Linux 2.4.27. It is necessary to configure the kernel for the headers to be in a valid state. The default parameters will be sufficient.

One can then start the building process.

Note that the –build and –host tags have to be specified instead of the –target one, which is not relevant. Also note that the prefix is /usr/mipsel-linux instead of the usual /usr as we do not want to overwrite our host’s libc with another version not compiled for the right architecture.

To complete the installation, it is necessary to copy some of the headers from the Linux source tree to the filesystem.

Linux-specific behavior

When building for a Linux host with a prefix set to /usr , instead of installing the libraries in /usr/lib , the building system will put them as the base libraries for the OS , in /lib , and update the linker scripts accordingly. You may get error messages like the following due to this.

This would be a sign that something went wrong and you may have to edit the linker script (like libc.so , GROUP line) to the correct paths… Or recompile your libc with correct parameters.

This problem, however, should not occur following the above building method.

gcc (the full monty)

This time, the full gcc source archive is needed. As before, the building process will take place in a directory different from that of the sources.

While trying to configure or build gcc, you may encounter these errors:

They may be due to a wrongly set C(XX)FLAGS environment option containing the -march=i686 flag. Be sure to properly set this variable (i.e. by removing said flag).

Packaging

binutils

The binutils provide a version of libiberty.a which is already present in the system. It is not necessary (and even possibly dangerous) to overwrite the preexisting version. It should be removed from the package.

The GNU Compiler Collection allso builds a version of libiberty.a , which should be removed from the package, as for the binutils. Also, some of the manpages are already present in the system and should be either removed or renamed in order not to cause conflicts when installing the package.

Thou shalt not strip my binaries

Beware of auto-stripping of the binaries. This package contains libraries for the target system like libgcc.a which provides basic functions too big to be inlined. Usually, strip recognizes binaries that are not in the correct format and prints a warning message before ignoring them. It happens, however, that strip actually does its jobs on some files on which it shouldn’t, overwriting the ELF header of these files with the wrong architecture.

When trying to cross compile for the target architecture and link against the defected libgcc.a , the problem can be spotted when this error message is displayed

Using objdump and grep to remove all correctly headed objects confirms the problem:

To solve the issue, it is necessary to prevent the packaging system from stripping all the binaries and libraries ( options=(NOSTRIP) for Arch Linux), eventually stripping manually those for which strip is safe (i.e. binaries and libs for the host machine).

glibc

When installing the libc in a alternative root, one must not use the usual DESTDIR make variable, but pass the path using install_root=… .

Some binaries for the target got creating during the build, and have been installed in /usr/mipsel-linux/ . They can be removed as the host computer will never be able nor need to run them. Infopages and locales information has also been generated but are not strictly necessary, it has then be decided to remove them from the final package

As before, libiberty.a and some manpage have to be removed or renamed from the final package

Errors when using the cross-compiler

Cannot find library whereas it is present

Sometimes, linking applications for the target arch may fail with the following message.

This can also be the cause of configure failing pretending the compiler cannot create executables.

This happens when using a relocated build environment for the target. That is, libraries have been built to be installed in / but where installed in, say, /sysroot/ on the build system. This usually does not cause any problem, except it some of the supposed library files are linker scripts (this seems to be really usual for libc6.so and libpthread.so ), e.g. /sysroot/usr/lib/libc.so :

Those script point the linker to the actual location of the desired libraries, but they may sometimes include full path to the object file, rather than relative location. Scripts with full path would then point the linker to the build system’s libraries instead of the target’s.

The cleanest solution to fix that is to modify those scripts to point to the actual location of the libraries on the build system. Here is an example shell script doing so. It depends on the file command identifying linker scripts as “ASCII C program text”, and relocates the scripts to point to $targetfs .

Libtool replaces a -lLIB flag with an absolute path to the build system’s native library

(Thanks to Sylvestre Ledru for pointing me in the very right direction.)

When linking using libtool, it sometimes happens that a command line that should have worked perfectly well, is replaced by one with some of the -lLIB arguments replaced by an absolute path to the system library /usr/lib/libLIB.so .

This is quite similar to the problem above and due to the relocation of the target’s sysroot as a subtree of the build host. Libtool is being wrongly redirected to an inapropriate library directory due to a script LIB.la , usually /usr/lib/libLIB.so like the following.

The source of the problem is on the last line, the libdir=’/usr/lib’ statement, which should obviously be replaced to point to the actual sysroot of the target system. Here is a sample bash script doing the work.

Источник

Пакет: gcc-mipsel-linux-gnu (4:10.2.0-1)

Ссылки для gcc-mipsel-linux-gnu

Ресурсы Debian:

Исходный код gcc-defaults-mipsen:

Сопровождающие:

Подобные пакеты:

GNU C compiler for the mipsel architecture

This is the GNU C compiler, a fairly portable optimizing compiler for C.

This is a dependency package providing the default GNU C cross-compiler for the mipsel architecture.

Другие пакеты, относящиеся к gcc-mipsel-linux-gnu

зависимости

рекомендации

предложения

enhances

• dep: cpp-mipsel-linux-gnu (= 4:10.2.0-1) GNU C preprocessor (cpp) for the mipsel architecture
• dep: gcc-10-mipsel-linux-gnu (>= 10.2.0-8

  ) GNU C compiler (cross compiler for mipsel architecture)

• rec: libc6-dev-mipsel-cross GNU C Library: Development Libraries and Header Files (for cross-compiling) или libc-dev-mipsel-cross виртуальный пакет, предоставляемый libc6-dev-mipsel-cross

• sug: autoconf automatic configure script builder
• sug: automake Tool for generating GNU Standards-compliant Makefiles
• sug: bison YACC-compatible parser generator
• sug: flex fast lexical analyzer generator
• sug: gcc-doc documentation for the GNU compilers (gcc, gobjc, g++)
• sug: gdb-mipsel-linux-gnu Пакет недоступен
• sug: libtool Сценарий сопровождения общих библиотек
• sug: make утилита управления компиляцией
• sug: manpages-dev Manual pages about using GNU/Linux for development

Загрузка gcc-mipsel-linux-gnu

Загрузить для всех доступных архитектур

Архитектура	Размер пакета	В установленном виде	Файлы
amd64	1,4 Кб	24,0 Кб	[список файлов]
arm64	1,4 Кб	24,0 Кб	[список файлов]
i386	1,4 Кб	24,0 Кб	[список файлов]
mips64el	1,4 Кб	24,0 Кб	[список файлов]
ppc64el	1,4 Кб	24,0 Кб	[список файлов]
x32 (неофициальный перенос)	1,4 Кб	24,0 Кб	[список файлов]

Эта страница также доступна на следующих языках (Как установить язык по умолчанию):

Чтобы сообщить о проблеме, связанной с веб-сайтом, отправьте сообщение (на английском) в список рассылки debian-www@lists.debian.org. Прочую контактную информацию см. на странице Debian Как с нами связаться.

Авторские права © 1997 — 2021 SPI Inc.; См. условия лицензии. Debian это торговый знак компании SPI Inc. Об этом сайте.

Источник

Ports/mipsel

Содержание

Состояние [ править ]

С марта 2018 года mipsel (32-битная little-endian MIPS) — официально поддерживаемая архитектура с репозиторием, который собирается в «догоняющем» режиме (sisyphus, p9).

Создана рассылка devel-sbc@ для разработчиков и активных пользователей одноплатных компьютеров.

Архитектура [ править ]

Пакеты собираются под архитектуру mipsel, o32 ABI, а точнее под mips32r2, что является общим знаменателем для P5600 (BE-T1000, ранее известный как Байкал-Т1) и Loongson III.

Репозитории [ править ]

Репозиторий доступен на ftp.altlinux.org и на большинстве зеркал в каталоге ports:

Обратите внимание: репозиторий подписан ключём secondary (догоняющей сборчницы, DB7335A9CF93543BA3E5033ACEA7F56E5689C9F0); этого ключа нет в пакете alt-gpgkeys в основном Сизифе, он есть только в версии пакета, собранной в sisyphus_mipsel.

На данный момент (2018-03-14) собрано более 9000 SRPM, из которых обычно отстают от основного Сизифа по EVR не больше сотни. Доступна статистика, в том числе подробно по пакетам (

Пакеты собираются на отдельной сборочнице, аналогичной Git.alt. В качестве сборочных узлов используются системы на Loongson 3A.

Сборка пакетов идёт в режиме «догоняющей сборочницы»: как только какое-то задание (task) проходит в основной Сизиф, специальный робот создаёт аналогичное задание в sisyphus_mipsel. Это означает, что никаких специальных усилий для сборки пакетов под mipsel предпринимать не нужно: собирайте в Sisyphus.

Задания подтверждаются вручную, обычно в тот же день или на следующий день. Если какого-то пакета не хватает (мы собираем не всё подряд) или он долго не обновляется, свяжитесь с iv@.

Если вы хотите собирать свои пакеты исключительно для архитектуры mipsel, иметь доступ к соответствующей сборочнице, свяжитесь с iv@ или glebfm@. Здесь имеются ввиду специфичные для архитектуры пакеты: ядра, драйвера, частично тулчейн и т.п, а также, например, пакеты, требующие бутстрапа на конкретной архитектуре.

Поддерживаемые платформы [ править ]

QEMU [ править ]

Используется ядро un-malta (mips64el). Доступны регулярные сборки. См. также Запуск в QEmu.

Таволга Терминал [ править ]

Используется для тестирования пакетов. Доступны регулярные сборки. См. также:

Плата BFK3 [ править ]

Плата с процессором BE-T1000 от Байкал Электроникс: BFK 3.1

Доступны регулярные сборки. Поддерживается использование видеокарт, в том числе некоторых ATI Radeon и SiliconMotion 750 — подробнее см. Видео на BFK3. Использование видеокарт на основе SM750 имеет свои особенности.

Loongson [ править ]

Системы с процессорами Loongson 3A используются как сборочные узлы, для тестирования и работы над пакетами. В репозитории для них есть ядро l3-def . Образы пока в разработке.

Как сообщить об ошибке [ править ]

Сообщения об ошибках принимаются по адресу https://bugzilla.altlinux.org/ (см. BugTracking).

• если проблема в пакете, выбирайте продукт Sisyphus, компонент соответсвующий имени пакета, платформа mipsel.
• если проблема в сборке или образе, выбирайте продукт Regular, компонент, сответствующий DE по умолчанию, платформа mipsel.

Источник