Члены класса:

Деструктор pure virtual нуждается в реализации.

Объявление деструктора по-прежнему требует определения его (в отличие от обычной функции):

struct X
{
    virtual ~X() = 0;
};
struct Y : X
{
    ~Y() {}
};
int main()
{
    Y y;
}
//X::~X(){} //uncomment this line for successful definition

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

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

Это похоже на методы не virtual без определения, с добавлением аргументов, что чистая декларация генерирует фиктивный vtable, и вы можете получить ошибку компоновщика без использования функции:

struct X
{
    virtual void foo();
};
struct Y : X
{
   void foo() {}
};
int main()
{
   Y y; //linker error although there was no call to X::foo
}

Чтобы это сработало, объявите X::foo() как чистый:

struct X
{
    virtual void foo() = 0;
};

Члены класса <<20 >

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

struct A
{ 
    ~A();
};

Ниже приведена ошибка:

A a;      //destructor undefined

Реализация может быть встроенной в самом определении класса:

struct A
{ 
    ~A() {}
};

или снаружи:

A::~A() {}

Если реализация вне определения класса, но в заголовке, методы должны быть помечены как inline, чтобы предотвратить множественное определение.

Все используемые методы-члены должны быть определены, если они используются.

Общей ошибкой является отказ от названия:

struct A
{
   void foo();
};

void foo() {}

int main()
{
   A a;
   a.foo();
}

Определение должно быть

void A::foo() {}

static члены данных должны быть определены вне класса в единице перевода:

struct X
{
    static int x;
};
int main()
{
    int x = X::x;
}
//int X::x; //uncomment this line to define X::x

Инициализатор может быть предоставлен для элемента данных static const интегрального или перечисляемого типа в определении класса; однако odr-использование этого элемента по-прежнему потребует определения области пространства имен, как описано выше. С++ 11 позволяет инициализировать внутри класса для всех членов static const.

Отказ от ссылки на соответствующие библиотеки/объектные файлы или компиляцию файлов реализации

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

В разделе gcc вы должны указать все объектные файлы, которые должны быть связаны вместе в командной строке, или скомпилировать файлы реализации вместе.

g++ -o test objectFile1.o objectFile2.o -lLibraryName

libraryName - это просто голое имя библиотеки, без добавления к платформе. Так, например, в файлах библиотеки Linux обычно называют libfoo.so, но вы должны писать только -lfoo. В Windows этот же файл можно назвать foo.lib, но вы должны использовать тот же аргумент. Возможно, вам придется добавить каталог, в котором эти файлы можно найти, используя -L‹directory›. Обязательно не записывайте пробел после -l или -l.

Для XCode: добавьте пути поиска заголовка пользователя → добавьте путь поиска библиотеки → перетащите фактическую ссылку на библиотеку в папку проекта.

В разделе MSVS файлы, добавленные в проект, автоматически связывают их объектные файлы и генерируется файл lib (обычно используется). Чтобы использовать символы в отдельном проекте, вы должны необходимо указать файлы lib в настройках проекта. Это делается в разделе Linker свойств проекта, в Input -> Additional Dependencies. (путь к файлу lib должен быть добавлено в Linker -> General -> Additional Library Directories). При использовании сторонней библиотеки, которая поставляется с файлом lib, отказ в этом обычно приводит к ошибке.

Также может случиться так, что вы забудете добавить файл в компиляцию, и в этом случае объектный файл не будет сгенерирован. В gcc вы должны добавить файлы в командную строку. В MSVS добавление файла в проект заставит его скомпилировать его автоматически (хотя файлы могут, вручную, быть отдельно исключены из сборки).

В программировании Windows контрольный знак, что вы не связывали нужную библиотеку, состоит в том, что имя неразрешенного символа начинается с __imp_. Посмотрите имя функции в документации, и она должна сказать, какую библиотеку вам нужно использовать. Например, MSDN помещает информацию в поле внизу каждой функции в разделе "Библиотека".

Объявлено, но не определено переменная или функция.

Типичное объявление переменной

extern int x;

Поскольку это только объявление, требуется одиночное определение. Соответствующим определением будет:

int x;

Например, следующее приведет к ошибке:

extern int x;
int main()
{
    x = 0;
}
//int x; // uncomment this line for successful definition

Аналогичные замечания относятся к функциям. Объявление функции без ее определения приводит к ошибке:

void foo(); // declaration only
int main()
{
   foo();
}
//void foo() {} //uncomment this line for successful definition

Будьте осторожны, чтобы выполняемая вами функция точно соответствовала той, которую вы указали. Например, у вас могут быть несоответствующие cv-квалификаторы:

void foo(int& x);
int main()
{
   int x;
   foo(x);
}
void foo(const int& x) {} //different function, doesn't provide a definition
                          //for void foo(int& x)

Другие примеры несоответствий включают

• Функция/переменная, объявленная в одном пространстве имен, определенном в другом.
• Функция/переменная, объявленная как член класса, определяемая как глобальная (или наоборот).
• Тип возвращаемого значения функции, номер и типы параметров и соглашение о вызове не все точно согласны.

Сообщение об ошибке из компилятора часто дает вам полное объявление переменной или функции, которая была объявлена, но не определена. Сравните его с определением, которое вы указали. Убедитесь, что каждая деталь соответствует.

Порядок, в котором указаны взаимозависимые связанные библиотеки, неверен.

Порядок, в котором связаны библиотеки, имеет значение, если библиотеки зависят друг от друга. В общем случае, если библиотека A зависит от библиотеки B, тогда libA ДОЛЖЕН появляется перед libB в флагах компоновщика.

Например:

// B.h
#ifndef B_H
#define B_H

struct B {
    B(int);
    int x;
};

#endif

// B.cpp
#include "B.h"
B::B(int xx) : x(xx) {}

// A.h
#include "B.h"

struct A {
    A(int x);
    B b;
};

// A.cpp
#include "A.h"

A::A(int x) : b(x) {}

// main.cpp
#include "A.h"

int main() {
    A a(5);
    return 0;
};

Создайте библиотеки:

$ g++ -c A.cpp
$ g++ -c B.cpp
$ ar rvs libA.a A.o 
ar: creating libA.a
a - A.o
$ ar rvs libB.a B.o 
ar: creating libB.a
a - B.o

Compile:

$ g++ main.cpp -L. -lB -lA
./libA.a(A.o): In function `A::A(int)':
A.cpp:(.text+0x1c): undefined reference to `B::B(int)'
collect2: error: ld returned 1 exit status
$ g++ main.cpp -L. -lA -lB
$ ./a.out

Итак, повторим еще раз, порядок ДОЛЖЕН!

что такое undefined ссылка/неразрешенный внешний символ

Я попытаюсь объяснить, что такое "undefined ссылка/неразрешенный внешний символ".

note: я использую g++ и Linux, и все примеры для него

Например, у нас есть код

// src1.cpp
void print();

static int local_var_name; // 'static' makes variable not visible for other modules
int global_var_name = 123;

int main()
{
    print();
    return 0;
}

и

// src2.cpp
extern "C" int printf (const char*, ...);

extern int global_var_name;
//extern int local_var_name;

