[00:01:26] <OCTAGRAM> под MIPS
[00:01:44] <OCTAGRAM> под роутер, правда, сходу не получилось скомпилированное запустить
[00:02:28] <OCTAGRAM> было бы неплохо, чтоб кто-нибудь как-нибудь разобрался с роутерами MIPS
[00:02:45] <ada_ru> (I_vlxy_I) думаю у с++ проблем не будет :-)
[00:02:50] <ada_ru> (Максим) из-за libc? А статически не получается собрать?
[00:03:53] <ada_ru> (Максим) я себе взял на arm роутер. но руки не доходят попробовать
[00:08:03] <OCTAGRAM> да, я думаю, libc
[00:08:41] <OCTAGRAM> TP-Link всякие много, у кого, на них Ревизоры и CIAWiFi делают
[00:10:02] <ada_ru> (Максим) у меня стоял OpenWRT на TPLink, там какая-то усеченная libc, не помню уже какая
[00:12:46] <ada_ru> (I_vlxy_I) а ада юзает либц? зачем?
[00:13:42] <ada_ru> (Максим) помойму адский рантайм на основе posix, а posix же на libc
[00:14:10] <OCTAGRAM> uclibc
[00:14:31] <ada_ru> (I_vlxy_I) libc - это стандартная либа Си
[00:14:41] <ada_ru> (I_vlxy_I) а позикс это все же не совсем оно, хотя и пересекаются
[00:14:53] <OCTAGRAM> в позиксе он как kernel32.dll в венде
[00:15:36] <ada_ru> (I_vlxy_I) кажется аде достаточно было бы сискалов. собственно и на сях так можно писать
[00:15:53] <ada_ru> (I_vlxy_I) зачем аде все эти сишные fopen, malloc, free и проч?
[00:16:18] <ada_ru> (I_vlxy_I) printf там - тоже оттуда
[00:16:40] <ada_ru> (Максим) нет особо желающих струячить рантайм на системных вызовах линуха
[00:16:47] <ada_ru> (I_vlxy_I) а вот всякого open, read там как раз нет - это сискалы уже.
[00:17:27] <ada_ru> (I_vlxy_I) всякий разный float.h, Аде, кажется, тоже не нужен
[00:18:07] <ada_ru> (I_vlxy_I) сискалы, кстати, это не линух, это позикс
[00:19:03] <ada_ru> (Максим) syscall он же как отдельная инструкция (типа int 0xxx)?
[00:19:47] <ada_ru> (Максим) а posix это вызов с convention => c
[00:20:29] <ada_ru> (I_vlxy_I) кажется сейчас это не через прерывания делают
[00:21:59] <ada_ru> (I_vlxy_I) "For example, the x86 instruction set contains the instructions SYSCALL/SYSRET and SYSENTER/SYSEXIT (these two mechanisms were independently created by AMD and Intel, respectively, but in essence they do the same thing). These are "fast" control transfer instructions that are designed to quickly transfer control to the kernel for a system call without the overhead of an interrupt.[8] Linux 2.5 began using this on the x86, where available; formerly it used the INT instruction, where the system call number was placed in the EAX register before interrupt 0x80 was executed."
[00:22:03] <ada_ru> (I_vlxy_I) всякое такое
[00:22:15] <ada_ru> (I_vlxy_I) хм. надо глянуть как это делается
[00:23:04] <OCTAGRAM> статический libc гипотетически так и будет делать
[00:23:35] <ada_ru> (Максим) ну вот, получается где-то должена быть обвертка сишным open вокруг syscall-а линукса
[00:25:33] <ada_ru> (I_vlxy_I) эмм.. зачем?
[00:25:53] <ada_ru> (I_vlxy_I) там же в регистр положил номер сискала, аргументы сложил куда надо, и можно звать!
[00:28:50] <ada_ru> (I_vlxy_I) вот их сколько! http://man7.org/linux/man-pages/dir_section_2.html
[00:32:20] <ada_ru> (I_vlxy_I) http://man7.org/linux/man-pages/man2/syscall.2.html
[00:32:25] <OCTAGRAM> …и повторить для каждого отдельного iOS, Solaris, BSD
[00:32:31] <ada_ru> (I_vlxy_I) то что доктор прописал!
[00:32:35] <OCTAGRAM> vsego-to nihego
[00:33:41] <ada_ru> (Максим) затем что posix это C, syscall это не Си. gnat рантайм на posix
[00:34:14] <ada_ru> (I_vlxy_I) а разве libc содержит весь позикс? вроде бы нужны еще либы
[00:35:23] <ada_ru> (I_vlxy_I) а если у gnat рантайм на позиксе, наверно тяжко ему в виндах то?
[00:36:18] <ada_ru> (Максим) думаю, что весь. под винду пришлось какие-то свои костыли делать, наверное
[00:43:37] <ada_ru> (Максим) меня больше интересует вопрос, что надо сделать чтобы gnat runtime с uclibc собрать.
[00:44:08] <ada_ru> (I_vlxy_I) а просто собрать - не вариант? ему вообще не все равно?
[00:44:21] <ada_ru> (I_vlxy_I) может LD_PRELOAD попробовать?
[00:44:59] <ada_ru> (I_vlxy_I) он же ищет функции по имени, а имена и сигнатуры функций должны совпадать у libc и ulibc
[00:47:15] <ada_ru> (Максим) я не пробовал. Вот Иван говорит, сходу не взлетает, значит кроме имен функций еще что-то надо
[00:47:49] <ada_ru> (I_vlxy_I) оно просто может libc.so ищет-ищет и не находит. не может подрузить либу с таким именем
[00:47:51] <ada_ru> (I_vlxy_I) и обламывается
[00:48:21] <ada_ru> (Максим) симлинку подсунуть?
[00:48:40] <ada_ru> (I_vlxy_I) ну, например
[00:50:42] <OCTAGRAM> Максим: Ну я вот, допустим, если беру ванильный GNAT GPL 2017, то там libc в комплекте тупо нет. Из коробки это нерабочий, не самодостаточный компилятор. Нужно установить какой-ннибудь libc-dev, чтоб заработал.
[00:51:04] <ada_ru> (I_vlxy_I) НИНУЖИН!
[00:51:41] <OCTAGRAM> так я полагаю, что там libc.a с импортами подключается только в самый последний момент, значит, если в этот момент подсунуть другой libc, то и соберётся с другим
[00:52:53] <OCTAGRAM> со статическим или с импортами к другому libc
[00:56:04] <ada_ru> (Максим) надо пробовать. где бы его (другой libc) взять? где-то в дебрях OpenWRT?
[01:00:31] <OCTAGRAM> uclibc-dev, я полагаю
[01:01:17] <OCTAGRAM> я так понимаю, там система не как в Делфи, а как в Си, то есть, вместе с so генерится a с импортами
[01:01:52] <OCTAGRAM> найти a с импортами от uclibc, и чтоб подключался именно он
[01:26:02] <ada_ru> (I_vlxy_I) lib + dll - это вроде бы чисто виндовая тема же. нет?
[01:26:13] <ada_ru> (I_vlxy_I) в линухах обычно .a не нужен для .so
[01:31:56] <ada_ru> (I_vlxy_I) вообще просто посмотрите какие либы ваш эльф хочет
[01:31:59] <ada_ru> (I_vlxy_I) уже собранный
[01:44:29] <OCTAGRAM> не чисто виндовая, а чисто сишная
[01:44:56] <ada_ru> (I_vlxy_I) у меня C и .a не требуется. что я делаю не так?
[01:45:12] <OCTAGRAM> в делфи-то просто пишешь function ABC …; external 'abc.dll' name 'abc';
[01:45:52] <OCTAGRAM> GCC умеет щупать dll и so, но это как будто бы хакерство
[01:46:51] <OCTAGRAM> в динамических библиотеках манглинг не такой, как в библиотеках импорта, так что вроде бы a нужны
[01:47:06] <ada_ru> (I_vlxy_I) у C нет же манглинга
[01:47:32] <ada_ru> (I_vlxy_I) там вся сигнатура функции - это ее имя. и всё
[01:53:36] <ada_ru> (I_vlxy_I) ну вот сейчас в маке собрал so и прилинковался к ней (динамически)
[01:53:42] <ada_ru> (I_vlxy_I) без .a
[01:53:49] <ada_ru> (I_vlxy_I) что я делаю не так?
[01:54:05] <OCTAGRAM> http://www.willus.com/mingw/yongweiwu_stdcall.html
[01:54:25] <ada_ru> (I_vlxy_I) ой, не надо про винду плиз
[01:54:41] <OCTAGRAM> а в Линуксе не так, что ли?
[01:54:46] <ada_ru> (I_vlxy_I) не так
[01:54:58] <ada_ru> (I_vlxy_I) и в маке не так
[01:55:31] <OCTAGRAM> а если в so имя какое-нибудь с вопросами, то как из C её подключить и вызвать?
[01:55:36] <ada_ru> (I_vlxy_I) да, блин. везде не так. в любой стандартной операционке не так.
[01:56:03] <ada_ru> (I_vlxy_I) эмм.. а какие проблемы?
[01:56:12] <OCTAGRAM> да, на Маке пустые dylib и надо ещё дать пощупать все зависимости зависимостей, это просто копец
[01:56:27] <OCTAGRAM> как в Си написать имя функции с вопросами?
[01:56:27] <ada_ru> (I_vlxy_I) ну, то есть идентификаторы в Си и имена функций в Си всегда без вопросов
[01:56:44] <ada_ru> (I_vlxy_I) но Си вообще ничего про библиотеки не знает - на уровне языка такой сущности НЕТ
[01:56:58] <ada_ru> (I_vlxy_I) поэтому тут все городят что хотят - это системные штуки
[01:57:08] <ada_ru> (I_vlxy_I) в soшках имена функций могут быть любые
[01:57:11] <ada_ru> (I_vlxy_I) так то
[01:57:17] <ada_ru> (I_vlxy_I) например у плюсов есть манглинг
[01:57:49] <ada_ru> (I_vlxy_I) (потому как там в сигнатуру функции входит не только имя оной функции, но и типы аргументов)
[01:58:11] <ada_ru> (I_vlxy_I) и .a не нужен. вообще. зачем?
[01:58:34] <ada_ru> (I_vlxy_I) компилятор сам может сделать манглинг и деманглинг.
[01:58:44] <OCTAGRAM> правильно, придумываем валидное имя, манглим его под внутренний манглинг выбранного компилятора, делаем библиотеку импорта, в котором внутренне замангленное имя связывается с символом в динамической библиотеке с именем из вопросов, и Си, ничего не знающий про библиотеки, может вызывать такую функцию
[01:58:54] <ada_ru> (I_vlxy_I) тебе не нужно знать точное текстовое представление имени функции в so
[01:59:27] <OCTAGRAM> а без такого механизма символы с вопросами не подключить
[02:00:07] <ada_ru> (I_vlxy_I) скажи, откуда они там возьмутся?
[02:00:27] <OCTAGRAM> например, потому что это библиотека C++, с которой работают из Си
[02:00:33] <ada_ru> (I_vlxy_I) и нафига мне тут .a вообще? вот сколько живу, столько не пользуюсь .a в *nix для использования so
[02:01:01] <ada_ru> (I_vlxy_I) если это либа С++ и ты с ней хочешь работать из сей, то у тебя будут проблемы поважнее чем манглинг :-D
[02:01:04] <OCTAGRAM> это только потому что компоновщик даёт срезать путь
[02:01:27] <OCTAGRAM> эти проблемы решаемы
[02:01:41] <ada_ru> (I_vlxy_I) обычно для сей делают обертку. специальный сишный интерфейс для либы. благо это элементарно делается
[02:01:50] <OCTAGRAM> хорошо, другой пример
[02:01:53] <ada_ru> (I_vlxy_I) чтобы нигде руками не трогать имена лежащие в so
[02:03:18] <OCTAGRAM> стоит в системе супер-пупер навороченная libc.so, и в ней символ GLIBC_VERSION дофига высоко задранный, а надо, чтоб работало у тех, где версия поменьше, поэтому нужна цель с другой версией символа
[02:03:49] <OCTAGRAM> чтоб эта цель ещё и код настоящий содержала, необходимости нет, так что a для импорта тут подойдёт
[02:04:16] <ada_ru> (I_vlxy_I) что такое "цель"?
[02:04:23] <ada_ru> (I_vlxy_I) ну сделай LD_PRELOAD, чо
[02:04:28] <OCTAGRAM> мишень для компоновщика
[02:04:57] <OCTAGRAM> не, LD_PRELOAD — это уже при запуске, а надо при компоновке
[02:04:58] <ada_ru> (I_vlxy_I) в конце концов, dlopen/dlsym тебе в руки
[02:06:39] <OCTAGRAM> я считаю, что щупать реальные, особенно системные на машине разработчика библиотеки с настоящим кодом — вредно, а чтоб объект щупания компоновщиком содержал реальный код, нет необходимости, поэтому для разработки a, а для запуска — so
[02:07:05] <ada_ru> (I_vlxy_I) вообще, .a это тупо архив объектников. если тебе нужен вдруг .a, то он тебе не даст ничего из того чего тебе не сможет дать .o
[02:09:02] <ada_ru> (I_vlxy_I) а .o это лишь скомпилированная единица компиляции Си
[02:09:14] <OCTAGRAM> для импорта сойдёт
[02:09:54] <OCTAGRAM> для импорта не содержится реальный код
[02:10:57] <ada_ru> (I_vlxy_I) я не очень понимаю что тебе нужно, но я рад что ты нашел для себя решение :-)

