GNU/Linux Qt5.* - Линкуем статически

@gromo · Регистрация: 04.09.2009

Студворк — интернет-сервис помощи студентам

В связи с отсутствием в данной теме мануала по статической линковке приложений Qt, решил исправить данный недостаток

Оговорюсь сразу: приветствуется беспощадная критика, особенно, что касается скриптов)
Итак:
1) Как обычно, нужно пересобрать фреймвор статически. Для этого скачиваем архив с исходными текстами отсюда: http://qt-project.org/downloads
На данный момент имя тар-бола - qt-everywhere-opensource-src-5.2.0.tar.gz

2) Переходим в каталог с тар-болом. Разархивируем и распаковываем. Потом нужно сконфигурировать, собрать и установить тонну исходников. Делаем это так ( за дополнительными параметрами, если нужно, обращайтесь ./configure --help):

Bash
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
tar -xzvf qt-everywhere-opensource-src-5.2.0.tar.gz && cd qt-everywhere-opensource-src-5.2.0 \
&& sudo mkdir -p /usr/lib/Qt5_static && ./configure -platform linux-g++ \
-release \
-static \
-fontconfig \
-opensource \
-confirm-license \
-nomake examples \
-c++11 \
-nomake tests \
-qt-zlib \
-qt-libpng \
-qt-libjpeg \
-prefix /usr/local/Qt5_static \
&& make -j3 && make install

Code
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
Объяснение опций:
-platform linux-g++ \ # Ваша платформа и компилятор
-release \ # Собираем для релиза
-static \ # Собственно, наша цель собрать статически
-fontconfig \ # Поддержка собственного fontconfig
-opensource \ # СПО версия
-confirm-license \ # Сразу согласиться с лицензией
-nomake examples \ # Не собирать учебные примеры
-c++11 \ # Поддержка последнего стандарта
-nomake tests \ # Не проводить тесты
-qt-zlib \ # Внедрение собственной библиотеки <libname>
-qt-libpng \ # ...
-qt-libjpeg \ # ...
-prefix /usr/local/Qt5_static \ # Относительно этого пути будет производиться установка (можете свой указать)
make -j3 # количество ядер процессора +1

3) Так, теперь у нас есть все необходимые инструменты (почти

)
Заходим в QtCreator, Tools > Options > Build & Run > Qt Versions
Добавляем путь к новому qmake ( в нашем случае /usr/local/Qt5_static/bin/qmake ).
Затем идем на вкладку Kits и добавляем новый набор инструментов, только укзываем ему qmake, только что добавленный на предыдущем шаге. Озаглавим этот набор Qt5_staticKit, например. Нажимаем Ok.
4) Ctrl+5, выбираем вверху проект, который мы хотим собрать статически, и щелкаем по новому Kit'y Qt5_staticKit. Выбираем Release конфигурацию. Тааак, здесь пока все.
5) Перелазим в .pro file. Добавляем туда

Code
1
2
3
QMAKE_LFLAGS += -s # Убрать все таблицы символов из результирующего бинарника ( man gcc )
# 3-rd party библиотеки, (boost, gmp, ... ) если есть статический вариант добавляем так:
LIBS += -Wl, -Bstatic, -lboost_regex, -lgmp, -lgmpxx, -Bdynamic

Теперь все Qt и 3-rd party библиотеки сидят в бинарнике, НО дело еще не закончено.

Если посмотреть на вывод ldd, то можно увидеть, что приложение зависит еще от целой кучи не Qt-ных библиотек. Они могут быть бинарно-несовместимыми со своими предыдущими версиями (особенно, если написаны на С++) даже если они имеются на чужом компьютере.
Например:

Кликните здесь для просмотра всего текста