void print ()
{
    // printf("%d%d\n", global_var_name, local_var_name);
    printf("%d\n", global_var_name);
}

Сделать объектные файлы

$ g++ -c src1.cpp -o src1.o
$ g++ -c src2.cpp -o src2.o

После фазы ассемблера мы имеем объектный файл, который содержит любые экспортируемые символы. Посмотрите на символы

$ readelf --symbols src1.o
  Num:    Value          Size Type    Bind   Vis      Ndx Name
     5: 0000000000000000     4 OBJECT  LOCAL  DEFAULT    4 _ZL14local_var_name # [1]
     9: 0000000000000000     4 OBJECT  GLOBAL DEFAULT    3 global_var_name     # [2]

Я отклонил некоторые строки из вывода, потому что они не имеют значения

Итак, мы видим следующие символы для экспорта.

[1] - this is our static (local) variable (important - Bind has a type "LOCAL")
[2] - this is our global variable

src2.cpp ничего не экспортирует, и мы не видели его символов

Свяжите наши объектные файлы

$ g++ src1.o src2.o -o prog

и запустите его

$ ./prog
123

Линкер видит экспортированные символы и связывает его. Теперь мы пытаемся раскомментировать строки в src2.cpp, как здесь.

// src2.cpp
extern "C" int printf (const char*, ...);

extern int global_var_name;
extern int local_var_name;

void print ()
{
    printf("%d%d\n", global_var_name, local_var_name);
}

и перестроить файл объекта

$ g++ -c src2.cpp -o src2.o

ОК (нет ошибок), потому что мы только создаем объектный файл, ссылка еще не завершена. Попробуйте связать

$ g++ src1.o src2.o -o prog
src2.o: In function `print()':
src2.cpp:(.text+0x6): undefined reference to `local_var_name'
collect2: error: ld returned 1 exit status

Это произошло потому, что наше local_var_name статично, то есть оно не видно для других модулей. Теперь глубже. Получить выход фазы перевода

$ g++ -S src1.cpp -o src1.s

// src1.s
look src1.s

    .file   "src1.cpp"
    .local  _ZL14local_var_name
    .comm   _ZL14local_var_name,4,4
    .globl  global_var_name
    .data
    .align 4
    .type   global_var_name, @object
    .size   global_var_name, 4
global_var_name:
    .long   123
    .text
    .globl  main
    .type   main, @function
main:
; assembler code, not interesting for us
.LFE0:
    .size   main, .-main
    .ident  "GCC: (Ubuntu 4.8.2-19ubuntu1) 4.8.2"
    .section    .note.GNU-stack,"",@progbits

Итак, мы видели, что для local_var_name нет метки, поэтому компоновщик ее не нашел. Но мы хакеры:), и мы можем это исправить. Откройте src1.s в текстовом редакторе и измените

.local  _ZL14local_var_name
.comm   _ZL14local_var_name,4,4

to

    .globl  local_var_name
    .data
    .align 4
    .type   local_var_name, @object
    .size   local_var_name, 4
local_var_name:
    .long   456789

то есть. вы должны иметь ниже

    .file   "src1.cpp"
    .globl  local_var_name
    .data
    .align 4
    .type   local_var_name, @object
    .size   local_var_name, 4
local_var_name:
    .long   456789
    .globl  global_var_name
    .align 4
    .type   global_var_name, @object
    .size   global_var_name, 4
global_var_name:
    .long   123
    .text
    .globl  main
    .type   main, @function
main:
; ...

мы изменили видимость local_var_name и установили его значение 456789. Попробуйте создать из него объектный файл

$ g++ -c src1.s -o src2.o

ok, см. вывод на экран (символы)

$ readelf --symbols src1.o
8: 0000000000000000     4 OBJECT  GLOBAL DEFAULT    3 local_var_name

теперь local_var_name имеет Bind GLOBAL (был локальным)

ссылка

$ g++ src1.o src2.o -o prog

и запустите его

$ ./prog 
123456789

ok, мы его взломаем:)

Итак, в результате - "undefined ссылка/неразрешенная внешняя ошибка символа" происходит, когда компоновщик не может найти глобальные символы в объектных файлах.

Символы были определены в программе на языке C и используются в коде С++.

Функция (или переменная) void foo() была определена в программе на C, и вы пытаетесь использовать ее в программе на С++:

void foo();
int main()
{
    foo();
}

Компилятор С++ ожидает, что имена будут искажены, поэтому вы должны объявить эту функцию как:

extern "C" void foo();
int main()
{
    foo();
}

Эквивалентно, вместо определения в программе на C, функция (или переменная) void foo() была определена в С++, но с C-связью:

extern "C" void foo();

и вы пытаетесь использовать его в С++-программе с С++-связью.

Если вся библиотека включена в заголовочный файл (и была скомпилирована как код C); включение должно быть следующим:

extern "C" {
    #include "cheader.h"
}

Если все остальное не удается, перекомпилируйте.

Недавно я смог избавиться от нерешенной внешней ошибки в Visual Studio 2012, просто перекомпилировав нарушивший файл. Когда я перестроил, ошибка исчезла.

Это обычно происходит, когда две (или более) библиотеки имеют циклическую зависимость. Библиотека A пытается использовать символы в B.lib и библиотеке B пытается использовать символы из A.lib. Ничего не существует для начала. Когда вы пытаетесь скомпилировать A, шаг ссылки завершится неудачно, потому что он не может найти B.lib. A.lib будет сгенерирован, но не будет dll. Затем вы компилируете B, который будет успешным и сгенерирует B.lib. Повторная компиляция A теперь будет работать, потому что теперь найден B.lib.

Это одно из самых запутанных сообщений об ошибках, которые каждый программист VС++ видел снова и снова. Давайте сначала сделаем чёткость.

а. Что такое символ? Короче говоря, символ - это имя. Это может быть имя переменной, имя функции, имя класса, имя typedef или что-либо кроме тех имен и знаков, которые принадлежат языку С++. Это пользователь, определенный или введенный библиотекой зависимостей (другой пользовательский).

В. Что такое внешний? В VС++ каждый исходный файл (.cpp,.c и т.д.) Рассматривается как единица перевода, компилятор компилирует по одному модулю за раз и генерирует один объектный файл (.obj) для текущей единицы перевода. (Обратите внимание, что каждый заголовочный файл, включенный в этот исходный файл, будет предварительно обработан и будет рассматриваться как часть этой единицы перевода). Все внутри единицы перевода считается внутренним, все остальное считается внешним. В С++ вы можете ссылаться на внешний символ, используя ключевые слова, такие как extern, __declspec (dllimport) и т.д.

С. Что такое "разрешение"? Resolve - термин времени связывания. Во время компоновки линкер пытается найти внешнее определение для каждого символа в объектных файлах, которые не могут найти свое определение внутри. Объем этого процесса поиска включает:

• Все объектные файлы, сгенерированные во время компиляции
• Все библиотеки (.lib), явно или неявно указанные в качестве дополнительных зависимостей этого строительного приложения.

Этот процесс поиска называется разрешением.

Д. Наконец, почему Unresolved External Symbol? Если компоновщик не может найти внешнее определение для символа, который не имеет внутреннего определения, он сообщает об ошибке неразрешенного внешнего символа.