но для си и с++ в реальной жизни для использования so не нужны .a В маздае же да, дурная система dll+lib
[02:12:37] <OCTAGRAM> я в GNAT как-то не увидел конструкцию function ABC… external 'abc.dll' name 'ABC'; и в gcc — тоже
[02:12:55] <OCTAGRAM> а только такой системой это можно заменить
[02:13:34] <OCTAGRAM> если external 'abc.dll' name 'ABC' нельзя написать в коде, приходится «писать» в библиотеку импорта
[02:14:12] <ada_ru> (I_vlxy_I) дааа.. вот в сях хорошо!
вот код программы которая подгружает и юзает .so:

#include <stdio.h>

int foo();

int main() {
printf("%d\n", foo());
return 0;
}
[02:14:13] <OCTAGRAM> если хочется без библиотек импорта, значит, external 'abc.dll' name 'ABC' должен переместиться в исходники
[02:14:42] <OCTAGRAM> в __attribute или куда угодно
[02:15:56] <ada_ru> (I_vlxy_I) и без всяких библиотек статических :-D
[02:18:01] <OCTAGRAM> а символ foo возьми да и найдись сразу в двух so
[02:18:31] <OCTAGRAM> надо же такому случиться
[02:18:35] <ada_ru> (I_vlxy_I) санитайзер по голове стукнет скорее всего :-)
[02:18:58] <OCTAGRAM> импорты-то под контролем
[02:19:19] <OCTAGRAM> а реальные so, ну мало ли что в них может твориться
[02:19:20] <ada_ru> (I_vlxy_I) а если без этого, то кто первый встал того и тапки. это нормуль!
[02:20:07] <OCTAGRAM> разработчик должен, качая импорты, определять, что и откуда пойдёт
[02:20:26] <OCTAGRAM> а вот so у разработчика с реальным кодом — это лыжи, которые сами куда-то везут
[02:20:33] <OCTAGRAM> может, туда, а, может, не туда
[02:23:35] <ada_ru> (I_vlxy_I) опиши схему как ты это хочешь контроллировать
[02:23:41] <ada_ru> (I_vlxy_I) через какие механизмы
[02:27:48] <OCTAGRAM> либо external+name в сорцах (лучше), либо импорты (хуже)
[02:28:02] <OCTAGRAM> почему в GNAT хуже, чем в Делфи, для меня — загадка
[02:28:14] <ada_ru> (I_vlxy_I) что такое импорты? что такое external? технически это что?
[02:28:31] <ada_ru> (I_vlxy_I) что такое делфи в линуксе - я вообще не знаю :-)
[02:33:25] <OCTAGRAM> есть делфи в линуксе, и kylix был, и сейчас новый 10.2
[02:34:14] <OCTAGRAM> const
 ole32    = 'ole32.dll';