Bash
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
ldd traditional
        linux-vdso.so.1 (0x00007fffd05fe000)
        libgobject-2.0.so.0 => lib/libgobject-2.0.so.0 (0x00007fe1a298a000)
        libX11-xcb.so.1 => lib/libX11-xcb.so.1 (0x00007fe1a2788000)
        libXi.so.6 => lib/libXi.so.6 (0x00007fe1a2578000)
        libxcb-render-util.so.0 => lib/libxcb-render-util.so.0 (0x00007fe1a2375000)
        libSM.so.6 => lib/libSM.so.6 (0x00007fe1a216d000)
        libICE.so.6 => lib/libICE.so.6 (0x00007fe1a1f51000)
        libxcb-glx.so.0 => lib/libxcb-glx.so.0 (0x00007fe1a1d39000)
        libxcb-render.so.0 => lib/libxcb-render.so.0 (0x00007fe1a1b2f000)
        libxcb-keysyms.so.1 => lib/libxcb-keysyms.so.1 (0x00007fe1a192d000)
        libdbus-1.so.3 => lib/libdbus-1.so.3 (0x00007fe1a16e5000)
        libxcb.so.1 => lib/libxcb.so.1 (0x00007fe1a14c5000)
        libxcb-image.so.0 => lib/libxcb-image.so.0 (0x00007fe1a12c1000)
        libxcb-icccm.so.4 => lib/libxcb-icccm.so.4 (0x00007fe1a10bd000)
        libxcb-sync.so.1 => lib/libxcb-sync.so.1 (0x00007fe1a0eb7000)
        libxcb-xfixes.so.0 => lib/libxcb-xfixes.so.0 (0x00007fe1a0cb0000)
        libxcb-shm.so.0 => lib/libxcb-shm.so.0 (0x00007fe1a0aad000)
        libxcb-randr.so.0 => lib/libxcb-randr.so.0 (0x00007fe1a089f000)
        libxcb-shape.so.0 => lib/libxcb-shape.so.0 (0x00007fe1a069b000)
        libxcb-xkb.so.1 => lib/libxcb-xkb.so.1 (0x00007fe1a0480000)
        libxkbcommon.so.0 => lib/libxkbcommon.so.0 (0x00007fe1a0220000)
        libfontconfig.so.1 => lib/libfontconfig.so.1 (0x00007fe19ffe4000)
        libfreetype.so.6 => lib/libfreetype.so.6 (0x00007fe19fd3f000)
        libXrender.so.1 => lib/libXrender.so.1 (0x00007fe19fb35000)
        libXext.so.6 => lib/libXext.so.6 (0x00007fe19f923000)
        libX11.so.6 => lib/libX11.so.6 (0x00007fe19f5e8000)
        libudev.so.1 => lib/libudev.so.1 (0x00007fe19f3d6000)
        libicui18n.so.52 => lib/libicui18n.so.52 (0x00007fe19efce000)
        libicuuc.so.52 => lib/libicuuc.so.52 (0x00007fe19ec55000)
        libpcre16.so.0 => lib/libpcre16.so.0 (0x00007fe19e9f6000)
        libdl.so.2 => lib/libdl.so.2 (0x00007fe19e7f2000)
        libgthread-2.0.so.0 => lib/libgthread-2.0.so.0 (0x00007fe19e5f0000)
        libglib-2.0.so.0 => lib/libglib-2.0.so.0 (0x00007fe19e2f0000)
        librt.so.1 => lib/librt.so.1 (0x00007fe19e0e8000)
        libGL.so.1 => lib/libGL.so.1 (0x00007fe19ddb5000)
        libpthread.so.0 => lib/libpthread.so.0 (0x00007fe19db98000)
        libstdc++.so.6 => lib/libstdc++.so.6 (0x00007fe19d894000)
        libm.so.6 => lib/libm.so.6 (0x00007fe19d591000)
        libgcc_s.so.1 => lib/libgcc_s.so.1 (0x00007fe19d37b000)
        libc.so.6 => lib/libc.so.6 (0x00007fe19cfd1000)
        /lib64/ld-linux-x86-64.so.2 (0x00007fe1a2bdb000)
        libpcre.so.1 => lib/libpcre.so.1 (0x00007fe19cd6a000)
        libffi.so.6 => lib/libffi.so.6 (0x00007fe19cb62000)
        libuuid.so.1 => lib/libuuid.so.1 (0x00007fe19c95d000)
        libXau.so.6 => lib/libXau.so.6 (0x00007fe19c759000)
        libXdmcp.so.6 => lib/libXdmcp.so.6 (0x00007fe19c553000)
        libxcb-util.so.1 => lib/libxcb-util.so.1 (0x00007fe19c34e000)
        libexpat.so.1 => lib/libexpat.so.1 (0x00007fe19c124000)
        libz.so.1 => lib/libz.so.1 (0x00007fe19bf0e000)
        libbz2.so.1.0 => lib/libbz2.so.1.0 (0x00007fe19bcfe000)
        libpng16.so.16 => lib/libpng16.so.16 (0x00007fe19bac9000)
        libicudata.so.52 => lib/libicudata.so.52 (0x00007fe19a25e000)
        libnvidia-tls.so.331.38 => lib/libnvidia-tls.so.331.38 (0x00007fe19a05b000)
        libnvidia-glcore.so.331.38 => lib/libnvidia-glcore.so.331.38 (0x00007fe19784d000)