E. Возможные причины LNK2019: ошибка неразрешенного внешнего символа. Мы уже знаем, что эта ошибка связана с тем, что компоновщик не смог найти определение внешних символов, возможные причины могут быть отсортированы как:

• Определение существует

Например, если у нас есть функция foo, определенная в a.cpp:

int foo()
{
    return 0;
}

В b.cpp мы хотим вызвать функцию foo, поэтому добавим

void foo();

объявить функцию foo() и вызвать ее в другом теле функции, скажем bar():

void bar()
{
    foo();
}

Теперь, когда вы создадите этот код, вы получите ошибку LNK2019, жалуясь, что foo - неразрешенный символ. В этом случае мы знаем, что foo() имеет свое определение в a.cpp, но отличается от того, которое мы вызываем (другое возвращаемое значение). Это так, что определение существует.

2. Определение не существует

Если мы хотим вызвать некоторые функции в библиотеке, но библиотека импорта не добавляется в дополнительный список зависимостей (установленный из: Project | Properties | Configuration Properties | Linker | Input | Additional Dependency) вашего проекта. Теперь компоновщик сообщит LNK2019, поскольку определение не существует в текущей области поиска.

Неправильно импортировать/экспортировать методы/классы по модулям /dll (специфичный для компилятора).

MSVS требует указать, какие символы экспортировать и импортировать с помощью __declspec(dllexport) и __declspec(dllimport).

Эта двойная функциональность обычно получается с помощью макроса:

#ifdef THIS_MODULE
#define DLLIMPEXP __declspec(dllexport)
#else
#define DLLIMPEXP __declspec(dllimport)
#endif

Макрос THIS_MODULE будет определен только в модуле, который экспортирует функцию. Таким образом, декларация:

DLLIMPEXP void foo();

расширяется до

__declspec(dllexport) void foo();

и сообщает компилятору экспортировать функцию, так как текущий модуль содержит свое определение. Если включить объявление в другом модуле, он будет расширяться до

__declspec(dllimport) void foo();

и сообщает компилятору, что определение находится в одной из библиотек, к которым вы привязались (см. также 1)).

Вы можете подобрать классы импорта/экспорта:

class DLLIMPEXP X
{
};

Реализации шаблонов не отображаются.

Неспециализированные шаблоны должны иметь свои определения для всех единиц перевода, которые их используют. Это означает, что вы не можете отделить определение шаблона к файлу реализации. Если вы должны отделить реализацию, обычным обходным решением является наличие файла impl, который вы укажете в конце заголовка, который объявляет шаблон. Общей ситуацией является:

template<class T>
struct X
{
    void foo();
};

int main()
{
    X<int> x;
    x.foo();
}

//differentImplementationFile.cpp
template<class T>
void X<T>::foo()
{
}

Чтобы исправить это, вы должны переместить определение X::foo в файл заголовка или какое-либо место, видимое для единицы перевода, которая его использует.

Специализированные шаблоны могут быть реализованы в файле реализации, и реализация не должна быть видимой, но специализация должна быть объявлена ​​ранее.

Для дальнейшего объяснения и другого возможного решения (явное создание экземпляра) см. этот вопрос и ответ.

неопределенная ссылка на WinMain@16 или аналогичную "необычную" main() точку main() точки входа (особенно для visual-studio).

Возможно, вы пропустили выбор правильного типа проекта с помощью вашей реальной среды IDE. IDE может захотеть связать, например, проекты приложений Windows с такой функцией точки входа (как указано в недостающей ссылке выше), вместо обычно используемого int main(int argc, char** argv); подпись.

Если ваша среда IDE поддерживает проекты Plain Console, вы можете выбрать этот тип проекта, а не проект приложения Windows.

Здесь case1 и case2 обрабатываются более подробно из реальной проблемы.

Microsoft предлагает #pragma ссылаться на нужную библиотеку во время ссылки;

#pragma comment(lib, "libname.lib")

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

Также, если вы используете сторонние библиотеки, убедитесь, что у вас есть правильные 32/64 битные файлы.

Пакет Visual Studio NuGet необходимо обновить для новой версии набора инструментов

У меня просто возникла проблема с подключением libpng с Visual Studio 2013. Проблема в том, что в файле пакета были только библиотеки для Visual Studio 2010 и 2012.

Правильное решение - надеяться, что разработчик выпустит обновленный пакет, а затем обновит его, но это сработало для меня, взломав дополнительную настройку для VS2013, указав на файлы библиотеки VS2012.

Я отредактировал пакет (в папке packages внутри каталога решений), найдя packagename\build\native\packagename.targets и внутри этого файла, скопировав все разделы v110. Я изменил v110 на v120 в только поля условия, очень осторожно оставляя пути имени файла как v110. Это просто позволило Visual Studio 2013 связать с библиотеками в 2012 году, и в этом случае он сработал.

Предположим, что у вас есть большой проект, написанный на С++, который содержит тысячу файлов .cpp и тысячу файлов .h. И пусть говорит, что проект также зависит от десяти статических библиотек. Пусть говорит, что мы в Windows, и мы строим наш проект в Visual Studio 20xx. Когда вы нажимаете Ctrl + F7 Visual Studio, чтобы начать компиляцию всего решения (предположим, что в решении есть только один проект)

Что означает компиляция?

• Поиск в Visual Studio в файл .vcxproj и начните компилировать каждый файл с расширением .cpp. Порядок компиляции undefined. Поэтому вы не должны предполагать, что файл main.cpp скомпилирован первым.
• Если файлы .cpp зависят от дополнительных файлов .h, чтобы найти символы которые могут или не могут быть определены в файле .cpp
• Если существует один .cpp файл, в котором компилятор не смог найти один символ, ошибка времени компилятора вызывает сообщение Symbol x не может быть найдено
• Для каждого файла с расширением .cpp создается объектный файл .o, а также Visual Studio записывает вывод в файл с именем ProjectName.Cpp.Clean.txt, который содержит все объектные файлы, которые должны обрабатываться компоновщиком.

Второй этап компиляции выполняется Linker.Linker должен объединить весь объектный файл и построить окончательно вывод (который может быть исполняемым или библиотекой)

Шаги по связыванию проекта

• Разберите все объектные файлы и найдите определение, которое было объявлено только в заголовках (например: Код одного метода класса, как указано в предыдущих ответах, или событие инициализация статической переменной, которая является членом внутри класса )
• Если один из символов не найден в объектных файлах, он также выполняется в дополнительных библиотеках. Для добавления новой библиотеки в проект Свойства конфигурации → Каталоги VС++ → Библиотечные каталоги, и здесь вы указали дополнительную папку для поиска библиотек и Свойства конфигурации → Linker → Вход для указав имя библиотеки. -Если Linker не смог найти символ, который вы пишете в одном .cpp, он поднимает ошибку времени компоновщика, которая может звучать как error LNK2001: unresolved external symbol "void __cdecl foo(void)" (?foo@@YAXXZ)

Наблюдение

