Что было бы призрачным примером вариантов sysroot и prefix для Qt

Я просматриваю все параметры, которые могут быть запущены для configure script с Qt. (в частности, qt-везде-opensource-src-5.2.0).

После значительного поиска я решил, что этот материал плохо документирован в лучшем случае, поэтому я надеялся, что смогу помочь. Когда я смотрю описания опций конфигурации prefix и sysroot:

~/qt-везде-opensource-src-5.2.0 $./configure -help | grep "sysroot"
    -extprefix <dir>... Когда используется -sysroot, установите все в <dir>,
    -sysroot <dir>...... Устанавливает <dir> в качестве целевого компилятора и qmake sysroot, а также устанавливает пути pkg-config.
    -no-gcc-sysroot..... При использовании -sysroot он отключает передачу --sysroot в компилятор

~/qt-везде-opensource-src-5.2.0 $./configure -help | grep "prefix"
    -prefix <dir>...... Это установит все относительно <dir>
    -extprefix <dir>... Когда используется -sysroot, установите все в <dir>,
    -hostprefix [dir].. Инструменты и библиотеки, необходимые при разработке

Итак, я использовал -prefix раньше, и он сделал точно так, как описано. Он разместил все на предоставленном <dir>, затем, когда я построил свое приложение с помощью <prefix_dir>/bin/qmake и установил его на моей целевой платформе, он захотел найти все библиотеки общих объектов в <prefix_dir>/lib.

У меня под впечатлением, что если я использую -sysroot, он установит все в <sysroot_dir>, а затем, установив приложение на целевую платформу, он будет искать в /lib. По крайней мере, я надеюсь, что это правда.

Теперь, если мое предположение верно... то какая точка -extprefix? Они говорят, что если я могу перенаправить туда, где все хорошо, если я использую как -sysroot, так и -extprefix?

И для чего я хотел бы использовать -no-gcc-sysroot? Если бы я хотел, чтобы мои Qt-библиотеки были установлены на "sysroot", почему я не хочу, чтобы gcc использовал/знал один и тот же sysroot?

Объяснение некоторых из них было бы замечательным, даже лучше, если я смогу получить некоторые практические примеры того, как правильно использовать эти параметры.

Ответы

Ответ 1

Это параметры, которые используются при создании встроенных платформ. Да, это королевский беспорядок. Итак, вот только частичный ответ:

-prefix

  • проверенный способ сказать /usr/lib вместо/usr/local/lib или аналогичный для всей установки Qt
  • когда Qt построен для платформы, на которой он в настоящее время работает (типичный для рабочего стола)

-sysroot/path

  • намеревается построить Qt для системы, которая не установлена ​​на/
  • например -sysroot ~/mysystem где ~/myssytem содержит /lib/bin и т.д.
  • передаст --sysroot другим инструментам, таким как gcc и pkg-config, поэтому они будут искать свои зависимости в ~/mysystem/lib, а не /lib

-extprefix/b

  • при использовании -sysroot/a, на самом деле не пишите в /a
  • напишите qt в /b вместо
  • это предназначено для кросс-компиляции с использованием только для чтения sysroots

-по-НКУ-SYSROOT

  • очень специфический взлом для компиляторов, которые не могут найти свой собственный crt внутри --sysroot
  • передает sysroot в pkgconfig и другие, но не gcc
  • так что gcc будет вызван с -L/sysroot/lib/правильно, но не пытается найти здесь неявные пути (crt).

-hostprefix/path

  • при компиляции для другой цели, чем мы в настоящее время выполняем
  • qmake будет главной архитектурой (например, x86), а сама qt будет целевой архитектурой (скажем, рука).
  • то поставьте qmake в /path вместо целевой системы, заданной -sysroot. он не будет полезен в целевой системе.

Чтобы добавить к путанице:

-R/путь

  • задает путь компоновщика ссылок - вот где QtGui находит QtCore, например, независимо от всех других опций.

Какие флаги, которые вы хотите использовать при компиляции для цели, а не вашего хоста, зависят от загрузки жестко запрограммированных допущений внутри configure.

Обычно -sysroot plus -prefix должен работать для большинства случаев использования.

то есть. когда у вас есть:

 $ ls ~/mytarget
 lib bin share dev

вы можете просто использовать -sysroot ~/mytarget -prefix/

Ответ 2

Одним из практических примеров может быть кросс-компиляция Qt для малины Pi, а затем создание набора "сестра" для добавления в Qt Creator.

Следующая команда устанавливает Qt на Pi после установки корневой файловой системы Pi:

    ./configure -opengl es2 -device linux-rasp-pi-g++ -device-option CROSS_COMPILE=$RPI_TOOLCHAIN -sysroot $RPI_SYSROOT -opensource -confirm-license -optimized-qmake -reduce-exports -release -make libs -prefix /usr/local/qt-5.5.1-pi -skip qtwebkit

Следующая команда затем устанавливает двоичные файлы на рабочем столе с помощью корневой файловой системы Pi.

    ./configure -opengl es2 -device linux-rasp-pi-g++ -device-option CROSS_COMPILE=$RPI_TOOLCHAIN -sysroot $RPI_SYSROOT -opensource -confirm-license -optimized-qmake -reduce-exports -release -make libs -extprefix /usr/local/qt-5.5.1-pi -skip qtwebkit

Обратите внимание, что единственное различие заключается в использовании -extprefix вместо -prefix, который направляет местоположение установки.

Примечание. Вы можете установить Qt на хост и цель одновременно, указав оба префикса и extprefix в той же строке

Теперь вы можете добавить этот комплект в свой Qt Creator, указав свой путь qmake, устройство, компилятор, отладчик и sysroot. Таким образом, вы можете создать проект qt на своем рабочем столе, а затем создать и запустить либо на рабочем столе, либо на pi в зависимости от выбранного вами набора.