Пересобирать каждую из них, в случае, когда нет статической, довольно проблематично и долго и не всегда возможно ( кто хочет пусть попробует

), поэтому есть вариант поставлять их вместе со своим приложением. Большая вероятность того, что большинство этих библиотек будут на чужой машине, но выполнив еще немного действий, вы застрахуете и себя, и пользователя от лишней головной боли.
Вот что делаем:
1) Нужно скопировать симлинк, который выводит ldd, и библиотеку на которую он указывает в каталог с нашим приложением. ( в нашем случае /path/to/app/lib ). Симлинк использует динамический загрузчик при загрузке библиотеки для приложения во время выполнения, ну а библиотека, на которую он указывает это собственно данные.

Вот наваял такой скрипт (еще раз напомню, что правки и улучшения очень приветствуются

c башем знаком 2 дня )

Bash
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
#!/bin/sh
LIB_DIR=lib/
SONAME_LIST=soname.lst
 
if [ "$#" -lt 1 ]; then
    echo "Usage: ./$(basename ${0}) < executable >"
    exit 1;
fi
 
# slc.c: На входе - вывод ldd, на выходе - имена symlink'ов, для динамич. загрузчика
cat<<'EOF' > slc.c
    #include <stdio.h>
    #include <stdlib.h>
    #include <ctype.h>
    #include <locale.h>
    #include <string.h>
 
    #define MAX_LENGTH 256
    #define LINE_CNT 200
    int first_nonspace(const char *s) {
    for(size_t i=0; *s; ++i, ++s)
        if( !isspace(*s) )
        return i;
    return -1; // Нет значимых символов
    }
    int main() {
    setlocale(LC_ALL, "C");
    char** lines = malloc( LINE_CNT * sizeof(char*) );
    for(int i=0; i < LINE_CNT; ++i)
        lines[i] = malloc( MAX_LENGTH * sizeof(char) );
    char  line[MAX_LENGTH];
    size_t currLineNumb = 0;
 
    while( fgets(line, MAX_LENGTH, stdin) != NULL && currLineNumb < LINE_CNT) {
        int fns = first_nonspace(line);
        if(fns == -1)
        continue;
        else {
        char lib_prefix[4] = {'\0',}; // "lib" + '\0'
        strncpy(lib_prefix, line+fns, 3);
        lib_prefix[3] = '\0';
        if( !strcmp(lib_prefix, "lib")) // Если имя начинается с 'lib',
            strcpy(lines[currLineNumb++], line+fns); // сохраняем эту строчку
        }
    }
    // Выводим сохраненную строчку до первого пробела,
    // что и будет составлять наш soname.
    for(size_t i=0; i < currLineNumb; ++i)
        printf("%.*s\n", (int)(strchr(lines[i], ' ') - lines[i]), lines[i]);
    for(int i=0; i < LINE_CNT; ++i) free(lines[i]);
    free(lines);
    return 0;
    }