• Когда Linker найдет один символ, он не ищет в других библиотеках для него
• Порядок связывания библиотек имеет значение.
• Если Linker находит внешний символ в одной статической библиотеке, он включает в себя символ на выходе проекта. Однако если библиотека является общей (динамической), он не включает в себя код (символы) на выходе, а Run- Могут произойти сбой времени.

Как решить эту ошибку

Ошибка времени компилятора:

• Убедитесь, что ваш синтаксический проект синтаксиса написан правильно.

Ошибка времени компоновщика

• Определите весь свой символ, который вы объявляете в своих файлах заголовков.
• Используйте #pragma once, чтобы компилятор не включал один заголовок, если он уже был включен в текущий .cpp, которые скомпилированы
• Убедитесь, что ваша внешняя библиотека не содержит символов, которые могут вступать в конфликт с другими символами, определенными в ваших файлах заголовков.
• При использовании шаблона убедитесь, что вы включили определение каждой функции шаблона в файл заголовка, чтобы компилятор мог создать соответствующий код для любых экземпляров.

Ошибка в компиляторе /IDE

У меня недавно была эта проблема, и оказалось, что это была ошибка

Используйте компоновщик, чтобы помочь диагностировать ошибку

Большинство современных линкеров включают подробный вариант, который печатается в различной степени;

• Вызов ссылки (командной строки),
• Данные о том, какие библиотеки включены в этап ссылки,
• Расположение библиотек,
• Используемые пути поиска.

Для gcc и clang; вы обычно добавляете -v -Wl,--verbose или -v -Wl,-v в командную строку. Более подробную информацию можно найти здесь:

• Linux ld man page.
• LLVM страница компоновщика.
• "Введение в GCC" глава 9.

Для MSVC в командную строку линии добавляется /VERBOSE (в частности, /VERBOSE:LIB).

• Страница MSDN на /VERBOSE вариант компоновщика.

Связанный .lib файл связан с .dll

У меня была такая же проблема. Скажем, у меня есть проекты MyProject и TestProject. Я эффективно связал файл lib для MyProject с TestProject. Однако этот файл lib был создан, так как была построена DLL для MyProject. Кроме того, я не содержал исходный код для всех методов в MyProject, а только доступ к точкам входа в DLL.

Чтобы решить эту проблему, я создал MyProject как LIB и связал TestProject с этим .lib файлом (скопируйте вложенный файл .lib в папку TestProject). Затем я смогу снова создать MyProject как DLL. Он компилируется, поскольку lib, с которым связан TestProject, содержит код для всех методов в классах MyProject.

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

Одна из возможных причин ошибок компоновщика с GCC 5.2.0 заключается в том, что по умолчанию теперь выбрана новая библиотека ABI libstdС++.

Если вы получаете ошибки компоновщика о undefined ссылках на символы, которые включают типы в пространстве имен std:: __ cxx11 или теге [abi: cxx11], то это, вероятно, указывает на то, что вы пытаетесь связать вместе файлы объектов, которые были скомпилированы с помощью различные значения для макроса _GLIBCXX_USE_CXX11_ABI. Это обычно происходит при подключении к сторонней библиотеке, которая была скомпилирована с более старой версией GCC. Если сторонняя библиотека не может быть перестроена с новым ABI, вам нужно будет перекомпилировать свой код со старым ABI.

Итак, если вы вдруг получите ошибки компоновщика при переключении на GCC после 5.1.0, это будет проверкой.

Обертка вокруг GNU ld, которая не поддерживает сценарии компоновщика

Некоторые .so файлы на самом деле скрипты компоновщика GNU ld, например. libtbb.so - это текстовый файл ASCII с этим содержимым:

INPUT (libtbb.so.2)

Некоторые более сложные сборки могут не поддерживать это. Например, если вы включаете -v в параметры компилятора, вы можете видеть, что mainwin gcc wrapper mwdip сбрасывает компоновщики script командных файлов в расширенном списке результатов библиотек для ссылки. Простая работа заключается в замене файла командной строки компоновщика script копией файла вместо (или символической ссылки), например

cp libtbb.so.2 libtbb.so

Или вы можете заменить аргумент -l полным путем .so, например. вместо -ltbb do /home/foo/tbb-4.3/linux/lib/intel64/gcc4.4/libtbb.so.2

Подружиться с шаблонами...

С учетом фрагмента кода типа шаблона с оператором (или функцией) друга;

template <typename T>
class Foo {
    friend std::ostream& operator<< (std::ostream& os, const Foo<T>& a);
};

operator<< объявляется как функция без шаблона. Для каждого типа T, используемого с Foo, должен быть не templated operator<<. Например, если объявлен тип Foo<int>, тогда должна существовать реализация оператора следующим образом:

std::ostream& operator<< (std::ostream& os, const Foo<int>& a) {/*...*/}

Так как он не реализован, компоновщик не находит его и приводит к ошибке.

Чтобы исправить это, вы можете объявить оператор шаблона перед типом Foo, а затем объявить его другом, соответствующим экземпляром. Синтаксис немного неудобен, но выглядит следующим образом:

// forward declare the Foo
template <typename>
class Foo;

// forward declare the operator <<
template <typename T>
std::ostream& operator<<(std::ostream&, const Foo<T>&);

template <typename T>
class Foo {
    friend std::ostream& operator<< <>(std::ostream& os, const Foo<T>& a);
    // note the required <>        ^^^^
    // ...
};

template <typename T>
std::ostream& operator<<(std::ostream&, const Foo<T>&)
{
  // ... implement the operator
}

Приведенный выше код ограничивает дружбу оператора соответствующим экземпляром Foo, т.е. экземпляр operator<< <int> ограничен доступом к частным членам экземпляра Foo<int>.

Альтернативы включают:

• Позволяя дружбе распространяться на все экземпляры шаблонов, следующим образом:

  template <typename T>
  class Foo {
      template <typename T1>
      friend std::ostream& operator<<(std::ostream& os, const Foo<T1>& a);
      // ...
  };
  

• Или реализация для operator<< может быть выполнена внутри внутри определения класса;

  template <typename T>
  class Foo {
      friend std::ostream& operator<<(std::ostream& os, const Foo& a)
      { /*...*/ }
      // ...
  };
  

Обратите внимание, что когда объявление оператора (или функции) появляется только в классе, имя не доступно для "нормального" поиска, только для зависимого от аргумента поиска, от cppreference;

Имя, объявленное ранее в объявлении друга в классе или классе, шаблон X становится членом самого внутреннего охватывающего пространства имен X, но недоступен для поиска (кроме зависимого от аргумента поиска, который учитывает X), если соответствующее объявление на область пространства имен предоставляется...

Далее читаются друзья шаблонов в cppreference и Часто задаваемые вопросы по С++.

Список кодов, показывающий методы выше.

В качестве побочного примечания к образцу неудачного кода; g++ предупреждает об этом следующим образом

warning: friend declaration 'std::ostream& operator<<(...)' declares a non-template function [-Wnon-template-friend]

note: (if this is not what you intended, make sure the function template has already been declared and add <> after the function name here)

Ваша ссылка потребляет библиотеки перед файлами объектов, которые относятся к ним

