R>и что это настолько сложно? R>после таких ваших вопросов R>ваш експириенс понизился до уровня джуна после несколько месячных курсов по программированию
я 8 лет говнокодил и частично утерял навыки
но теперь все будет иначе
Здравствуйте, удусекшл, Вы писали:
ЕМ>>Где там границы функций и модулей? У>А они точно нужны? Без них никак?
Чтобы тупо прикрутить DLL внутрь EXE — не нужны, только зачем это может быть нужно?
У>Библиотека содержит объектники. Может содержать и один. Объектник содержит секции. Если ты не указал в настройках помещать каждую функцию в отдельную секцию, то код каждой единицы трансляции будет лежать в одной секции, которая при линковке будет подсосана целиком.
Так делаются только самые тупые библиотеки, единственной задачей которых является столь же тупое прикрепление к конечному бинарнику. Правильная библиотека делается так, чтобы извлекать оттуда только необходимые зависимости, и ничего лишнего.
У>Вопрос был как слинковать DLL статически
Вопрос был, как переделать DLL в статическую библиотеку. Поскольку ТС традиционно сверхлаконичен, я предположил, что ему нужна классическая библиотека (контейнер для функций и модулей), а не формально линкуемый неразборный кусок.
Здравствуйте, sergey2b, Вы писали:
S>статическую библиотеку S>или из файлов .o собранных cygwin файлы lib коректно линкуемые к проекту на VS
Оттуда будут потроха видны наружу, с ODR могут быть проблемы.
Особенно если несколько кломпиляторов и рантаймов в деле...
А зачем тебе это всё? Можно как-то по-простому хаккернуть? Ну, там, выгружать dll из ресурсов куда-нибудь во временный, автоудаляемый файл и грузить оттуда?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Erop, Вы писали:
E>А зачем тебе это всё? Можно как-то по-простому хаккернуть? Ну, там, выгружать dll из ресурсов куда-нибудь во временный, автоудаляемый файл и грузить оттуда?
Здравствуйте, flаt, Вы писали:
F>Чем линковка "одним куском" хуже?
Тем, что библиотека используется в роли единичного объектного файла.
F>И что такое "полноценная библиотека"?
"Библиотека" — это "хранилище книг". Множества книг, из которых можно выбрать нужное подмножество, а не одного гигантского фолианта из сотен тысяч страниц.
F>Вот есть у нас заголовочный файл с API, функции которого можно вызывать из своего кода. В случае статической библиотеки они будут публичными в obj-файлах, в случае динамической — в её экспорте. В обоих случаях мы используем то, что нам предоставили.
Если API состоит, грубо говоря, из сотни функций, а программа использует двадцать, то при линковке с грамотно сделанной статической библиотекой (ну, или при использовании современных расширений вроде packaged functions), будут прилинкованы только эти два десятка. DLL будет содержать всю сотню, но ее одновременно могут использовать несколько приложений. А при линковке "одним куском" к каждому приложению будет прицеплена вся сотня, и восемь десятков будет там лежать мертвым, бесполезным грузом.
Здравствуйте, IID, Вы писали:
IID>Автоудаляемые файлы (DELETE_ON_CLOSE) не маппятся.
Ну пусть в своп копирует, флажок жен был вроде?
Но, на самом деле конкретно DELETE_ON_CLOSE неудобно. Лучше в список на удаление после перезагрузки добавть, например.
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Евгений Музыченко, Вы писали:
S>>статическую библиотеку
ЕМ>Нельзя. DLL — это, как и EXE, конечный исполняемый файл, в нем нет имен, модулей, функций и прочих принадлежностей OBJ/LIB.
Ну как же нет, когда всё, что нужно, там есть?
Теоретически можно разобрать ручками dll, покурить формат obj файлов MSVS и собрать всё в OBJ. Но таких инструментов готовых я не видел
Не хочу вас расстраивать, но во первых, ffMPEG под LGPL, а во вторых, avcodec.dll статически слинкована с avutil.dll и swresample.dll, т.е. она в рантайме без этих dll работать не будет. Поэтому, вам и их придется научится собирать.
Здравствуйте, SaZ, Вы писали:
S>>но попросили сделать статическую линковку с проектом на vs2015 SaZ>Вас LGPL лицензия не смущает для статической линковки?
Может они готовы предоставлять свои исходники, тогда какие проблемы?
V>Не хочу вас расстраивать, но во первых, ffMPEG под LGPL, а во вторых, avcodec.dll статически слинкована с avutil.dll и swresample.dll, т.е. она в рантайме без этих dll работать не будет. Поэтому, вам и их придется научится собирать.
с лицензие пусть разбираеться начальство, я их предупрежу
avcodec.a avutil.a swresample.a и оставшиеся 3-4 библиотеки
mingw могут быть слинкованы статически вместе
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Здравствуйте, sergey2b, Вы писали:
S>>статическую библиотеку
ЕМ>Нельзя. DLL — это, как и EXE, конечный исполняемый файл, в нем нет имен, модулей, функций и прочих принадлежностей OBJ/LIB.
именна функций и думюю их смещение нам известны (в конце концов я собираю эти dll и у меня есть def файлы)
dll на чистом Си те проблем с именнами не будет
rtl не смещиваеться тк он свой у dll и программы
Здравствуйте, Videoman, Вы писали:
V>Здравствуйте, sergey2b, Вы писали:
S>>avcodec.a avutil.a swresample.a и оставшиеся 3-4 библиотеки S>>mingw могут быть слинкованы статически вместе
V>Это не оно?
Нет это делает lib для простого доступа к функциям all
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Нельзя. DLL — это, как и EXE, конечный исполняемый файл, в нем нет имен, модулей, функций и прочих принадлежностей OBJ/LIB.
Имена экспортируемых и импортируемых символов в нем есть. Релокации ему вроде как не нужны. Так что теоретически можно. А практически вряд ли имеет смысл.
Подобные тулзы могут сделать из DLL только "статически линкуемую" DLL, не более того. То есть, линковаться-то она будет, но только одним куском (максимум — секциями, но это уже ненадежно). Полноценной библиотеки из нее не сделать, если нет PDB.
Здравствуйте, Евгений Музыченко, Вы писали:
У>>Ну как же нет, когда всё, что нужно, там есть?
ЕМ>Где там границы функций и модулей?
А они точно нужны? Без них никак?
У>>Теоретически можно разобрать ручками dll, покурить формат obj файлов MSVS и собрать всё в OBJ.
ЕМ>И получится линкуемый бинарник, но никак не библиотека.
Библиотека содержит объектники. Может содержать и один. Объектник содержит секции. Если ты не указал в настройках помещать каждую функцию в отдельную секцию, то код каждой единицы трансляции будет лежать в одной секции, которая при линковке будет подсосана целиком.
Вопрос был как слинковать DLL статически, а назовешь ты это библиотекой или линкуемым бинарником — какая разница-то?
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>>>Где там границы функций и модулей? У>>А они точно нужны? Без них никак?
ЕМ>Чтобы тупо прикрутить DLL внутрь EXE — не нужны, только зачем это может быть нужно?
Чтобы тупо прикрутить DLL к EXE
ЕМ>Так делаются только самые тупые библиотеки, единственной задачей которых является столь же тупое прикрепление к конечному бинарнику. Правильная библиотека делается так, чтобы извлекать оттуда только необходимые зависимости, и ничего лишнего.
Тупая не тупая, но всё равно — библиотека
У>>Вопрос был как слинковать DLL статически
ЕМ>Вопрос был, как переделать DLL в статическую библиотеку.
Ок, согласен
ЕМ>Поскольку ТС традиционно сверхлаконичен, я предположил, что ему нужна классическая библиотека (контейнер для функций и модулей), а не формально линкуемый неразборный кусок.
Здравствуйте, удусекшл, Вы писали:
ЕМ>>Чтобы тупо прикрутить DLL внутрь EXE — не нужны, только зачем это может быть нужно?
У>Чтобы тупо прикрутить DLL к EXE
Ну вот я и не понял, для чего это могло бы понадобиться.
У>Тупая не тупая, но всё равно — библиотека
Как обычная библиотека с книгами, где на просьбу выдать один экземпляр предлагают забрать весь стеллаж.
Честно, не понял проблемы. Чем линковка "одним куском" хуже? И что такое "полноценная библиотека"?
Вот есть у нас заголовочный файл с API, функции которого можно вызывать из своего кода. В случае статической библиотеки они будут публичными в obj-файлах, в случае динамической — в её экспорте. В обоих случаях мы используем то, что нам предоставили.
Здравствуйте, удусекшл, Вы писали:
ЕМ>>Где там границы функций и модулей? У>А они точно нужны? Без них никак?
Точно нужны, но и этого недостаточно. Линкер может объединить в dll хвосты нескольких процедур/функций в один. Код процедуры может не составлять непрерывный кусок секции и пр.
ЕМ>Если API состоит, грубо говоря, из сотни функций, а программа использует двадцать, то при линковке с грамотно сделанной статической библиотекой (ну, или при использовании современных расширений вроде packaged functions), будут прилинкованы только эти два десятка. DLL будет содержать всю сотню, но ее одновременно могут использовать несколько приложений. А при линковке "одним куском" к каждому приложению будет прицеплена вся сотня, и восемь десятков будет там лежать мертвым, бесполезным грузом.
Это всё верно, вот только отвечал я на другое (черезчур категоричное) заявление:
Нельзя. DLL — это, как и EXE, конечный исполняемый файл, в нем нет имен, модулей, функций и прочих принадлежностей OBJ/LIB.
Здравствуйте, sergey2b, Вы писали:
S>статическую библиотеку S>или из файлов .o собранных cygwin файлы lib коректно линкуемые к проекту на VS
Главный вопрос, а зачем? Какая цель преследуется? Когда генерируется dll с ней можно флагом компилятора указать сгенерировать библиотеку линковки.
Еще тело dll можно упаковать как данные, которые грузит в память статическая либа. Только какой в этом смысл?
Только цель какая? Может тот кто поставил задание хочет другое? Например чтобы CRT в dll линковался статически, а не использовался динамически? Так это опять опция сборки dll.
Поскольку ТС традиционно сверхлаконичен, я предположил, что ему нужна классическая библиотека (контейнер для функций и модулей), а не формально линкуемый неразборный кусок. 