EOF
cc -std=c99 slc.c -o slc
mkdir -p ${LIB_DIR}
ldd $1 | ./slc > $SONAME_LIST
for name in `cat $SONAME_LIST`; do
    libname=$(readlink /usr/lib/$name)   # Получим имя библиотеки
    cp /usr/lib/${libname} -t $LIB_DIR;    # Копируем библиотеку
    cp -P /usr/lib/${name} -t $LIB_DIR;    # Копируем симлинк, нужный для ldd
done
 
# Чистимся
rm -f ${SONAME_LIST} slc{,.c}
exit 0;

Сохраняем это под именем, например, s.sh, и ложим в каталог с исполняемым файлом приложения.
Выполняем:

Bash
1
chmod +x s.sh && ./s.sh name_of_the_executable

В текущем каталоге появится каталог ./lib/ , в котором будут лежать все необходимые ссылки и библиотеки.
Последний штрих: в .pro файл нужно добавить -rpath опцию линковщику, чтобы загрузчик потом знал, что поставляемые нами вместе с приложением библиотеки лежат в папке lib/ (в данном случае):

Code
1
LIBS += -Wl,-rpath lib/

Теперь все это дело в .tar.gz и можете делиться с друзьями своим приложением

Как из этого сделать программный пакет, смотрите документацию к своему дистрибутиву GNU/Linux.

Ps. На MacOS процедура практически не должна отличаться, но у меня нет возможности проверить.
Pss. Если ваше приложени базируется на плагинах, то они по своей природе не могут линковаться статически..
Смотрите документацию http://qt-project.org/doc/qt-4... t-x11.html и все вытекающие перекрестные ссылки по плагинам.
________________________________________ ________________________________________ ___________________________
Вроди бы ничего не забыл...
Надеюсь, статейка кому-нибудь поможет разобраться.
Спасибо и удачи

@RazrFalcon · 23.01.2014, 20:28

По поводу башскрипта который копирует либы. Это вы в нем прогу на С компилите и ей парсите ввод ldd?
Не проще было бы сразу на баше это сделать вместо того что бы такие странные вещи делать?

@gromo · 23.01.2014, 20:32 **[ТС]**

Сообщение от RazrFalcon

Не проще было бы сразу на баше это сделать вместо того что бы такие странные вещи делать?

Проще, наверное

Только вот

Сообщение от gromo

c башем знаком 2 дня

Та программа выделяет все , что до знаков " => " в выводе ldd и с префиксом 'lib'
Если вы знаете как, то можете сделать это на баше, Если пожелаете, конечно, - это намного упростит реализацию. И включим ваше решение сюда.

@RazrFalcon · 23.01.2014, 20:34

+ на x86_x64 либы лежат в /usr/lib64
+ на том же gentoo qt либы лежат в /usr/lib64/qt4, так что лучше использовать абсолютные пути при копировании

@gromo · 23.01.2014, 20:42 **[ТС]**

Сообщение от RazrFalcon

+ на x86_x64 либы лежат в /usr/lib64

Это симлинк. (во всяком случае у меня)

Сообщение от RazrFalcon

+ на том же gentoo qt либы лежат в /usr/lib64/qt4, так что лучше использовать абсолютные пути при копировании

Ну это к Qt5.* мануал, а не к 4, да и пути можно свои дописать. И где вы там неабсолютные пути увидели?
P.s. В арче например текущая версия Qt вообще без цифры, на неё просто сслыаться нужно как на 'qt', а остальные /usr/lib/qt4{,3,5} уже по надобности.

@RazrFalcon · 23.01.2014, 21:16

Мое решение, возможно не самое лучшее, но всяко лучше того что выше:

Bash
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
#!/bin/sh
LIB_DIR=lib/
 