• Вы пытаетесь скомпилировать и связать свою программу с инструментальной цепочкой GCC.
• В вашей ссылке указаны все необходимые библиотеки и пути поиска библиотек
• Если libfoo зависит от libbar, тогда ваша ссылка правильно помещает libfoo до libbar.
• Ваша связь с ошибками undefined reference to не работает.
• Но все undefined somethings объявлены в файлах заголовков, которые у вас есть #include d и фактически определены в библиотеках, которые вы связываете.

Примеры в C. Они также могут быть С++

Минимальный пример, связанный с созданной вами статической библиотекой

my_lib.c

#include "my_lib.h"
#include <stdio.h>

void hw(void)
{
    puts("Hello World");
}

my_lib.h

#ifndef MY_LIB_H
#define MT_LIB_H

extern void hw(void);

#endif

eg1.c

#include <my_lib.h>

int main()
{
    hw();
    return 0;
}

Вы создаете свою статическую библиотеку:

$ gcc -c -o my_lib.o my_lib.c
$ ar rcs libmy_lib.a my_lib.o

Вы компилируете свою программу:

$ gcc -I. -c -o eg1.o eg1.c

Вы пытаетесь связать его с libmy_lib.a и сбой:

$ gcc -o eg1 -L. -lmy_lib eg1.o 
eg1.o: In function `main':
eg1.c:(.text+0x5): undefined reference to `hw'
collect2: error: ld returned 1 exit status

Тот же результат, если вы выполните компиляцию и ссылку за один шаг, например:

$ gcc -o eg1 -I. -L. -lmy_lib eg1.c
/tmp/ccQk1tvs.o: In function `main':
eg1.c:(.text+0x5): undefined reference to `hw'
collect2: error: ld returned 1 exit status

Минимальный пример, включающий общую системную библиотеку, библиотеку сжатия libz

eg2.c

#include <zlib.h>
#include <stdio.h>

int main()
{
    printf("%s\n",zlibVersion());
    return 0;
}

Скомпилируйте свою программу:

$ gcc -c -o eg2.o eg2.c

Попробуйте связать свою программу с libz и выполните сбой:

$ gcc -o eg2 -lz eg2.o 
eg2.o: In function `main':
eg2.c:(.text+0x5): undefined reference to `zlibVersion'
collect2: error: ld returned 1 exit status

То же самое, если вы компилируете и связываете за один раз:

$ gcc -o eg2 -I. -lz eg2.c
/tmp/ccxCiGn7.o: In function `main':
eg2.c:(.text+0x5): undefined reference to `zlibVersion'
collect2: error: ld returned 1 exit status

И вариант на примере 2 с участием pkg-config:

$ gcc -o eg2 $(pkg-config --libs zlib) eg2.o 
eg2.o: In function `main':
eg2.c:(.text+0x5): undefined reference to `zlibVersion'

Что вы делаете неправильно?

В последовательности объектных файлов и библиотек, которые вы хотите связать, чтобы сделать свой вы размещаете библиотеки перед объектными файлами, которые ссылаются на их. Вы должны поместить библиотеки после того, как файлы объектов, которые ссылаются к ним.

Правильно ссылайтесь на пример 1:

$ gcc -o eg1 eg1.o -L. -lmy_lib

Success

$ ./eg1 
Hello World

Правильно ссылайтесь на пример 2:

$ gcc -o eg2 eg2.o -lz

Success

$ ./eg2 
1.2.8

Правильно ссылайтесь на пример 2 pkg-config:

$ gcc -o eg2 eg2.o $(pkg-config --libs zlib) 
$ ./eg2
1.2.8

Объяснение

Чтение необязательно здесь.

По умолчанию команда привязки, сгенерированная GCC, в вашем дистрибутиве, расходует файлы в ссылке слева направо последовательность командной строки. Когда он обнаруживает, что файл ссылается на что-то и не содержит определения для него, будет искать определение в файлах дальше вправо. Если в конечном итоге оно найдет определение, ссылка разрешена. Если какие-либо ссылки остаются неразрешенными в конце, связь не выполняется: компоновщик не ищет назад.

Сначала пример 1, со статической библиотекой my_lib.a

Статическая библиотека - это индексированный архив объектных файлов. Когда компоновщик находит -lmy_lib в последовательности связей и вычисляет, что это относится к статической библиотеке ./libmy_lib.a, она хочет знать, ваша программа требуется любой из объектных файлов в libmy_lib.a.

В libmy_lib.a есть только объектный файл, а именно my_lib.o, и только одна вещь определена в my_lib.o, а именно: функция hw.

Компонент решает, что ваша программа нуждается в my_lib.o тогда и только тогда, когда она уже знает, что ваша программа относится к hw, в одном или нескольких объектных файлах, которые уже есть добавлен в программу, и что ни один из файлов объектов, которые он уже добавил содержит определение для hw.

Если это так, то компоновщик извлечет из библиотеки my_lib.o копию добавьте его в свою программу. Затем ваша программа содержит определение для hw, поэтому его ссылки на hw разрешены.

Когда вы пытаетесь связать программу следующим образом:

$ gcc -o eg1 -L. -lmy_lib eg1.o

компоновщик не добавил eg1.o к программе, когда видит -lmy_lib. Потому что в этот момент он не видел eg1.o. Ваша программа еще не ссылается на hw: it пока не делает никаких ссылок, потому что все ссылки, которые он делает находятся в eg1.o.

Таким образом, компоновщик не добавляет my_lib.o в программу и не имеет дальнейшего используйте для libmy_lib.a.

Затем он находит eg1.o и добавляет его в программу. Объектный файл в последовательность ссылок всегда добавляется в программу. Теперь программа делает ссылка на hw и не содержит определения hw; но в последовательности связей нет ничего, что могло бы обеспечить отсутствие определение. Ссылка на hw заканчивается неразрешенной, и связь не выполняется.

Во-вторых, пример 2, с общей библиотекой libz

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

Многие дистрибутивы Linux сегодня настраивают свою привязку GCC так, чтобы ее языковые драйверы (gcc, g++, gfortran и т.д.) проинструктировать системный компоновщик (ld) для связывания разделяемых библиотек по мере необходимости. У вас есть один из этих дистрибутивов.

Это означает, что, когда компоновщик находит -lz в последовательности связей и выясняет, что это относится к общей библиотеке (скажем) /usr/lib/x86_64-linux-gnu/libz.so, она хочет знать, есть ли какие-либо ссылки, которые она добавила к вашей программе, которые еще не определены, имеют определения, которые экспортируются с помощью libz

Если это так, то компоновщик не будет копировать любые куски из libz и добавьте их в свою программу; вместо этого он просто обработает код вашей программы так что: -

• Во время выполнения загрузчик системной программы загрузит копию libz в тот же процесс, что и ваша программа, когда он загружает копию вашей программы, для ее запуска.

• Во время выполнения, когда ваша программа ссылается на то, что определено в libz, эта ссылка использует определение, экспортированное копией libz в тот же процесс.

Ваша программа хочет ссылаться только на одну вещь, которая имеет определение, экспортированное libz, а именно функцию zlibVersion, которая упоминается только один раз, в eg2.c. Если компоновщик добавляет эту ссылку к вашей программе, а затем находит определение экспортируется libz, ссылка разрешена

