gcc -Wl,--as-needed ...

[Olej]

Значит на убунтоподобных дистрах можно найти в ман странице gcc опцию --as-needed а в других дистрах ПОКА нет

Опция -Wl,--as-needed есть во всех дистрибутивах.
Это опция самого GCC.
И может быть полезной, если нею умело распорядиться.
Опция и вот этот эффект, связанный с жёстким порядком указания библиотек в командной строке - это разные вещи.
Хотя у них и общая природа: желание исключить из сборки не используемые библиотеки.

[Olej]

Да у меня столько же вируальных гостей но нет среди них убунты.

Нет Ubuntu, так, может, есть Mint, или ALT Linux...
В том-то и фокус, что довольно много дистрибутивов где это проявляется.
Или может проявиться в следующей ... или предыдущей версии.
И вы, со своим проектом, на неё нарвётесь.

[nezabudka]

..И вы, со своим проектом, на неё нарвётесь.

Обычно пользуюсь флагом в makefile LDFLAGS думаю make должен разруливать все правильно.

[Olej]

..И вы, со своим проектом, на неё нарвётесь.

Обычно пользуюсь флагом в makefile LDFLAGS думаю make должен разруливать все правильно.

Это не так.
LDFLAGS - это только перечень используемых библиотек. Если вы натолкаете туда, вместо требуемых 2-х библиотек, 22, то все 22 DLL будут автозагружаться при выполнении вашего проекта (ну, скажем, не полностью загружаться, а загружаться их таблицы имён ... или что-то подобное в этом случае ... не хочется вспоминать и разбираться).

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

P.S. А make - вообще ни в чём не "разбирается" - это не его проблема, make вообще к программированию не имеет отношения - это программа тупо управления обновлениями файлов на их временных зависимостях ... вы можете на make построить себе, например, ... дневник выполнения намеченных дел

[Olej]

..И вы, со своим проектом, на неё нарвётесь.

думаю make должен разруливать все правильно.

Откуда у меня возникло по-новой разбирательство с этой проблемой?
Меня попросили проект с Makefile (который я раньше и сделал) переписать под сборку CMake.
И вот, у меня на Fedora проект собирается, а у клиента на Ubuntu - ни фига ... с тяжелейшими и не диагностируемыми ошибками.
В итоге, полагаю, под некоторыми дистрибутивами проекты на языке C с помощью CMake вообще невозможно будет собрать (гипотеза ).
Потому как параметры сборки там в CMakeLists.txt вы определяете спец. макросами типа:

Код: Выделить всё

execute_process(COMMAND net-snmp-config --agent-libs
                OUTPUT_VARIABLE LDOPT
               )
string(STRIP "${LDOPT}" CMAKE_EXE_LINKER_FLAGS)

А куда он потом втулит этот $CMAKE_EXE_LINKER_FLAGS, в начало или в хвост командной строки - это его дело, и контролировать вы это никак не сможете.
И так со всем великим множеством переменных CMake.

P.S. Резюме ... попутно возникшее (и сформулированное мной заказчику ): а не надо пользоваться всякими приблудами для сборки , типа CMake (и QtCreator) ... или всякими "проектами", которые строят некоторые разные IDE - это всё идёт от дурных манер Windows и MS VisualStudio. А нужно пользоваться Makefile.

[Olej]

Обычно пользуюсь флагом в makefile LDFLAGS думаю make должен разруливать все правильно.

Вот объяснение того, откуда ноги растут: ld и --as-needed

2008-06-01 23:48:28

И до сих пор единого мнения нет.

[Olej]

Есть очень интересное решение проблемы в тех дистрибутивах, где этот эффект наблюдается, и тогда, когда он мешает:

Код: Выделить всё

olej@nvidia ~/2016_WORK/in.WORK/as-needed $ lsb_release -ircd
Distributor ID: LinuxMint
Description:    Linux Mint 17.1 Rebecca
Release:        17.1
Codename:       rebecca

olej@nvidia ~/2016_WORK/in.WORK/as-needed $ gcc -Wall -lm ex1.c -o ex1
/tmp/ccUuI8Fy.o: In function `main':
ex1.c:(.text+0x1a): undefined reference to `sqrt'
collect2: error: ld returned 1 exit status

