Ошибка на этапе линковки это

линкеру не сообщили, что нужно линковаться с библиотекой.

нет. ошибки линкера — это ошибки линковки, а не компиляции.

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

зайдите в свойства проекта (у вас ведьвижуал студия),
в раздел Linker
и укажите там имя библиотеки,
и путь, где её можно найти.

а если у меня нет депрессии,
что тогда обязательно/не обязательно
мне делать в публичном/любом другом месте?

вы находитесь на форуме программистов, а не блондинок.
ваше условие — дырявое насквозь.
любой компилятор ткнул бы вас носом в:
«результат возвращается не на всех ветках if»

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

Плюсы и минусы компилируемости в машинный код

Плюсы:

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

Минусы:

• нужно компилировать для каждой платформы (т.е. программу, написанную на языке, который компилируется в машинный код, недостаточно скомпилировать однажды чтобы её можно было запускать на любой платформе);
• сложность внесения изменения в программу — нужно перекомпилировать заново.

int main(int argc, char ** argv)
{
 return 0;
}

Лекция 3

Многофайловая компоновка

Говорят, что переменная описана (определена), если она объявлена и под неё
выделена память. Рассмотрим следующий пример, пусть в проекте есть два файла:

/* a.cpp */
extern int n;    // "Где-то дальше определено"
void f(int);     // Предварительное объявление

void main() {
    n = 5; f(n);
}


/* b.cpp */
#include <iostream>
int i;           // Описание переменной

// Определение функции
void f(int i) {
    std::cout << i;
}

В C++ имеет место независимая компиляция: все файлы проекта компилируются
независимо один от другого. Компиляция состоит из этапа собственно компиляции
и этапа линковки.

Заголовочные файлы

Содержат заголовки всех функций и объявления переменных, обычно имеют
расширение *.h (header). Теперь можно вынести объявления функций из всех
файлов в один (заголовочный):

/* myheader.h */
extern int n;
void f(int);

/* myheader.cpp */
#include <iostream>
int n;

void f(int i) {
    std::cout << i;
}


/* a.cpp */
#include "myheader.h"

void main() {
    n = 5; f(n);
}

/* b.cpp */
#include "myheader.h"

void makeZero() {
    n = 0;
}

Имена пользовательских заголовочных файлов в директиве include
заключаются в двойные кавычки, а имена стандартных заголовочных файлов —
в угловые скобки. Стандартные заголовочные файлы расположены в /INCLUDE.
Поиск пользовательских файлов производится в текущем каталоге.

Замечание: inline-функции не сохраняются в исходном коде, так как больше не
используются (а сразу встраиваются на место вызова). Чтобы воспользоваться
такими функциями в другой единице компиляции, их нужно поместить в
заголовочный файл.

Содержимое заголовочных файлов

Что может содержать заголовочный файл:

В заголовочном файле никогда не должно быть:

Глобальные описания в C++ и необходимость пространств имен

При простом определении глобальных сущностей они объединяются в глобальном пространстве имен. Для создания локального пространства имен используется ключевое слово namespace.

namespace MyNamespace{
    ... // содержимое пространства имён: типы, функции, что-угодно…
}

Пространства имен и заголовочные файлы

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

/* header.h */
namespace MyNamespace{
    extern int n;
    void f();
}

Основные этапы сборки проекта

1. Препроцессирование.
2. Компиляция каждого *.cpp-файла в объектный код (файлы *.obj или *.o).
3. Линковка — сборка всех объектных файлов в один исполняемый
   (*.exe или ELF).

Ошибки во время линковки

• Одинаковые объявления в одном пространстве имен.
• Ошибки при использовании #include "*.cpp" (грубая ошибка).
• Отсутствие описания функции.
• Отсутствие main() во всех файлах проектах.
• Несколько объявлений main().

Особенности линковки

• Константы имеют внутреннюю линковку.
• inline-функции «погибают» при компиляции.

При сборке программы с включенными опциями для GCOV можно получить ошибку на этапе линковки следующего вида:

/usr/bin/ld: ./a.out: hidden symbol `__gcov_merge_add’ in /usr/lib/gcc/i486-linux-gnu/4.1.3/libgcov.a(_gcov_merge_add.o) is referenced by DSO
/usr/bin/ld: final link failed: Nonrepresentable section on output

Скорее всего причина заключается в том, что к исполняемому модулю линкуются библиотеки, которые тоже были скомпилированы с опциями -fprofile-arcs -ftest-coverage.

Простой пример, иллюстрирующий проблему.

Даны два файла:

=== a.cpp
#include <stdio.h>

Из файла b.cpp делаем статическую библиотеку libmy.a, а из файла a.cpp — исполняемый модуль a.out:

g++ -c -fprofile-arcs -ftest-coverage b.cpp
g++ -shared -o libmy.a ./b.o
g++ -c -fprofile-arcs -ftest-coverage a.cpp
g++ -o a.out a.o -L. -lmy


Получаем ошибку вида «undefined reference to `__gcov_init’» — забыли подключить библиотеку libgcov.a.

Подключаем к сборке требуемую библиотеку как обычно:

g++ -c -fprofile-arcs -ftest-coverage b.cpp
g++ -shared -o libmy.a ./b.o
g++ -c -fprofile-arcs -ftest-coverage a.cpp
g++ -o a.out a.o -L. -lmy -lgcov


Вот здесь-то и получаем странную ошибку:

/usr/bin/ld: ./a.out: hidden symbol `__gcov_merge_add' in /usr/lib/gcc/i486-linux-gnu/4.1.3/libgcov.a(_gcov_merge_add.o) is referenced by DSO
/usr/bin/ld: final link failed: Nonrepresentable section on output


Исправить это просто. Нужно подключить библиотеку libgcov.a не только к сборке исполняемого модуля, но и к сборке статической библиотеки:

g++ -c -fprofile-arcs -ftest-coverage b.cpp
g++ -shared -o libmy.a ./b.o -lgcov
g++ -c -fprofile-arcs -ftest-coverage a.cpp
g++ -o a.out a.o -L. -lmy -lgcov


Вот и всё. Так нужно поступить с каждой библиотекой, исходный код которой скомпилирован с опциями -fprofile-arcs -ftest-coverage.