Как сделать по фен-шую

Задача собрать его под arm или другие неподдерживаемые архитектуры. Путем правки configure.ac.

А чем configure --host=arm ... не подходит?

cmake

Потому что не работает. В программе которую я портирую поддержки арма нет, надо портировать, в этом и задача.

Нет, надо портировать существующую программу. Мне что к чужому проекту на несколько десятков сорцовых файлов CMake скрипты писать?

Если можно поправить уже написанные autoconf.

То есть я поясню. В проекте уже есть файл configure.ac и там производятся проверки через AC_TRY_RUN, но поле кросс-компиляции там пустое. А значит в случае кросс-компиляции произойдет падание configure.

ну значит, открывай мануал autoconf, описание AC_TRY_RUN и читай, вдруг что полезное увидишь на тему кросскомпиляции

Да с AC_TRY_RUN все понятно. Там последним параметром надо дописать выставление параметров в нужное состояние. Вопрос не в этом. Эти значения надо где-то захардкодить. В самом configure.ac? Или можно как-то константы задать в отдельном файле. Вот собственно в этом мой вопрос.

привёл бы конкретный кусок configure.ac, c AC_TRY_RUN, чтоб более понятно было.

А так в чём проблема в самом макросе захардкодить?

AC_TRY_RUN(blah, blah, blah, HARDCODED_VALUE) ?

вполне в стиле autoconf.ac скриптов :)

вполне в стиле autoconf.ac скриптов :)

Ну таких кусков более 10ка и желательно сделать так, чтобы значение этих фич легко менялось. Потому что армы бывают разные, а возможно придется не только под арм собирать.

Кусок, да ради бога

  AC_MSG_CHECKING([if large (64-bit) files are supported on this system.])
  AC_CACHE_VAL([hdf5_cv_have_lfs],
    [AC_TRY_RUN([
      #include <stdio.h>
      #include <unistd.h>
      #include <stdlib.h>
      #include <fcntl.h>
      #define BIG_FILE (off_t)0x80000000UL
      int main(void) {
        int fd;
        if ((fd=open("test.conf", O_RDWR|O_TRUNC|O_CREAT, 0666)) < 0) exit(1);
        if (lseek(fd, BIG_FILE, SEEK_SET)!=BIG_FILE) exit(1);
        if (5!=write(fd, "hello", (size_t)5)) exit(1);
        if (lseek(fd, 2*BIG_FILE, SEEK_SET) != 2*BIG_FILE) exit(1);
        if (5!=write(fd, "hello", (size_t)5)) exit(1);
        if (unlink("test.conf") < 0) exit(1);
        exit(0);
      }
    ],[hdf5_cv_have_lfs=yes],[hdf5_cv_have_lfs=no],)])

Как видишь в конце после [hdf5_cv_have_lfs=no] пропущен параметр, по ману autoconf туда надо подставить код на случай кросс-компиляции. В случае если параметра нет и кросс-компиляция происходит, то configure выдает ошибку. Тут все ясно. Вопрос где задать эти значения? Пока мысль задать их в начале configure.ac хардкодом. А как реально такие ситуации обходятся в жизни? Ведь не создаются же разыне configure.ac под разные архитектуры. Надо универсально написать как-то.

Не мучайся с кросскомпиляцией. Сейчас 21й век на дворе, гигабайты стоят дешево. Используй qemu в user-mode.

Например, как тут: http://wiki.debian.org/QemuUserEmulation

Нужна кросс-компиляция. Это даже не обсуждается. В том то и дело.

Обоснуй. Зачем? Откуда такие идиотские требования?

Проектная необходимость. Собираемаый пакет - часть емедед дистрибутива. Собираемого через кросс-компиляцию.

Не канает на обоснование. Что, есть какие-то религиозные предубеждения против chroot? Ну так на это mount --bind имеется. Какая тебе вообще разница, как конкретно твой cross toolchain устроен - под эмуляцией он работает, или нативный?