Обсуждаемый эффект наблюдается.
А теперь смотрим сюда:

Код: Выделить всё

olej@nvidia / $ ls -l `which ld`*
lrwxrwxrwx 1 root root       6 мая    2 23:41 /usr/bin/ld -> ld.bfd
-rwxr-xr-x 1 root root 1042556 мая    2 23:40 /usr/bin/ld.bfd
-rwxr-xr-x 1 root root    5424 мая   26 13:39 /usr/bin/ldd
-rwxr-xr-x 1 root root 2513280 мая    2 23:40 /usr/bin/ld.gold
-rwxr-xr-x 1 root root      87 февр. 16  2014 /usr/bin/ld-musl-config

olej@nvidia / $ ld.bfd --version
GNU ld (GNU Binutils for Ubuntu) 2.24
Copyright 2013 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or (at your option) a later version.
This program has absolutely no warranty.

olej@nvidia / $ ld.gold --version
GNU gold (GNU Binutils for Ubuntu 2.24) 1.11
Copyright 2013 Free Software Foundation, Inc.
Данная программа является свободным программным обеспечением;  вы можете распространять её в соответствии
с условиями GNU General Public License Версия 3 или (на ваш выбор) более поздней версии.
Эта программа не имеет абсолютно никаких гарантий.

Как легко видеть, это два разных компоновщика.

Код: Выделить всё

olej@nvidia /usr/bin $ sudo ln -sf /usr/bin/ld.gold /usr/bin/ld

olej@nvidia ~/2016_WORK/in.WORK/as-needed $ gcc -Wall -lm ex1.c -o ex1

Сменили компоновщик ld.bfd на ld.gold.
Теперь всё срабатывает без проблем.

[Olej]

И ещё одна особенность - если то же собирать как приложение C++:

Код: Выделить всё

olej@nvidia ~/2016_WORK/in.WORK/as-needed $ g++ -lm -Wall ex1.c -o ex1++

А вот тут я вас обманул ... необоснованно обнадёжил.

С C++ в точности такая же картина.
Просто потому, что к команде линковки g++ по умолчанию добавляет -lstdc++ с зависимостями (включая -lm), и делает это в конце командной строки, эффект неразрешённой ссылки маскируется.

Код: Выделить всё

#include <iostream>
#include <cstring>
#include <pcre.h>

int main(int argc, char **argv) {
    pcre *re;
    const char *err;
    int erroffset;
    if (argc != 3) {
        std::cerr << "specify exactly 2 arguments" << std::endl;
        return 1;
    }
    re = pcre_compile(argv[1], 0, &err, &erroffset, nullptr);
    if (! re) {
        std::cerr << erroffset << ": " << err << std::endl;
        return 2;
    }
    if (pcre_exec(re, nullptr, argv[2], strlen(argv[2]), 0, 0, nullptr, 0) != PCRE_ERROR_NOMATCH) {
        std::cout << argv[2] << std::endl;
    }
    return 0;
}

Не важно, что делает этот код, важно что это нужно связать с библиотекой libpcre.so :

Код: Выделить всё

[olej@dell as-needed]$ g++ -std=gnu++11 -Wl,--as-needed -o ex2 ex2.cc -lpcre

[olej@dell as-needed]$ g++ -std=gnu++11 -Wl,--as-needed -lpcre -o ex2 ex2.cc
/tmp/cc02ATVb.o: In function `main':
ex2.cc:(.text+0x5e): undefined reference to `pcre_compile'
ex2.cc:(.text+0xe9): undefined reference to `pcre_exec'
collect2: ошибка: выполнение ld завершилось с кодом возврата 1

В 1-м случае всё собирается. Во 2-м случае та же сборка - ошибка.
Более того, это Fedora 23, где по умолчанию этот эффект не возникает, но опция -Wl,--as-needed его выявляет... при использовании стандартного компоновщика ld.bfd .

Так что не стоит обольщаться, что C++ вас спасёт.

[Olej]

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