Но когда вы пытаетесь связать программу, например:

gcc -o eg2 -lz eg2.o

порядок событий неверен точно так же, как в примере 1. В момент, когда компоновщик находит -lz, ссылок на что-либо нет в программе: все они находятся в eg2.o, который еще не был замечен. Итак компоновщик решает, что он не нужен для libz. Когда он достигнет eg2.o, добавляет его в программу, и затем имеет undefined ссылку на zlibVersion, последовательность связей закончена; эта ссылка не решена, и связь не удалась.

Наконец, вариант pkg-config примера 2 имеет теперь очевидное объяснение. После расширения оболочки:

gcc -o eg2 $(pkg-config --libs zlib) eg2.o

становится:

gcc -o eg2 -lz eg2.o

который снова является примером 2.

Я могу воспроизвести проблему в примере 1, но не в примере 2

Связь:

gcc -o eg2 -lz eg2.o

отлично подходит для вас!

(Или: эта связь работала хорошо для вас, скажем, Fedora 23, но не работает на Ubuntu 16.04)

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

В тот же день для UNIX-подобных систем было нормально связывать статические и общие библиотеки по разным правилам. Статические библиотеки в последовательности связей были связаны по мере необходимости, объясняется в примере 1, но разделяемые библиотеки были связаны безоговорочно.

Такое поведение экономично в режиме ссылки, потому что линкер не должен обдумывать нужна ли библиотека совместно используемой библиотеке: если она является общей библиотекой, ссылку. Большинство библиотек в большинстве связей являются общими библиотеками. Но есть и недостатки: -

• Это неэкономично во время выполнения, поскольку это может привести к тому, что общие библиотеки будут загружаются вместе с программой, даже если они не нужны.

• Различные правила привязки для статических и разделяемых библиотек могут вводить в заблуждение к незнакомым программистам, которые могут не знать, есть ли -lfoo в их связи будет разрешено до /some/where/libfoo.a или /some/where/libfoo.so, и может не понимать разницу между общими и статическими библиотеками в любом случае.

Этот компромисс привел сегодня к раскольнической ситуации. Некоторые дистрибутивы изменили свои правила привязки GCC для разделяемых библиотек, чтобы, по мере необходимости, принцип применяется ко всем библиотекам. Некоторые дистрибутивы застряли со старым путь.

Почему я все еще получаю эту проблему, даже если я компилирую-ссылку в то же время?

Если я просто сделаю:

$ gcc -o eg1 -I. -L. -lmy_lib eg1.c

Конечно, gcc должен сначала скомпилировать eg1.c, а затем связать полученный результат объектный файл с libmy_lib.a. Итак, как он не может знать этот объектный файл если он выполняет привязку?

Поскольку компиляция и привязка к одной команде не меняют порядок последовательности связей.

Когда вы запустите команду выше, gcc выяснит, что вы хотите компилировать + связь. Таким образом, за кулисами, он генерирует команду компиляции и запускает он генерирует команду привязки и запускает ее, как если бы вы запускали две команды:

$ gcc -I. -c -o eg1.o eg1.c
$ gcc -o eg1 -L. -lmy_lib eg1.o

Таким образом, связь не работает так же, как если бы вы выполняли эти две команды. только разница, которую вы замечаете при ошибке, заключается в том, что gcc сгенерировал временный файл объекта в файле компиляции + ссылка, потому что вы не говорите об этом использовать eg1.o. Мы видим:

/tmp/ccQk1tvs.o: In function `main'

вместо:

eg1.o: In function `main':

См. также

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

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

Непоследовательные определения UNICODE

Конструкция Windows UNICODE построена с TCHAR и т.д., которая определяется как wchar_t и т.д. Когда не строится с UNICODE, определенным как build с TCHAR, определенным как char и т.д. Эти UNICODE и _UNICODE определяет все "T" типы строк; LPTSTR, LPCTSTR и их лося.

Создание одной библиотеки с UNICODE, определенной и попытки связать ее в проекте, где UNICODE не определен, приведет к ошибкам компоновщика, поскольку в определении TCHAR будет несовпадение; char против wchar_t.

Обычно ошибка включает в себя функцию a с производным типом char или wchar_t, это может также включать std::basic_string<> и т.д. При просмотре затронутой функции в коде часто будет ссылка на TCHAR или std::basic_string<TCHAR> и т.д. Это контрольный знак того, что этот код изначально предназначался как для UNICODE, так и для многобайтового символа ( или "узкий" ).

Чтобы исправить это, создайте все необходимые библиотеки и проекты с последовательным определением UNICODE (и _UNICODE).

• Это можно сделать либо с помощью:

  #define UNICODE
  #define _UNICODE
  

• Или в настройках проекта;

  Свойства проектa > Общие > Значения по умолчанию > Набор символов

• Или в командной строке;

  /DUNICODE /D_UNICODE
  

Альтернатива применима также, если UNICODE не предназначен для использования, убедитесь, что определения не установлены, и/или многосимвольная настройка используется в проектах и ​​последовательно применяется.

Не забывайте быть совместимыми между сборками "Release" и "Debug".

Когда ваши пути включения различаются

Ошибки компоновщика могут произойти, если заголовочный файл и связанная с ним общая библиотека (файл .lib) не синхронизируются. Позволь мне объяснить.

Как работают линкеры? Линкер соответствует объявлению функции (объявленному в заголовке) с его определением (в общей библиотеке) путем сравнения их подписи. Вы можете получить ошибку компоновщика, если компоновщик не найдет определение функции, которое идеально подходит.

Возможно ли получить ошибку компоновщика, даже если объявление и определение, похоже, совпадают? Да! Они могут выглядеть одинаково в исходном коде, но это действительно зависит от того, что видит компилятор. По существу, вы можете столкнуться с такой ситуацией:

// header1.h
typedef int Number;
void foo(Number);

// header2.h
typedef float Number;
void foo(Number); // this only looks the same lexically

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

Вы можете спросить, как это получается в такой ситуации? Включить пути, конечно! Если при компиляции разделяемой библиотеки путь include ведет к header1.h, и вы в конечном итоге используете header2.h в своей собственной программе, вы оставите царапины в своем заголовке, задаваясь вопросом, что произошло (каламбур).

Пример того, как это может произойти в реальном мире, объясняется ниже.

Дальнейшая разработка с примером

У меня есть два проекта: graphics.lib и main.exe. Оба проекта зависят от common_math.h. Предположим, что библиотека экспортирует следующую функцию:

// graphics.lib    
#include "common_math.h" 

void draw(vec3 p) { ... } // vec3 comes from common_math.h

И затем вы идете вперед и включаете библиотеку в свой собственный проект.

// main.exe
#include "other/common_math.h"
#include "graphics.h"

int main() {
    draw(...);
}

Boom! Вы получаете ошибку компоновщика, и вы не знаете, почему это не удается. Причина в том, что в общей библиотеке используются разные версии одного и того же include common_math.h (я сделал это очевидным здесь в этом примере, включив другой путь, но это может быть не всегда так очевидно. Возможно, путь include отличается в настройки компилятора).