Потому что это готовый тулчейн для построения дистрибутива. Скачал арихвчик, зашел. Поправил конфиги, добавил новые правила сборки, если надо, запустил команду - получил образ linux дистрибутива под любую архитектуру, которую указал или в конфиге или при выборе. Все. Даже никаких компиляторов ставить левых не надо, сами собирутся в процессе построения. Так должно быть. Таков проект. Делать по другому просто нельзя.

Тьфу ты посмотрел на этот ад, кажется реально проще простенький cmake скрипт накидать.

Продолжаю ни хрена не понимать.

Не вижу, как такая постановка задачи противоречит использованию эмулируемого toolchain-а. Кто тебе мешает в процессе построяния собрать еще и qemu? Ну а rootfs у тебя и так собирается, ничего дополнительного не нужно. Еще, если ты не понял, сам кросскомпилятор вовсе не обязательно собирать под arm, можешь оставить ровно тот, что используешь для всего остального (gcc, собранный под arm, будет под qemu безжалостно тормозить). Посмотри, как устроен scratchbox и ему подобные системы.

Потому что так работать не должно. Таков проект, такие в нем принципы. Из-за мелкого пакета я сборку в виртуалке не буду предлагать. Проект крупный. Там сотни пакетов собираются в кросс-компиляции, а я ради одного буду все переделывать. Успокойся. не будет этого.

Простенький не выйдет. Тут надо просто выяснить фичи и прописать их как следует. А с симейком придется делать и это и все с нуля еще.

Потому что так работать не должно. Таков проект, такие в нем принципы.

То есть, все таки религия. Смешно.

Из-за мелкого пакета я сборку в виртуалке не буду предлагать.

А что такого-то? Повторяю для медленных: rootfs у тебя УЖЕ есть. Кросскомпилятор УЖЕ есть. Тебе нужен только qemu, чтобы это заработало. Ты бы потратил на реализацию всего этого дела меньше времени, чем уже потратил на этот тред.

Мне за такое руки оторвут, это же не мой проект. И даже не моего руководителя.

Алсо ты понимаешь, что я должен не бинарный дистр поставить. А написать правила для этого проекта? Чтобы оно собиралось у Васи Пупкина, по сути я пишу систему сборки для емедед дистра. То есть никакие левые сборки в виртуалке конечному пользователю не нужны.

Мне за такое руки оторвут, это же не мой проект. И даже не моего руководителя.

За какое «за такое»? Сам сказал, что toolchain собирается в процессе сборки всего проекта. Так какая тогда разница-то?

И этот подход, кстати, может существенно упростить сборку многих других пакетов. Например, тот же Python чуваки из Linaro собирают всегда именно так.

То есть никакие левые сборки в виртуалке конечному пользователю не нужны.

Вся разница между обычной кросс-компиляцией и такой только в необходимости chroot-а. У твоего Васи Пупкина нет рутовых прав, что ли?

Допустим нет. И qemu собирать он может не хочет. Это излишне.

То есть, собирать binutils и gcc ему не в падлу, а крошечный qemu с одним единственным arm-ом - «излишне»? Странный ты. Похоже, до сих пор так и не понял, как работает user-mode qemu.

Вы уверены что проблема именно в этом, что за программа, если не секрет?
По роду своей деятельности постоянно собираю программы под ARM и что-то не припомню таких сложностей.

Там была тулза, которая автолулз проекты в cmake конвертила.

Вот тут скрипты есть, по идеи все тесты умеют конвертить. http://www.cmake.org/Wiki/CMake#automake.2Fautotools.2Fautoconf

Да я руками cmakelists'ы для весьма сложных вещей писал, не такой уж и ад. С конвертилкой это быстро получится, а потом напильником можно будет подточить. Но сейчас многие с autotools'ов сбегают. Тот же llvm/clang.

Да я уверен, что в этом. Дока по autoconf ясно говорит, что у TRY_RUN последнее поле код, выполняемый при кросс-компиляции и если оно пустое, то configure выдаст ошибку. И в этом проекте оно во всех случаях пустое. Проект hdf5 - либа такая, вообще там вроде смесь cmake и autoconf, но с autoconf все вроде просто, как сделать вроде догадываюсь. Только вот думаю как красивее сделать, выяснить фичи арма и захардкодить их вначале configure.ac это легко. Но может есть более трушный способ хардкодить такие вещи? Например внешний файл, который выбирается в зависимости от таргет архитектуры? Такого нет?