if [ "$#" -lt 1 ]; then
    echo "Usage: ./$(basename ${0}) < executable >"
    exit 1;
fi 
 
mkdir -p ${LIB_DIR}
#забираем все пути
SONAME_LIST=`ldd "$1" | sed 's/^.*> //g;s/ (.*//g;s/\t//g'`
for name in $SONAME_LIST; do
    # игнорируем некоторые либы
    if [ $name != "linux-vdso.so.1" ]; then
        linkname=`readlink $name`
        # не пытаемся копировать либы у которых нет симлинков
        if [ -n "$linkname" ]; then
            cp `dirname $name`"/"$linkname -t $LIB_DIR;
        fi
        cp -P ${name} -t $LIB_DIR;
    fi
done

Сообщение от gromo

Это симлинк. (во всяком случае у меня)

У всех симлинк, но у меня не обработало его, по каким-то причинам.
В генту симлинк на оборот

Bash
1
lib -> lib64

Да и при чем тут версия Qt, если вы просто собирает либы из ldd...

Добавлено через 7 минут
Даже проще:

Bash
1
SONAME_LIST=`ldd "$1" | sed 's/^.*> //g;s/ (.*//g;s/\t//g'`

на

Bash
1
SONAME_LIST=`ldd "$1" | grep -oe '/.* '`

Добавлено через 1 минуту
К слову у вас в инструкции пропущена самая важная часть - установка зависимостей для компиляции.

@gng · 23.01.2014, 21:50

Автор любезно согласился принимать критические замечания.
1.

Сообщение от gromo

Теперь все Qt и 3-rd party библиотеки сидят в бинарнике, НО дело еще не закончено.
Если посмотреть на вывод ldd, то можно увидеть, что приложение зависит еще от целой кучи не Qt-ных библиотек.

Это меня озадачило. Всякий раз, компилируя статически, я получаю что-то такое

Bash
1
2
gg@c-1:~/cc/tmp$ ldd a.out
    not a dynamic executable

Статические библиотеки, указанные в приведенном списке распространяются вместе с динамическими, часто в рамках одного пакета с заголовочными файлами. Особенно удивляет отсутствие статических libc и libstdc++ шестой версии, присутствующие практически везде, где есть gcc.
Да и какой смысл в статической линковке, если с бинарником все равно нужно распространять зоопарк библиотек.
Если какие-то библиетеки окажутся других версий, или вовсе отсутствуют в дистрибутиве, то да, имеет смысл скачать их исходники. Это займет не больше времени, чем разработка вышеприведенного оригинального кросс-скрипта.

2. Непонятна целевая аудитория такого распрстранения программы. Если программа открытая, то статическая компановка обычно не требуется. Достаточно указать зависимости в пакете. Если проприетарная, то такой подход нарушает LGPL, под которой распростаняется Qt, кроме оговоренного (на мой взгляд достаточно экзотического) случая, когда автор предоставит средства для работы своей программы с любой новой версией Qt.

@RazrFalcon · 23.01.2014, 22:14

gng,
1) Почему вы указываете ldd не исполняемый файл?
Все либы собрать статически почти не возможно. Обычно тягают только Qt + мелочевка. От системных либ никуда не уйти.
2) LGPL не запрещает статическу сборку.

@gng · 23.01.2014, 22:57

Сообщение от RazrFalcon

1) Почему вы указываете ldd не исполняемый файл?

a.out - имя исполняемого файла по умолчанию.

Сообщение от RazrFalcon

2) LGPL не запрещает статическу сборку.

Я написал, при каких условиях. Либо
1. Это свободно распространяемая программа, либо
2. Автор вместе с программой предоставляет инструменты, позволяющие запустить её с новыми версиями библиотеки Qt (которые ещё выйдут)

Добавлено через 3 минуты

Сообщение от RazrFalcon

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

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

@gromo · 23.01.2014, 23:05 **[ТС]**

Сообщение от RazrFalcon

Даже проще:

Вот так вот - век живи, век учись