function IsEqualGUID(const guid1, guid2: TGUID): Boolean; stdcall; external ole32 name 'IsEqualGUID';
[02:34:48] <OCTAGRAM> здесь вся информация в одном месте, откуда, по какому имени и с каким соглашением брать
[02:34:49] <ada_ru> (I_vlxy_I) ы? что такое const ole32 =
[02:35:44] <OCTAGRAM> в Делфи константы могут быть строками, и эти константы могут быть в external
[02:36:01] <OCTAGRAM> function IsEqualIID(const guid1, guid2: TGUID): Boolean; stdcall; external ole32 name 'IsEqualGUID';
[02:36:11] <OCTAGRAM> вот пример, когда имена не совпадают
[02:36:14] <ada_ru> (I_vlxy_I) в общем, ты хочешь прямо в коде указывать либу откуда грузить и имя символа который оттуда грузить?
[02:36:22] <OCTAGRAM> конечно!
[02:36:51] <ada_ru> (I_vlxy_I) жуть какая непортабельная :-)
[02:36:52] <OCTAGRAM> много ещё таких несовпадений получилось, когда ReadConsole на самом деле в DLL ReadConsoleW
[02:37:32] <OCTAGRAM> можно с точностью до принятых в системе декораций имени библиотеки
[02:37:58] <OCTAGRAM> ак в -l аргументе компоновщика
[02:38:28] <OCTAGRAM> библиотеки импортов — это усложнение по сравнению с делфями
[02:39:07] <OCTAGRAM> на тот случай, если что-то не заладилось с тем, чтобы просто взять и сделать хотя бы не хуже, чем в делфи
[02:42:22] <ada_ru> (I_vlxy_I) что такое библиотека импортов?
[02:43:09] <OCTAGRAM> набор связей между внутренне замангленными именами и указателей на so, откуда их на самом деле брать и под каким именем оттуда на самом деле брать
[02:43:46] <ada_ru> (I_vlxy_I) предположим манглинга нет. вообще
[02:44:33] <ada_ru> (I_vlxy_I) просто я гружу две so: a.so, b.so. в первой две функции: a(), b(). во второй тоже две: b(), c()
[02:44:36] <OCTAGRAM> то есть, взяли external+name отпилили от привязок и поскидали в одну кучу, а чтоб кучу потом можно было разобрать, в месте распила ещё придумали внутренне замангленное имя, и им соединили то, что в коде, с тем, что в библиотеке импорта
[02:44:55] <ada_ru> (I_vlxy_I) я знаю как это сделать через dlopen, но не очень понимаю как ты это хочешь сделать
[02:45:11] <OCTAGRAM> function IsEqualIID(const guid1, guid2: TGUID): Boolean; stdcall; external ole32 name 'IsEqualGUID'; — здесь всё едино, распиливать на две половины не нужно
[02:45:30] <ada_ru> (I_vlxy_I) в проге я использую естественно a(), b() (из a.so), с()
[02:45:39] <OCTAGRAM> а, хм, ну в макосе-то сработает, там двухуровневая адресация
[02:45:51] <OCTAGRAM> в Линуксе, кажется, действительно будут проблемы
[02:46:26] <ada_ru> (I_vlxy_I) а как макось поймет, что я хочу дернуть именно b() из a.so, а не b() из b.so?
[02:46:39] <OCTAGRAM> а там в бинарнике указание
[02:46:53] <OCTAGRAM> как в Windows таблица импортов
[02:46:54] <ada_ru> (I_vlxy_I) каким образом там это указание появится?
[02:46:58] <OCTAGRAM> откуда и что
[02:47:15] <OCTAGRAM> двухуровневая
[02:47:29] <ada_ru> (I_vlxy_I) вот моя программа (целиком):
void a();
void b();
void c();

