кросскомпиляция под другую систему.

1)ARCH=...
2)./configure --help

configure --sysroot=/usr/local/root --host=arm-unknown-linux-eabi , переменные SYSROOT и CHOST
gcc --sysroot=/usr/local/root/usr/bin/gcc и т.п.

В Gentoo, к примеру, есть пакет sys-devel/crossdev, который устанавливает скрипты, среди которых есть автоматизированная сборка кросскомпилятора под нужную целевую архитектуру скриптом crossdev, плюс самое интересное, скрипты-обёртки над стандартым пакетным менеджером, вроде emerge-i686-pc-mingw32 (обёртка над cross-emerge, который сам по себе есть обёртка над стандартным emerge, который, в свою очередь, через /usr/bin/ebuild есть обёртка над ./configure .. && make && make install)

Обёртки работают так: устанавливают переменные SYSROOT с образом целевой системы (chroot в этот SYSROOT — будет корень целевой системы), CHOST, и запускают сборку через emerge/ebuild. /usr/bin/ebuild в конечном итоге распаковывает архив с исходниками во временный каталог в /var/tmp/portage, делает «sandbox» для сборки, вызывает ./configure с нужными ключами, собирает, устанавливает во временный каталог, сливает из временного каталога в корень системы, отмечает установленный пакет в world файле, базе пакетного менеджера.

Также, хорошие пакетные менеджеры в этом плане packman в Arch и Nix в NixOS — именно для кросскомпиляции, легко затачиваются.
gcc с ключом -B или, более новый, --sysroot используется для вызова нужной версии gcc, под целевую архитектуру. Например, -B используется при компиляции самого кросскомпилятора.

crossdev howto из Gentoo:
http://www.gentoo.org/proj/en/base/embedded/cross-development.xml

оно не очень Gentoo специфичное, просто под другими системами эти действия надо будет сделать вручную. Фактически crossdev в Gentoo создаёт базу пакетного менеджера под целевую систему, и собирает под целевую систему обёрткой над emerge, почти как обычно. Посмотри, может что-то по советам оттуда и тебе пригодится, вроде указать нужные ключики к configure/gcc.

В итоге, можно довольно просто собирать под целевой Linux под другую архитектуру вроде Arm (твой случай) и проверять собранное в виртуальной машине с нужного chroot корня, либо, собирать вообще под другую ОС (стандартно есть Gentoo/FreeBSD, но я пробовал пособирать под Windows mingw-ом, и под Haiku кросстулчейном из её состава).
Получилось, только с другими целевыми ОС, не Линукс есть заморочки — нужно фактически нормально портировать софт, нормально следить за пакетами-зависимостями, в общем, по идее, делать нормальный Alt prefix. Это в перспективе.
А если просто пособирать два пакетика, подойдёт и paludis — для него аналогично можно настроить обёртки для кросссборки, но что самое полезное, в paludis есть утилита importare, которая просто позволяет собрать руками и отметить собранное в пакетном менеджере, как будто это нормальный пакет, не делая для этого рецептов сборки-ебилдов, не возясь с зависимостями, патчами, и т.п. Просто образ, как есть.

В общем, сrossdev из Gentoo автоматизирует львиную долю ручной работы, собирает обычным пакетным менеджером, создаёт отдельно образ собранной целевой системы, и профиль пакетного менеджера для кросссборки, целевого.
Если собираешь из Линукса в Линукс, проблем нет никаких, отображение исходный пакетный менеджер-целевой 1:1, разве что тестировать надо под виртуальной машиной либо под реальной железкой.
Если собираешь из Линукса в другую ОС, тут начинается секс с профилем целевого пакетного менеджера. Например. в FreeBSD есть свой libc, не gnu glibc. И поэтому для системного софта есть соответствующий USE-флаг: выключается под линуксом, включается под FreeBSD.
Если ОС совсем другая, например, Haiku или Windows, то имеем секс со структурой пакетов, отображение может быть сложное, не 1:1. Например, x11-libs/qt в целевой ОС Windows может называться по-другому, но тогда все зависимости придётся переделывать. Если оставить как есть, то поскольку x11-libs/qt зависит от x11-base/xorg-server в базовой системе, в целевой появится фейковый виртуальный пакет-пустышка x11-base/xorg-server (если к примеру, виндовый qt собирается не под X-сервер). С portage тут сложно всё, нужен какой-то term rewriting для пакетов-зависимосей, либо лепить кучу фейковых пакетов. Ещё надо как-то выбирать конкретные портированные версии пакетов, либо патчиками + USE-флагами, либо брать версию из конкретного своего оверлея (portage ЕМНИП, не умеет, зато умеет paludis). Под Paludis есть importare, да.

Nix в этом смысле очень перспективный пакетный менеджер: зависимости в его пакетах как-то меньше ОСе-специфичны. Плюс, для Nix есть Hydra — continuous integration build farm, что само по себе удобно и интересно.

В общем, совет такой: прочитай Gentoo crossdev howto, разберись со скриптами-обёртками, как они работают, и в конечном итоге, с ключиками в configure --sysroot и -B и --sysroot в gcc.
Пакетным менеждером под целевую систему можно собирать и потом, когда отработаешь механизм вручную.

> а как заставить его искать все зависимости в /usr/local/root?
Возможно поможет ещё это:
CFLAGS="-L/usr/local/root/lib -I/usr/local/root/usr/include"