Нужно будет как-то отредактировать пост и включить туда ваш вариант.
Кстати, еще нужно сделать, там где "игнорируем некоторые либы" пропуск всех соответствующих ld.*
я никак не пойму как прописать это условие что-то.

Сообщение от gng

Это меня озадачило. Всякий раз, компилируя статически, я получаю что-то такое

Это вы компилируете Qt проект или что-то простое с 2-3 либами? Если второе, то у меня тоже так.

Сообщение от gng

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

По идее так и должно быть но у меня их нет. Например, взял случайную либу в /usr/lib/libxcb.so
Она принадлежит пакету libxcb, хотя должна принадлежать libxcb-devel, которого, к слову, даже нет. (ну я только в официальных репах смотрел).
Что касается libc.a и libstdc++.a, они, безусловно, присутствуют, но их, насколько я знаю, небезопасно линковать статически. Если libc.a еще можно, потому что ее ABI, грубо говоря, прост как валенок, то libstdc++.a требует какой-то runtime identification/support ... что-то такое для поддержки исключений RTTI, что, в свою очередь требует динамич. линковки.
Более того, есть опция -static-libstdc++, в таком случае g++ принимает решение: можно/нужно ли линковать статически. В моем случае не связывал ни в какую. Может я не туда прописывал эту опцию в .pro файле, черт иногда поймет этот qmake...

Сообщение от gng

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

Ну а если древняя очень система, на которой будет производиться запуск приложения?

Сообщение от gng

Если проприетарная, то такой подход нарушает LGPL, под которой распростаняется Qt

Не совсем понимаю, проприетарная или LGPL ? Насколько я знаю, это разные вещи, ведь Qt распространяется в 3 видах лицензии: GPL, LGPL, Commercial.
Вообще, это один из подходов, который описан в документации.
Вот http://qt-project.org/doc/qt-4... on-package
Второй в списке.
________________________________________ _______
P.s. Спасибо за внимание и критику

@Dmitriy_M · 23.01.2014, 23:11

libnvidia-tls.so.331.38 => lib/libnvidia-tls.so.331.38 (0x00007fe19a05b000)
libnvidia-glcore.so.331.38 => lib/libnvidia-glcore.so.331.38 (0x00007fe19784d000)

Сообщение от gromo

Теперь все это дело в .tar.gz и можете делиться с друзьями своим приложением

ABI между GLibc на твоей машине и Linux kernel твоих друзей совместимо?

Добавлено через 2 минуты

Сообщение от gromo

Она принадлежит пакету libxcb, хотя должна принадлежать libxcb-devel

Вранье. Нет там такого.

Добавлено через 49 секунд

Сообщение от gromo

Ну а если древняя очень система, на которой будет производиться запуск приложения?

с вероятностью 99% не запуститься из-за бинарной не совместимостью с ядром.

@gromo · 23.01.2014, 23:18 **[ТС]**

Сообщение от Dmitriy_M

ABI между GLibc на твоей машине и Linux kernel твоих друзей совместимо?

Не совсем понимаю, что вы имеете ввиду... ABI в Gglibc практически не меняется, разве что в мажорных версиях? Или я не прав?

Добавлено через 1 минуту

Сообщение от Dmitriy_M

Вранье. Нет там такого

чего нет? libxcb-devel нет такого пакет, я это написал.

Добавлено через 1 минуту
Написал я это потому, что выше был разговор о том, что с динамическими либами почти всегда идут статические. Статические обычно являются частью devel-пакета. я и написал, что такого пакета нет, как и статических библиотек с ним идущих

Добавлено через 1 минуту

Сообщение от Dmitriy_M

с вероятностью 99% не запуститься из-за бинарной не совместимостью с ядром.

Ну, я думаю, о kernel < 2.6.32* речь уже не идет...

@Dmitriy_M · 23.01.2014, 23:48

Сообщение от gromo

ABI в Gglibc практически не меняется, разве что в мажорных версиях? Или я не прав?

