О скомпилированых библиотеках

Вставляется описание интерфейса библиотеки а не реализация. Или ты об чём?

ибо никогда не видел, чтобы кто-то импортировал эдакие

Они подключаются на этапе линковки, а не компиляции.

Всегда при импорте просто вырезается текст из файла с кодом и вставляется на место #include.

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

Вы для себя разберитесь для чего нужны .h файлы и чем они от .c отличаются. А ещё лучше подойте к вопросу системно и почитайте качественный учебник.

То есть, мне нужно создать два файла .h: в один записать функции с кодом, а во второй только объявления; первый скомпилировать, а второй подключать инклудом. Я вас правильно понял?

Два файла

Один .h (или .hpp), другой .c или .cpp

В .h – объявления, описание интерфейса.

В .cpp – определения, код самих функций или методов.

Первый скомпилировать и после этого подключать инклудом его .h-файл.

Наглядно:

$ cat lib.h 
#pragma once
void hello();

$ cat lib.c
#include "lib.h"

#include <stdio.h>

void hello() {
    printf("Hello, World!\n");
}

$ cat main.c 
#include "lib.h"

void main() {
    hello();
}

$ gcc -shared -fPIC lib.c -o lib1.so

$ gcc main.c -L . -l1 -o main

$ ./main 
./main: error while loading shared libraries: lib1.so: cannot open shared object file: No such file or directory

$ LD_LIBRARY_PATH=. ./main 
Hello, World!

Это настолько основы, что тут сомнительна необходимость что-то здесь отвечать. Чтобы получить систематизированные знания, почитай какую-нибудь книгу по основам c/c++.

В заголовочных файлах (*.h) В ОСНОВНОМ находятся объявления функций (имя функции и список параметров без тела функции). В файлах исходного кода В ОСНОВНОМ расположены определения функций (имя/список параметров и тело функции). Для того, чтобы использовать функции из твоей библиотеки в другом проекте, нужно В ЧИСЛЕ ПРОЧЕГО подключить твои заголовочные файлы в другой проект.

сомнительна необходимость что-то здесь отвечать

Ну да. Плюсую. Калл какой то.

Я плакалъ.
-L
-I

ТС не обижайся ни на кого.
Они тебе все

ЗАВИДУЮТ

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

От дедов-пердедов, которые сидят на древних пентиумах и парятся по поводу скорости компиляции.

Всегда при импорте просто вырезается текст из файла с кодом и вставляется на место #include. Или нет?

Всё так. суй всю библиотеку в один файл и includь его и вперёд. Даже такие знаменитые библиотеки, как sqlite лежат в одном файле: sqlite3.c.

Учиться самым основам чего-то совершенно нового – действительно непередаваемое удовольствие. Даже если это сарказм, ты прав.

Учиться самым основам чего-то совершенно нового – действительно непередаваемое удовольствие. Даже если это сарказм, ты прав.

Шутка

Я завидую, чо.

Если вдруг кто уши развесил и поверил, процитирую на всякий «The SQLite library consists of 102 files of C code». Возможность их амальгамировать в 2021 нужна примерно никому.

LTO для себя открой, дед-пердед

Проще встраивать в свой проект.

Проще чем что, чем -lsqlite3? Doubt.

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

В двух словах тебе нужен нормальный учебник по Си, а не только Керниган-Ритчи. Для какой платформы ты пишешь?

https://sqlite.org/althttpd/doc/trunk/althttpd.md

#include сделать проще, чем какие-то непонятные флаги учить.

существуют не только single-header библиотеки

думается по сути .h от .c файлы ничем не отличаются — любой скорми компилятору и он сделает что следует. Тут же просто соглашение, что первые содержат как минимум объявлений, как максимум сразу с реализацией.

И .h файлы по соглашению не должны содержать

 int main ()

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

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

В современных ОС виртуальное пространство программы может расширяться подобным образом.

Думается, в любой вменяемой литературе ясно и однозначно объясняется что из этого и для чего предназначено.

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

sqlite3.c - это амальгамированный файл для удобства скачивания и встраивания в приложение, сами исходники sqlite разумеется лежат в разных файлах.

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

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

Это всё, что вы хотели знать о библиотеках.

А? Что?

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

Помедленнее, пожалуйста. Я записываю.

Про менеджер памяти не знаю, не буду комментировать.

Но вот насчет параметров через стек – это ты загнул. Это только в винде ее WinAPI до сих пор вызывается так. Это называется stdcall.

И только WinAPI. Для внутренних функций, внутри бинарника даже винда уже перешла на регистровый, пусть и свой собственный стандарт – ms-fastcall. Первые 4 параметра передаются через регистры, остальные через стек.

В линуксе, бсд и макоси есть System V Application Binary Interface. Первые 6 параметров передаются через регистры, остальное через стек. И по-моему, так собирается в никсах все, в том числе и Shared Objects (so).

Исключение в современных никсах, по-моему, только интерфейс системных вызовов. В современном ядре там добавили структурку (struct), которая имеет поля, схожие с названиями регистров (pt_regs). Эта структурка передается все-таки через стек. Там есть слово asmlinkage для этого.

Других исключений я не помню.