В этом файле есть функция с сигнатурой int foo(void)

ну имя, адрес и параметры, что логично

И тода линкер прросматривая по порядку объектник. Её найдет

Да. Имя.

Но это на си

На си++ эта функция в таблице экспорта будет называться как то типа ifoo@2(void)

Или еще кака-то такая хрень

А если она лежит внутри неймспейса то еще и имя неймспейса

А бедный компилятор искал foo

Вот эта хрень которая добавляется к имени функции в плюсах это называется mangling

Поэтому между двух плюсовых файлов линковщик ищет функции с mangled именами

Но если ты хочешь к плюсовому файлу прилинковать сишный

Тебе надо сообщить линковщику, что чувак, ищи не ifoo@2 а ищи _foo

Потому что это линковка с сишным объектником.

Об этом "С" и говорит после слова "extern"

Как тут правильно еще заметили есть такая вещь как ABI это совместимость на бинарном уровне(application binary interface)

Здесь речь просто о том что на разных платформах и разных реализациях компиляторов и между ними И так далее есть разные соглашения о том как передавать параметры в функцию в каком порядке как возвращать результат и куча тонкостей еще

Чтобы ты мог прилинковать одну функцию в другую тебе надо сделать это правильно. В соответсвии с ABI

В общем внутри плюсов или внутри сишки или внутри чего еще угодно это делается само

Но между разными языками надо быть осторожным.

В общем ты напрмер можешь прилинковать в сишную программу и функцию из паскаля

В паскале fastcall, вроде

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

А в си cdecl

В паскале __pascal :D

A lol

Хотя не очень актуально в 2016 году.

кхм

ты неплохо объясняешь

а что ещё можно сказать в виде extern X {...}

?

Кажется ничего кроме "C" который обслуживает си и ассемблер и "C++" который обслуживает плюсы нет

В стандарте

Но в некоторых компиляторах я знаю есть extern "Pascal" и extern "COM+"

окай

понял

чтож, огромное спасибо

а ещё такой вот вопрос

если у нас хедеры хранятся в линуксе преимущественно в /usr/include, то где хранятся их объектники и откуда линкер знает, что откуда с чем линковать?

обычно все объектники объединены в .lib файлы (.a, .la в линкусе)

Ага. И хранятся по большей части в /usr/lib

как понять "объединены"?

А линкер знает это потому что у нег есть системная переменная ld_path

Или как-то так.

в окружении такой нету

LDLIBRARYPATH

С подчеркиваниями

По-моему. Я не линуксоид могу ошибаться.

хорошо

теперь ясно

Объединены в том смысле что они скомпонованы в библиотеку.

То есть просто представь как если бы ты собирал свою программу, но без main

ну да, я понял

gcc -c

Это просто скомпилированные и слинкованные между собой функции которые экспортируются наружу.

да, без компоновки

не совсем, LD_LIBRARY_PATH указывает где искать .so файлы

уже при запуске программы

Ну, справедливости ради там есть компоновка кое-какая, но не полная. Там компоновка ровно та, которую можно статически провести.

Да, вот Станислав меня поправит.

а кто мне скажет, правильно ли я понимаю, что .so линкуются в runtime, а объектники библиотек нужны для статической линковки

так жи?

@crackedmind в линуксах статические либы резолвятся как-то иначе?

так жи?

Типа того.

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

А динамическая линковка берет код в рантайме.

ERROR: S client not available

то есть чтобы написать либу, я должен сделать сначала cpp с описанием функций, затем .h с их объявлениями, затем скомпилить в объектник и положить куда надо и затем сделать .so и положить куда надо. верно?

@crackedmind в линуксах статические либы резолвятся как-то иначе?

да вроде все так же

Достаточно будет только .h и .so

so уже в себе содержит все из объектника.

ну.... тогда программы, использующие либу попадают в зависимость. или можно сказать gcc —static и он прилинкует код нужных функций из .so статически?

Но вообще можно даже обойтись только одним .so потому что в нем есть список экспорта. Но там могут быть проблемы с пользовательскимии типами. Не забивай голову. В общем случае да .h и либа

Ох. Я вот кстати не знаю можно ли так делать.

Кажется нет.

Да. Скорее всего нельзя.

нет, в любом случае нужен статическая либа

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

нет, в любом случае нужен статическая либа

то есть в итоге надо иметь .h, .o и .so?

.h, .a & .so :) так точнее

нет, в любом случае нужен статическая либа

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

причем .a для шареда и для статической линковки отличаются

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

если ты собираешься зависеть от либы и линковать её динамически во время runtime, нужно ли в коде напрямую делать dlopen()?

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

а, ну я вот как раз за этот код и спрашиваю

Вот. Можно либо так да, либо когда делаешь свою шареную либу еще делать к ней маленький статический лоадер

то есть, если будешь зависеть от .so, тебе нужно сначала его dlopen() а потом использовать функции?

понял

все

Вернее за тебя это сейчас компиляторы делабт.

ну да, ведь libstdc++ тоже по идее .so, но явно я её не подгружаю

Угу.

вроде бы и qt не подгружают явно

хорошо

что будет, если скачать из винды noname.dll и сделать во время runtime с ней dlopen?

Это делает код внутри статических либ, который вот кстати как раз вызывается перед main

архитектура та же, API не затрагивается

Разные abi ничего не выйдет