API != ABI. GLibc может вызывать функции ядра, которых нет в предыдущих ядрах.

Сообщение от gromo

чего нет? libxcb-devel нет такого пакет, я это написал.

Пакет *-devel это заголовочные файлы и поэтому libxcb не зависит от libxcb-devel, а вот libxcb-devel зависит от libxcb, т.к. это пакет для разработки, а для разработки нужны заголовочные файлы+либа.

Сообщение от gromo

Ну, я думаю, о kernel < 2.6.32* речь уже не идет...

RHEL 5 еще актуален. Да и для версии 2.6.32 гарантий нет.

@RazrFalcon · 24.01.2014, 00:00

Собственно обычная проблема зоопарка линукс дистров. Проще сорцы выложить, а те кому - надо соберут.
Ну или deb/rpm который поставит нужные зависимости.

@gng · 24.01.2014, 00:34

Сообщение от Dmitriy_M

RHEL 5 еще актуален

Ради полноты надо вспомнить о LSB, блаодаря которой уже не один год любители совместимых бинарников (в основном проприетарщики и авторы вирусов) компилируют их в RHEL4.

Сообщение от gromo

Что касается libc.a и libstdc++.a, они, безусловно, присутствуют, но их, насколько я знаю, небезопасно линковать статически

Здесь проблема, как заметил уважаемый Dmitriy_M, больше в ABI, но не в статической компановке.

Добавлено через 5 минут

Сообщение от gromo

Не совсем понимаю, проприетарная или LGPL ? Насколько я знаю, это разные вещи, ведь Qt распространяется в 3 видах лицензии: GPL, LGPL, Commercial.

1. GPL - ваша программа тоже должна быть GPL незавимо от способа линковки.
2. LGPL - ваша программа может быть проприетарной при динамической линковке либо при соблюдении вышеописанного условия.
3.Commercial - покупаете и линкуете как хотите.

@gromo · 24.01.2014, 00:51 **[ТС]**

Сообщение от Dmitriy_M

Пакет *-devel это заголовочные файлы

Не только. В девел пакете также лежит необходимая ТОЛЬКО для разработки статическая либа.
В пакете же libxcb.pkg.* будет libxcb.so.2.25 (например) и сслыка на нее, libxcb.so.2

@Чистый · 24.01.2014, 13:47

Тему закрепил, а там посмотрим

@Dmitriy_M · 27.01.2014, 11:04

Хм. Под Debian 6 без дополнительных пинков configure не проходит.

@gromo · 27.01.2014, 14:02 **[ТС]**

Сообщение от Dmitriy_M

Под Debian 6 без дополнительных пинков configure не проходит.

что именно не проходит?

@KOSHAK_ · 26.12.2014, 17:16

Никак не получается собрать библиотеки. Выскакивает ошибка:

Code
1
2
3
4
Running configuration tests...
The test for linking against libxcb and support libraries failed!
 You might need to install dependency packages, or pass -qt-xcb.
 See src/plugins/platforms/xcb/README.

Пробовал добавлять ключ -qt-xcb, выдало:

Code
1
2
3
4
NOTE: libxkbcommon and libxkbcommon-x11 0.4.1 or higher not found on the system, will use 
the bundled version from 3rd party directory.
Could not find qmake configuration file linux-g++.
Error processing project file: /home/oleg/Загрузки/qt-everywhere-opensource-src-5.3.2/qt.pro

А с -no-xcb:

Code
1
2
Could not find qmake configuration file linux-g++.
Error processing project file: /home/oleg/Загрузки/qt-everywhere-opensource-src-5.3.2/qt.pro

В чем может быть проблема? Версия Qt 5.3.2

Добавлено через 1 час 22 минуты
kUbuntu 14.10

Добавлено через 3 часа 44 минуты
Все установилось, надо было выполнять команды из под рута

Добавлено через 27 минут
В общем все прописал, скомпилировал, а прога все равно не запускается на компе без Qt. Требует шрифты, которрые лежат в папке с Qt библиотеками. Как это исправить?

