1.5. Сборка сложного приложения из командной строки
1.5. Сборка сложного приложения из командной строки
Проблема
Вы хотите использовать для сборки исполняемого файла, зависящего от нескольких статических и динамических библиотек, инструменты командной строки.
Решение
Начните со сборки статических и динамических библиотек, от которых зависит ваше приложение. Если библиотеки получены от сторонних разработчиков, следуйте инструкциям, поставляемым с этими библиотеками; в противном случае соберите их так, как описано в рецептах 1.3 и 1.4.
Затем скомпилируйте в объектные файлы .cpp-файлы своего приложения, как описано в разделе «Сборка простой программы «Hello, World» из командной строки». Чтобы сказать компилятору, где искать заголовочные файлы, требуемые для вашего приложения, используйте опцию -I, как показано в табл. 1.12.
Табл. 1.12. Указание директорий для поиска заголовочных файлов
Инструментарий Опция Все -I<директория>Наконец, для создания исполняемого файла из набора объектных файлов и библиотек используйте компоновщик. Для каждой библиотеки вы должны либо указать ее полный путь и имя, либо сказать компоновщику, где ее искать.
На каждой стадии этого процесса при использовании инструментария, поставляемого со статическим и динамическим вариантами рабочих библиотек, и если программа использует хотя бы одну динамическую библиотеку, вы должны указать компилятору или компоновщику использовать динамическую библиотеку времени выполнения, как описано в рецепте 1.23.
Таблица 1.13 предоставляет команды для компоновки приложения hellobeatles из примера 1.3. Она предполагает, что:
• текущей директорией является hellobeatles;
• статическая библиотека libjohnpaul.lib или libjohnpaul.а была создана в директории johnpaul;
• динамическая библиотека georgeringo.dll, georgeringo.so или georgeringo.dylib и, если есть, ее библиотека импорта были созданы в директории georgeringo.
Табл. 1.13. Команды для компоновки приложения hellobeatles.exe
Инструментарий Входные файлы Командная строка GCC (Unix) hellobeatles.o libjohnpaul.a libgeorgeringo.so g++ -о hellobeatles hellobeatles.o -L ./johnpaul -L./georgeringo -ljohnpaui -lgeorgeringo или g++ -o hellobeatles hellobeatles.o ./johnpaul/libjohnpaul.a ./georgeringo/libgeorgeringo.so Intel (Linux) icpc -o hellobeatles hellobeatles.o -L./johnpaul -L./georgeringo -ljohnpaul -lgeorgeringo или icpc -о hellobeatles hellobeatles.o ./johnpaul/libjohnpaul.a ./georgeringo/libgeorgeringo.so Comeau (Unix) como -no_prelink_verbose -o hellobeatles hellobeatles.o -L./johnpaul L./georgeringo -ljohnpaul -lgeorgeringo или como -no_prelink_verbose -o hellobeatles hellobeatles.о ./johnpaul/libjohnpaul.a ./georgeringo/libgeorgeringo.a GCC (Mac OS X) hellobeatles.о libjohnpaul.a libgeorgeringo.dylib g++ -o hellobeatles hellobeatles.o -L/johnpaul -L./georgeringo -ljohnpaul -lgeorgeringo или g++ -o hellobeatles hellobeatles.o ./johnpaul/libjohnpaul.a ./georgeringo/libgeorgeringo.dylib Metrowerks (Mac OS X) mwld -o hellobeatles hellobeatles.о -search -L/johnpaul -search -L ./georgeringo -ljohnpaui -lgeorgeringo или mwld -о hellobeatles hellobeatles.о ./johnpaul/libjohnpaul.a ./georgeringo/libgeorgeringo.dylib GCC (Cygwin) hellobeatles.о libjohnpaul.a libgeorgeringo.dll.a g++ -о hellobeatles hellobeatles.o -L./johnpaul -L./georgeringo -Ijohnpaul -Igeorgeringo или g++ -o hellobeatles hellobeatles.о ./johnpaul/libjohnpaul.a ./georgeringo/libgeorgeringo.dll.a GCC (MinGW) hellobeatles.о libjohnpaul.a libgeorgeringo.a g++ -o hellobeatles hellobeatles.o -L./johnpaul -L./georgeringo -Ijohnpaul -Igeorgeringo или g++ -о hellobeatles hellobeatles.o ./johnpaul/libjohnpaul.a. /georgeringo/libgeorgeringo.a Visual C++ hellobeatles.obj libjohnpaul.lib libgeorgeringo.lib link -nologo -out:hellobeatles.exe -libpath:./johnpaul -libpath:./georgeringo libjohnpaul.lib libgeorgeringo.lib hellobeatles.obj Intel (Windows) xilink -nologo -out:hellobeatles -libpath:./johnpaul -libpath:./georgeringo.lib johnpaul.lib libgeorgeringo.lib hellobeatles.obj Metrowerks (Windows) mwld -o hellobeatles -search -L./johnpaul libjohnpaul.lib -search -L./georgeringo libgeorgeringo.lib hellobeatles.obj Metrowerks (Mac OS X)? mwld -o hellobeatles hellobeatles.o -search -L./johnpaul -search -L./georgeringo libjohnpaul libgeorgeringo.dylib CodeWarrior 10.0 (Mac OS X)? Сверьтесь с документацией Metrowerks Borland bcc32 -q -WR -WC -ehellobeatles -L./johnpaul -L./georgeringo/libjohnpaul.lib libgeorgeringo.lib hellobeatles.obj Digital Mars link -noi hellobeatles.obj,hellobeatles.exe,NUL,user32.lib kernel32.lib ..johnpaul .georgeringolibjohnpaul.lib libgeorgeringo.lib,, или link -noi hellobeatles.obj,hellobeatles.exe,NUL,user32.lib kernel32.lib ..johnpaullibjohnpaul.lib ..georgeringolibgeorgeringo.lib,, Comeau (Windows) hellobeatles.obj libjohnpaul.lib libgeorgeringo.lib como -no_prelink_verbose -o hellobeatles ./johnpaul/libjohnpaul.lib ./georgeringo/libgeorgeringo.lib hellobeatles.obj? При сборке с помощью указанной командной строки hellobeatles может работать неправильно, так как это приложение будет использовать две копии рабочих библиотек Metrowerks. (См. рецепт 1.23.)
? CodeWarrior 10.0 для Mac OS X будет содержать динамический вариант своих библиотек. При сборке hellobeatles следует использовать именно их. (См. рецепт 1.23.)
Например, при использовании Microsoft Visual Studio .NET 2003 и если она установлена в стандартную директорию на диске С, чтобы собрать hellobeatles.exe из командной строки, перейдите в директорию hellobeatles и введите следующие команды.
> "С:Program FilesMicrosoft Visual Studio .NET 2003VCinvcvars32.bat"
Setting environment for using Microsoft Visual Studio 2005 tools.
(IF you have another version of Visual Studio or Visual C++ installed
and wish to use its tools from the command line, run vcvars32.bat for
that version.)
> cl -c -nologo -EHsc -GR -Zc:forScope -Zc:wchar_t -MD -I.. -Fohollobeatles hellobeatles.cpp
hellobeatles.cpp
> link -nologo -out:hellobeatles.exe -libpath:../johnpaul -libpath:../georgeringo libjohnpaul.lib libgeorgeringo.lib
> hellobeatles.obj
Обсуждение
Поиск включенных заголовочных файлов
Опция -I используется для указания пути, где находятся заголовочные файлы. Когда компилятор — а на самом деле препроцессор — встречает директиву include в виде:
#include "file"
он обычно пытается вначале найти подключаемый файл, интерпретируя указанный путь относительно директории, в которой находится обрабатываемый исходный файл. Если этот поиск не дает результатов, он пытается найти этот файл в одной из директорий, указанных в опции -I, а затем в директориях, указанных в инструментарии, который часто настраивается с помощью переменных среды.
Эта ситуация аналогична включению заголовочного файла с помощью угловых скобок, как здесь:
#include <file>
за исключением того, что обычно компиляторы не интерпретируют указанный таким образом путь относительно местоположения обрабатываемого исходного файла.
Передача библиотек компоновщику
Есть несколько интересных аспектов, связанных с командными строками из табл. 1.13.
В Windows вход компоновщика состоит из объектных файлов, статических библиотек и библиотек импорта. В Unix он состоит из объектных файлов, статических и динамических библиотек.
Как в Windows, так и в Unix библиотеки могут передаваться компоновщику двумя способами:
• с помощью указания пути в командной строке;
• с помощью указания только имени библиотеки и места поиска библиотек.
Таблица 1.13 иллюстрирует оба метода.
Места поиска библиотек обычно могут быть указаны в командной строке. Большинство компоновщиков для этой цели используют опцию -L<directory>, но Visual C++ и Intel для Windows используют опцию -lipath: <directory>, a Metrowerks использует опцию -search -L<directory>. Компоновщик Digital Mars позволяет указывать пути поиска библиотек в командной строке вместе с файлами библиотек, при условии, что пути поиска отличаются от файлов библиотек завершающей обратной косой чертой. Также он требует, чтобы эти обратные слеши использовались как разделители в путях.
Кроме явно указанных директорий компоновщики обычно используют список собственных директорий, который часто может быть настроен с помощью переменных среды. В Windows список директорий обычно включает lib-поддиректорию пути установки инструментария. В результате, если скопировать .lib-файлы в эту директорию, их можно будет указать в командной строке по имени, не указывая их местоположения. Если объединить этот метод с действиями, описанными в рецепте 1.25, то можно вообще избежать передачи компоновщику какой-либо информации о библиотеке.
Способ, которым имя библиотеки передается компоновщику, для Unix и Windows различается. В Windows указывается полный путь библиотеки, включая расширение файла. В Unix — и в Windows при использовании инструментария GCC — библиотеки указываются с помощью опции -l, за которой следует имя библиотеки с удаленными из него расширением файла и префиксом lib. Это означает, что для того, чтобы компоновщик автоматически находил библиотеку, ее имя должно начинаться с префикса lib. Еще интереснее то, что это дает компоновщику возможность выбрать между несколькими версиями библиотек. Если компоновщик находит как статическую, так и динамическую версии библиотеки, выбирается, если не указано другого, динамическая библиотека. На некоторых системах компоновщик может выбрать между несколькими версиями динамической библиотеки, используя часть имени файла, за которой следует .so.
Наконец, будьте осторожны, так как компоновщики Unix могут быть очень чувствительны к порядку, в котором в командной строке указаны объектные файлы и статические библиотеки: если статическая библиотека или объектный файл ссылаются на символ, определенный во второй статической библиотеке или объектном файле, первый файл должен быть указан в командной строке до второго. Чтобы разрешить круговые зависимости, иногда требуется указать библиотеку или объектный файл несколько раз. Еще одним решением является передача последовательности из объектных файлов и статических библиотек компоновщику обрамленными в -( и -). Это приведет к тому, что поиск в файле будет производиться до тех пор, пока не будут разрешены все зависимости. Этой опции по возможности следует избегать, так как она значительно снижает производительность.
Запуск вашего приложения
Если ваше приложение использует динамический вариант библиотеки времени исполнения инструментария, то эта библиотека должна быть доступна приложению при его запуске и должна находиться в таком месте, где динамический загрузчик операционной системы сможет автоматически найти ее. Обычно это означает, что динамическая библиотека времени исполнения должна находиться либо в той же директории, что и ваше приложение, либо в одной из директорий, указанных системе. Это больше относится к разработке для Windows, чем для Unix, так как в Unix соответствующие библиотеки обычно уже установлены по правильным путям. Имена динамических библиотек времени исполнения, поставляемых с различным инструментарием, приведены в рецепте 1.23.
Смотри также
Рецепты 1.10, 1.13, 1.18 и 1.23.