Обратите внимание, что в этом примере компоновщик сказал бы вам, что не смог найти draw(), когда на самом деле вы знаете, что он явно экспортируется библиотекой. Вы могли часами царапать себе голову, думая, что пошло не так. Дело в том, что компоновщик видит другую подпись, потому что типы параметров немного отличаются. В этом примере, vec3 является другим типом в обоих проектах в отношении компилятора. Это может произойти из-за того, что они состоят из двух немного разных файлов include (возможно, включенные файлы поступают из двух разных версий библиотеки).

Отладка компоновщика

DUMPBIN - ваш друг, если вы используете Visual Studio. Я уверен, что другие компиляторы имеют другие подобные инструменты.

Процесс выполняется следующим образом:

• Обратите внимание на странное искаженное имя, указанное в ошибке компоновщика. (например, draw @graphics @XYZ).
• Выгрузить экспортированные символы из библиотеки в текстовый файл.
• Найдите экспортированный символ, представляющий интерес, и обратите внимание, что измененное имя отличается.
• Обратите внимание на то, почему искаженные имена оказались разными. Вы могли бы видеть, что типы параметров различны, хотя они выглядят одинаково в исходном коде.
• Причина, почему они разные. В приведенном выше примере они различаются из-за разных файлов include.

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

РЕДАКТИРОВАТЬ 1: переписать первый раздел, который будет легче понять. Пожалуйста, прокомментируйте ниже, чтобы сообщить мне, нужно ли что-то еще исправлять. Спасибо!

Очистить и восстановить

"Чистый" сборщик может удалить "мертвую древесину", которая может быть оставлена ​​лежащей вокруг предыдущих сборок, неудачными сборками, неполными сборками и другими проблемами сборки, связанными с сборкой.

В общем случае IDE или сборка будет включать в себя некоторую форму "чистой" функции, но это может быть неправильно настроено (например, в ручном make файле) или может завершиться неудачей (например, промежуточные или результирующие двоичные файлы доступны только для чтения).

После завершения "очистки" убедитесь, что "чистый" преуспел, и все созданные промежуточные файлы (например, автоматический make файл) были успешно удалены.

Этот процесс можно рассматривать как окончательный вариант, но часто является хорошим первым шагом; особенно если недавно был добавлен код, связанный с ошибкой (локально или из исходного репозитория).

Отсутствует "extern" в const объявления/определения переменных (только С++)

Для людей, приезжающих с C, может быть неожиданностью, что в С++ глобальные переменные const имеют внутреннюю (или статическую) связь. В C это не так, поскольку все глобальные переменные неявно extern (т.е. Когда отсутствует ключевое слово static).

Пример:

// file1.cpp
const int test = 5;    // in C++ same as "static const int test = 5"
int test2 = 5;

// file2.cpp
extern const int test;
extern int test2;

void foo()
{
 int x = test;   // linker error in C++ , no error in C
 int y = test2;  // no problem
}

- использовать заголовочный файл и включать его в файлы file2.cpp и file1.cpp

extern const int test;
extern int test2;

В качестве альтернативы можно было объявить переменную const в файле file1.cpp с явным extern

Несмотря на то, что это довольно старые вопросы с несколькими принятыми ответами, я хотел бы поделиться, как разрешить непонятную ошибку "неопределенной ссылки на".

Различные версии библиотек

Я использовал псевдоним для ссылки на std::filesystem::path: файловая система находится в стандартной библиотеке с С++ 17, но моя программа также должна была скомпилироваться в С++ 14, поэтому я решил использовать переменную alias:

#if (defined _GLIBCXX_EXPERIMENTAL_FILESYSTEM) //is the included filesystem library experimental? (C++14 and newer: <experimental/filesystem>)
using path_t = std::experimental::filesystem::path;
#elif (defined _GLIBCXX_FILESYSTEM) //not experimental (C++17 and newer: <filesystem>)
using path_t = std::filesystem::path;
#endif

Скажем, у меня есть три файла: main.cpp, file.h, file.cpp:

• file.h #include < experimental :: filestystem > и содержит код выше
• file.cpp, реализация file.h, #include " file.h "
• main.cpp #include < filestystem > и " file.h "

Обратите внимание на разные библиотеки, используемые в файлах main.cpp и file.h. Поскольку main.cpp # include'd " file.h " после < filestystem >, версия используемой файловой системы была С++ 17. Я использовал для компиляции программы со следующими командами:

$ g++ -g -std=c++17 -c main.cpp → компилирует main.cpp на main.o
$ g++ -g -std=c++17 -c file.cpp → компилирует файлы file.cpp и file.h в файл file.o
$ g++ -g -std=c++17 -o executable main.o file.o -lstdc++fs → ссылки main.o и file.o

Таким образом, любая функция, содержащаяся в файле.o и используемая в main.o, которая требовала path_t давала ошибки "неопределенной ссылки", потому что main.o ссылался на std::filesystem::path но file.o на std::experimental::filesystem::path.

разрешение

Чтобы исправить это, мне просто нужно было изменить <experimental :: filestystem> в файле.h на <filestystem>.

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

Поведение gcc по умолчанию состоит в том, что все символы видны. Однако, когда единицы перевода построены с опцией -fvisibility=hidden, только функции/символы, отмеченные __attribute__ ((visibility ("default"))) являются внешними в результирующем общем объекте.

Вы можете проверить, являются ли символы, которые вы ищете, внешними, вызывая:

# -D shows (global) dynamic symbols that can be used from the outside of XXX.so
nm -D XXX.so | grep MY_SYMBOL 

скрытые/локальные символы отображаются с помощью nm с символом нижнего регистра, например t вместо "T для кодового раздела:

nm XXX.so
00000000000005a7 t HIDDEN_SYMBOL
00000000000005f8 T VISIBLE_SYMBOL

Вы также можете использовать nm с опцией -C для демонстрации имен (если использовался C++).

Подобно Windows-dll, можно было бы отметить публичные функции с помощью определения, например DLL_PUBLIC определенного как:

#define DLL_PUBLIC __attribute__ ((visibility ("default")))

DLL_PUBLIC int my_public_function(){
  ...
}

Что примерно соответствует версии Windows/MSVC:

#ifdef BUILDING_DLL
    #define DLL_PUBLIC __declspec(dllexport) 
#else
    #define DLL_PUBLIC __declspec(dllimport) 
#endif

Более подробную информацию о видимости можно найти в wiki.

Когда блок перевода скомпилирован с -fvisibility=hidden результирующие символы имеют по-прежнему внешнюю связь (показан с типом символа верхнего регистра на nm) и могут быть использованы для внешней связи без проблем, если объектные файлы становятся частью статических библиотек. Связь становится локальной только тогда, когда объектные файлы связаны с общей библиотекой.

Чтобы найти, какие символы в объектном файле скрыты, выполните:

>>> objdump -t XXXX.o | grep hidden
0000000000000000 g     F .text  000000000000000b .hidden HIDDEN_SYMBOL1
000000000000000b g     F .text  000000000000000b .hidden HIDDEN_SYMBOL2

Функции или методы класса определяются в исходных файлах с помощью inline спецификатора.

Пример:-

main.cpp

#include "gum.h"
#include "foo.h"

int main()
{
    gum();
    foo f;
    f.bar();
    return 0;
}