Ну проект просто разработчиками не расчитывался на кросс-компиляцию вот и все. Мне и надо его как раз собрать, а потом если чо не будет работать, то и подработать напильником.

То есть, собирать binutils и gcc ему не в падлу

Оно собирается, автоматически и ими же собирается сотня других пакетов. Короче успокойся, собирать в виртуалке я не буду.

Да что ты заладил, «собирать в виртуалке», «собирать в виртуалке». Ты просто вообще не понял, как работает user-mode qemu. Зря ленишься включить голову, это решило бы многие твои проблемы.

Как ты на билд-машине будешь запускать неродной бинарник?

Делай ./configure hdf5_cv_have_lfs=yes и не парься

P. S. или hdf5_cv_have_lfs=no, если не поддерживается на хост-машине.

блин ну неужели еще раз! Я так и хочу делать! Я не собираюсь пускать неродной бинарник не собираюсь! Я уже раз 20 повторил, что хочу поступить как ты мне предлагаешь, но спросил как это сделать покрасивее. Собственно последний параметр у TRY_RUN и есть захардкоживание переменной, так как запустить неродной бинарник нельзя. Мой вопрос в том, можно ли сделать это красивее? Чтобы было допустим к configure.ac еще файлики для арм, ppc и других? Если так никак, то ок.

Или единственное решение использовать разные configure.ac для разных архитектур? Нельзя ли обойтись одним + файлы со значениями констант? Если так нельзя, а я не нагуглил такого, то вопрос закрыт и я буду делать как есть. Это просто, точнее configure.ac по сути УЖЕ ГОТОВ у меня, но мне захотелось сделать более изящно, а не размышлять о том как собрать под арм. Вот в чем вопрос. Все уже сделано, но хочется сделать лучше.

Ты бы уже десять раз успел на scratchbox все сделать, прозрачно и безопасно. Ну ладно, раз ты такой не ленивый, развлекайся. Дураков работа любит.

Running Test Programs

Use the following macro if you need to test run-time behavior of the system while configuring.

Macro: AC_TRY_RUN (program, @ovar{action-if-true}, @ovar{action-if-false}, @ovar{action-if-cross-compiling})
program is the text of a C program, on which shell variable and back quote substitutions are performed. If it compiles and links successfully and returns an exit status of 0 when executed, run shell commands action-if-true. Otherwise, run shell commands action-if-false; the exit status of the program is available in the shell variable `$?'. This macro uses CFLAGS or CXXFLAGS, CPPFLAGS, LDFLAGS, and LIBS when compiling.

If the C compiler being used does not produce executables that run on the system where configure is being run, then the test program is not run. If the optional shell commands action-if-cross-compiling are given, they are run instead. Otherwise, configure prints an error message and exits.

Try to provide a pessimistic default value to use when cross-compiling makes run-time tests impossible. You do this by passing the optional last argument to AC_TRY_RUN. autoconf prints a warning message when creating configure each time it encounters a call to AC_TRY_RUN with no action-if-cross-compiling argument given. You may ignore the warning, though users will not be able to configure your package for cross-compiling. A few of the macros distributed with Autoconf produce this warning message.

To configure for cross-compiling you can also choose a value for those parameters based on the canonical system name (see section Manual Configuration). Alternatively, set up a test results cache file with the correct values for the host system (see section Caching Results).

To provide a default for calls of AC_TRY_RUN that are embedded in other macros, including a few of the ones that come with Autoconf, you can call AC_PROG_CC before running them. Then, if the shell variable cross_compiling is set to `yes', use an alternate method to get the results instead of calling the macros.

отседова
осталось выяснить, как set up a test results cache file with the correct values for the host system. ;) в этом случае не придется делать pessimistic defaults в виде третьего параметра, если я правильно понял.

О, спасибо! Завтра посмотрю.

Некошерно. Собирай на arm.