void main(){a(); b(); c();}
[02:48:39] <ada_ru> (I_vlxy_I) я вот прямо сейчас собирал прогу в макоси - никаких таблиц импортов не потребовалось. gcc отлично собрал без них.
[02:49:01] <ada_ru> (I_vlxy_I) но то была зависимость от одной so без таких перекрытий. вопрос - как разрулить вот такое вот?
[02:49:29] <OCTAGRAM> компоновщик пощупает файлы, которые дали ему пощупать, и если там конфликта нет, то создаст бинарный файл с двухуровневой таблицей импорта, а этот файл уже будет работать вне зависимости от того, есть ли конфликты в реальных библиотеках
[02:50:30] <ada_ru> (I_vlxy_I) предлагаешь моки делать? то есть пустые сошки где просто символы перечислены?
[02:50:39] <OCTAGRAM> да
[02:50:47] <OCTAGRAM> а лучше — чтоб как в Делфи
[02:50:53] <OCTAGRAM> в одном окне
[02:51:10] <OCTAGRAM> declspec или attribute
[02:51:15] <ada_ru> (I_vlxy_I) не знаю что такое "окно" :-)
[02:51:25] <OCTAGRAM> как говорят
[02:51:34] <OCTAGRAM> в одном окне решить все вопросы
[02:51:41] <ada_ru> (I_vlxy_I) в принципе такие моки сделать можно, да. вроде бы довольно просто в сях.
[02:51:46] <OCTAGRAM> не пилить на две части
[02:52:06] <OCTAGRAM> в макосе strip есть для создания SDK
[02:52:14] <OCTAGRAM> им SDK и делаются
[02:52:31] <OCTAGRAM> или не strip, но что-то есть для потрошения
[02:53:49] <ada_ru> (I_vlxy_I) но вообще, если такие сложности возникают, то народ советует не морочить голову и тупо юзать dlopen(), dlsym() and dlclose()
[02:54:02] <ada_ru> (I_vlxy_I) берем полностью все в свои руки, рулим как хотим
[20:27:59] <ada_ru> (borysik)