foo.h(1)

#pragma once

struct foo {
    void bar() const;
};

gum.h(1)

#pragma once

extern void gum();

foo.cpp(1)

#include "foo.h"
#include <iostream>

inline /* <- wrong! */ void foo::bar() const {
    std::cout << __PRETTY_FUNCTION__ << std::endl;
}

gum.cpp(1)

#include "gum.h"
#include <iostream>

inline /* <- wrong! */ void gum()
{
    std::cout << __PRETTY_FUNCTION__ << std::endl;
}

Если вы укажете, что gum (аналогично, foo::bar) является inline при определении, тогда компилятор встроит gum (если он выберет), с помощью: -

• не испускает никакого уникального определения gum, и, следовательно,
• не испускает какой-либо символ, с помощью которого компоновщик может ссылаться на определение gum, и вместо
• замена всех вызовов gum встроенными копиями скомпилированного тела gum.

В результате, если вы определяете gum inline в исходном файле gum.cpp, он компилируется в объектный файл gum.o в котором все вызовы gum являются встроенными, и не определен символ, с помощью которого компоновщик может ссылаться на gum. Когда вы связываете gum.o с программой вместе с другим объектным файлом, например, main.o который ссылается на внешний символ gum, компоновщик не может разрешить эти ссылки. Таким образом, связь не работает:

Обобщение:

g++ -c  main.cpp foo.cpp gum.cpp

Ссылка на сайт:

$ g++ -o prog main.o foo.o gum.o
main.o: In function 'main':
main.cpp:(.text+0x18): undefined reference to 'gum()'
main.cpp:(.text+0x24): undefined reference to 'foo::bar() const'
collect2: error: ld returned 1 exit status

Вы можете определить gum только как inline если компилятор может видеть его определение в каждом исходном файле, в котором может быть вызван gum. Это означает, что его встроенное определение должно существовать в заголовочном файле, который вы включаете в каждый исходный файл, который вы компилируете, в который может вызываться gum. Сделайте одно из двух:

Либо не включайте определения

Удалите inline спецификатор из определения исходного файла:

foo.cpp(2)

#include "foo.h"
#include <iostream>

void foo::bar() const {
    std::cout << __PRETTY_FUNCTION__ << std::endl;
}

gum.cpp(2)

#include "gum.h"
#include <iostream>

void gum()
{
    std::cout << __PRETTY_FUNCTION__ << std::endl;
}

Перестройте с этим:

$ g++ -c  main.cpp foo.cpp gum.cpp
imk@imk-Inspiron-7559:~/develop/so/scrap1$ g++ -o prog main.o foo.o gum.o
imk@imk-Inspiron-7559:~/develop/so/scrap1$ ./prog
void gum()
void foo::bar() const

Успех.

Или правильно

Встроенные определения в заголовочных файлах:

foo.h(2)

#pragma once
#include <iostream>

struct foo {
    void bar() const  { // In-class definition is implicitly inline
        std::cout << __PRETTY_FUNCTION__ << std::endl;
    }
};
// Alternatively...
#if 0
struct foo {
    void bar() const;
};
inline void foo::bar() const  {
    std::cout << __PRETTY_FUNCTION__ << std::endl;
}
#endif

резинка (2)

#pragma once
#include <iostream>

inline void gum() {
    std::cout << __PRETTY_FUNCTION__ << std::endl;
}

Теперь нам не нужны foo.cpp или gum.cpp:

$ g++ -c main.cpp
$ g++ -o prog main.o
$ ./prog
void gum()
void foo::bar() const

Разные архитектуры

Вы можете увидеть сообщение как:

library machine type 'x64' conflicts with target machine type 'X86'

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

В Visual Studio это происходит из-за неправильной "Платформы", и вам нужно либо выбрать подходящую, либо установить правильную версию библиотеки.

В Linux это может быть связано с неправильной папкой библиотеки (например, с использованием lib вместо lib64).

В MacOS есть возможность отправить обе архитектуры в одном файле. Может быть, что ссылка ожидает, что обе версии будут там, но только одна есть. Это также может быть проблема с неправильной папкой lib/lib64 которой находится библиотека.

Ошибка возникает, когда компоновщик не может найти какое-либо определение для определения в файле декларации, то есть из файла заголовка или файла декларации. Это происходит, когда реализация не найдена.

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

Получение неуправляемого/родного класса С++/CLI в DLL в неуправляемый unit test в Visual Studio

Проблема

Я использую направления MS Модуль тестирования собственного кода с помощью Test Explorer

Сначала я создаю неуправляемую DLL, используя шаблоны. Это дает мне:

Win32Project1.h

#ifdef WIN32PROJECT1_EXPORTS
#define WIN32PROJECT1_API __declspec(dllexport)
#else
#define WIN32PROJECT1_API __declspec(dllimport)
#endif

// This class is exported from the Win32Project1.dll
class WIN32PROJECT1_API CWin32Project1 {
public:
    CWin32Project1(void);

    bool Foo();
};

extern WIN32PROJECT1_API int nWin32Project1;

WIN32PROJECT1_API int fnWin32Project1(void);

Win32Project1.cpp

#include "stdafx.h"
#include "Win32Project1.h"


// This is an example of an exported variable
WIN32PROJECT1_API int nWin32Project1=0;

// This is an example of an exported function.
WIN32PROJECT1_API int fnWin32Project1(void)
{
    return 42;
}

// This is the constructor of a class that has been exported.
// see Win32Project1.h for the class definition
CWin32Project1::CWin32Project1()
{
    return;
}

bool CWin32Project1::Foo() {return true;}

Затем я создаю неуправляемый проект unit test из шаблонов и добавлю unit test.

UnitTest1.cpp

#include "stdafx.h"
#include "CppUnitTest.h"
#include "..\Win32Project1\Win32Project1.h"

using namespace Microsoft::VisualStudio::CppUnitTestFramework;

namespace UnitTest1
{       
    TEST_CLASS(UnitTest1)
    {
    public:

        TEST_METHOD(TestMethod1)
        {
            auto bar = new CWin32Project1();
            Assert::AreEqual(true, bar->Foo());
        }

    };
}

Когда я скомпилирую это, я получаю ошибки:

1>unittest1.obj : error LNK2019: unresolved external symbol "__declspec(dllimport) public: __thiscall CWin32Project1::CWin32Project1(void)" ... referenced in function "public: void __thiscall UnitTest1::UnitTest1::TestMethod1(void)" (?TestMethod1@UnitTest1@1@QAEXXZ)
1>unittest1.obj : error LNK2019: unresolved external symbol "__declspec(dllimport) public: bool __thiscall CWin32Project1::Foo(void)" ... referenced in function "public: void __thiscall UnitTest1::UnitTest1::TestMethod1(void)"

Решение

UnitTest1.vcxproj нуждается в следующих изменениях:

<AdditionalLibraryDirectories>$(SolutionDir)Debug;$(VCInstallDir)UnitTest\lib;%(AdditionalLibraryDirectories)</AdditionalLibraryDirectories>
<AdditionalDependencies>Win32Project1.lib;%(AdditionalDependencies)</AdditionalDependencies>