Здраствуйте, помогите прийти к решению проблемы. Есть класс class Window { public:

static GLFWwindow* window;
};
статическая переменная которого определена в файле его реализации GLFWwindow* Window::window;
но есть необходимость использовать ее в другого классе
class Events {
public:
static int initialize();
};
а именно в функции
int Events::initialize() {
GLFWwindow* window = Window::window;
return 0;
}
как это можно сделать?

Ты уже это сделал

Но компилятор так не считает

выдает Ошибка LNK2001 неразрешенный внешний символ "public: static class GLFWwindow * Window::window"

cpp файл с определением статической переменной не собираешь

Нет никаких препятствий чтобы у тебя это не получилось.

Не может быть

Ты же написал : статическая переменная которого определена в файле его реализации GLFWwindow* Window::window; Либо ты обманываешь и не определена, либо не может быть такой ошибки. Шли полный код...

код в нескольких файлах (7), как грузить?

В проект добавь файлы

Pastebin.com

https://pastebin.com/S9RUGQjs

Да все ок, должно работать

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

Порядок линковки - это что?

в каком порядке файлы принимаются компилятором

Это не имеет значения никакого

Почитай что такое раздельная компиляция. Это концепция, которая позволяет компилировать файлы независимо. После компиляции определенного файла часть имен (символов) остается неразрешенными (unresolved). Задача линковщика разрешить все unresolved символы. Сам понимаешь, здесь порядок абсолютно неважен.

ЕМНИП важен же. Насколько я помню, линковщик в одном проходе и собирает по объектникам неразрешённые символы, и разрешает эти символы. То есть если к моменту появления неразрешённого символа в другом объектнике нужный объектник ещё не обошли, то произойдёт ошибка линковки.

В 10-й студии были проблемы, которые реально решались изменением порядка линковки. в принципе, это были костыли...

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

Это разве баг? Иначе линкер бы пол века работал

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

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

Почему все либы? Так же по одной

та всё равно дорого как-то

Можно сделать спец. флаг --not_zashkvar_mode который эту фичу включает

так есть же уже что-то такое

Ну тогда проблем нет

-Wl,-\( -liba -libb -libc) если кто-то название знает то подскажите, я не могу это нагуглить нигде кроме лекции на ютубе

Многопроходность линкера? https://sourceware.org/binutils/docs-2.16/ld/Options.html -( archives -) --start-group archives --end-group The archives should be a list of archive files. They may be either explicit file names, or -l options. The specified archives are searched repeatedly until no new undefined references are created. Normally, an archive is searched only once in the order that it is specified on the command line. If a symbol in that archive is needed to resolve an undefined symbol referred to by an object in an archive that appears later on the command line, the linker would not be able to resolve that reference. By grouping the archives, they all be searched repeatedly until all possible references are resolved. Using this option has a significant performance cost. It is best to use it only when there are unavoidable circular references between two or more archives.

Абсолютно не важен.

UB - оно такое милое, знаешь ли...

Не припомню проблем в студии и msvc. Gcc грешил, да.

Что за ересь? Задача линкера, чтобы все неразрешенные символы разрешились. Где здесь о порядке?

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

Я знаю об особенностях gcc, но делать на основании этого "выводы" странно.

Насколько я помню, там при статической линковке MFC нужно было добавить некоторые lib-ки в список "исключить из сборки" и часть из них-же в список библиотек, с которыми надо линковаться. Да, звучит как бред, но без этого было не собрать прогу, которая не требовала бы установку дополнительных dll-ок на компе, где не установлена студия.