Новые блоги и статьи Все статьи Все блоги /
http://iceja.net/ сервер решения полиномов iceja 18.01.2026 Выкатила http:/ / iceja. net/ сервер решения полиномов (находит действительные корни полиномов методом Штурма). На сайте документация по API, но скажу прямо VPS слабенький и 200 000 полиномов. . .	Первый деплой lagorue 16.01.2026 Не спеша развернул своё 1ое приложение в kubernetes. А дальше мне интересно создать 1фронтэнд приложения и 2 бэкэнд приложения развернуть 2 деплоя в кубере получится 2 сервиса и что-бы они. . .	Расчёт переходных процессов в цепи постоянного тока igorrr37 16.01.2026 / * Дана цепь постоянного тока с R, L, C, k(ключ), U, E, J. Программа составляет систему уравнений по 1 и 2 законам Кирхгофа, решает её и находит: токи, напряжения и их 1 и 2 производные при t = 0;. . .	Восстановить юзерскрипты Greasemonkey из бэкапа браузера damix 15.01.2026 Если восстановить из бэкапа профиль Firefox после переустановки винды, то список юзерскриптов в Greasemonkey будет пустым. Но восстановить их можно так. Для этого понадобится консольная утилита. . .
Изучаю kubernetes lagorue 13.01.2026 А пригодятся-ли мне знания kubernetes в России?	Сукцессия микоризы: основная теория в виде двух уравнений. anaschu 11.01.2026 https:/ / rutube. ru/ video/ 7a537f578d808e67a3c6fd818a44a5c4/	WordPad для Windows 11 Jel 10.01.2026 WordPad для Windows 11 — это приложение, которое восстанавливает классический текстовый редактор WordPad в операционной системе Windows 11. После того как Microsoft исключила WordPad из. . .	Classic Notepad for Windows 11 Jel 10.01.2026 Old Classic Notepad for Windows 11 Приложение для Windows 11, позволяющее пользователям вернуть классическую версию текстового редактора «Блокнот» из Windows 10. Программа предоставляет более. . .

@RazrFalcon 1403 / 1260 / 262 Регистрация: 10.11.2013 Сообщений: 3,763
	23.01.2014, 20:28
	По поводу башскрипта который копирует либы. Это вы в нем прогу на С компилите и ей парсите ввод ldd? Не проще было бы сразу на баше это сделать вместо того что бы такие странные вещи делать? 0

@RazrFalcon 1403 / 1260 / 262 Регистрация: 10.11.2013 Сообщений: 3,763
	23.01.2014, 20:34
	+ на x86_x64 либы лежат в /usr/lib64 + на том же gentoo qt либы лежат в /usr/lib64/qt4, так что лучше использовать абсолютные пути при копировании 0

@RazrFalcon 1403 / 1260 / 262 Регистрация: 10.11.2013 Сообщений: 3,763
	23.01.2014, 22:14
	gng, 1) Почему вы указываете ldd не исполняемый файл? Все либы собрать статически почти не возможно. Обычно тягают только Qt + мелочевка. От системных либ никуда не уйти. 2) LGPL не запрещает статическу сборку. 0

@RazrFalcon 1403 / 1260 / 262 Регистрация: 10.11.2013 Сообщений: 3,763
	24.01.2014, 00:00
	Собственно обычная проблема зоопарка линукс дистров. Проще сорцы выложить, а те кому - надо соберут. Ну или deb/rpm который поставит нужные зависимости. 2

@Чистый 2733 / 1429 / 89 Регистрация: 08.09.2011 Сообщений: 3,746 Записей в блоге: 1
	24.01.2014, 13:47
	Тему закрепил, а там посмотрим 0

@Dmitriy_M 1443 / 1326 / 131 Регистрация: 20.03.2009 Сообщений: 4,689 Записей в блоге: 11
	27.01.2014, 11:04
	Хм. Под Debian 6 без дополнительных пинков configure не проходит. 0