MikhailEdoshin

Насколько я понимаю, суффиксы @8 и т. п. добавляются к функциям, для которых указан формат вызовов stdcall и означают размер стека. Это зависит от компилятора вообще-то, но и MSVC, и mingw тут совпадают. Если такую функцию предполагается экспортировать из получившейся DLL, дополнительно создается алиас без суффикса, что мы, собственно, тут и видим:

DllCanUnloadNow = @ILT+450(_DllCanUnloadNow@0)

Мне не нравится различие в DllMain — @8 и @12, правильное, судя по спецификации, @12 — передаются три указателя, но тут один куда-то девается. У вас DllMain точно три параметра принимает?

Новая функция SQLite? В смысле, новая функция, которой можно пользоваться в SQL-выражениях? Если так, то там ведь стандартный интерфейс добавления таких функций во время выполнения — зачем изменять саму SQLite?

Pelles C? С++ нет. Windows. Скриншоты.

Написать библиотеку на С с нужной функцией. Потребление памяти возрастет на размер получившейся библиотеки, но я так понимаю, вам нужна, главным образом, скорость. Как вариант — написать на Cython, в данном случае будет почти тоже самое, что и руками на С.

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

Текст и картинка разные вещи. Текст печатается с разрешением принтера (например, 300 dpi — это достаточно низкое разрешение, недостатки будут заметны невооруженным глазом), а картинка — с линеатурой растра (например, 75 lpi — это, напротив, довольно высокая линеатура). Если печатать текст картинкой, он всегда будет дробиться растром, тут ничего не сделать. Копайте все-таки в сторону измерения длины строки как-то.

Вы имеете в виду calling conventions, т. е. stdcall, fastcall и т. п.? Собственно в этом и разница, одни очищают, другие нет. Если вы не пишете собственную libffi, то остается только следить за правильностью объявлений.

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

#ifdef USE_A
...
#endif

.
В исходниках соответственно сначала определяется, что использовать, а затем включается .h-файл:

#define USE_A
#define USE_B

#include "project.h"

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

Насчет XCode не скажу, но скажу, как вручную. Раз это C++, то, скорее всего, надо будет ее перекомпилировать (собственно, они и сами это пишут). В Mac OS X при линковке запоминается полный путь к библиотеке (который может включать специальные переменные @executable_path, @loader_path и еще один хитрый ключ) — соответственно при линковке библиотеки нужно будет правильно выставить этот путь в зависимости от того, где собираетесь держать библиотеку. Когда библиотека готова, для линковки ее к проекту можно указать ее непосредственно ее в командной строке, или же через ключи -L(директория) -l(краткое имя библиотеки); или, если она собирается framework'ом, то ключами -F(директория) -framework(имя фреймворка).

Нужно сделать .lib-файл самостоятельно. Посмотрите, нет ли в комплекте с .dll файла .def. Если есть, то можно получить .lib с помощью

lib.exe /DEF:mylib.def mylib.dll

или

lib.exe /DEF:mylib.def /OUT:mylibname.lib mylib.dll

если нужно другое имя. В таком виде (dll + def), распространяется, например, sqlite3.

Если .def-файла нет, посмотрите, какие у вас символы в библиотеке через

dumpbin /exports mylib.dll

Если это практически те же имена, что и в заголовочном файле, значит, библиотека экспортирует символы в стиле С; это хорошо. Перечислите все нужные имена в командной строке:

lib.exe /EXPORT:mylib_func1 /EXPORT:mylib_func2 mylib.dll

(.def-файл, по сути, делает то же самое.) Единственное, я сейчас не помню, но к именам может спереди добавлятся подчеркивание. Я не уверен, нужно ли указывать имена с подчеркиванием или без.

Если там имен нет, значит, они отрезаны, функции можно определить только по порядковому номеру. Если вокруг них всякая муть, это C++, а муть означает закодированный тип параметров. Это все не очень хорошо, конечно, потому что соответствие номеров функциям не определить (разве что экспериментально), а стандарта на кодирование нет. Но технически создать .lib-файл можно, у опции /EXPORT полная сигнатура такая:

/EXPORT: entryname[= internalname][,@ ordinal[, NONAME]][, DATA]

То есть можно и переименовать функцию, и по номеру ее выбрать, и данные экспортировать. Но это на крайний случай.

lib.exe обычно не в PATH, из обычной командной строки не найдется, но в группе инструментов Visual Studio должно быть что-то вроде «Command Prompt» — он открывает консоль и добавляет нужные пути в PATH, так что инструменты командной строки становятся доступными.

Ссылки: dumpbin, lib.

То есть вы собираете poppler как статическую библиотеку, затем линкуете ваш проект, статическую Qt и получившийся статический poppler, и при запуске он у вас вылетает, требуя какую-то DLL?

Если так, то посмотрите через dumpbin /imports (справка), какие DLL импортирует ваш собранный проект. Если там есть какая-то DLL, посмотрите лог сборки — там, соответственно, тоже должна быть статическая обертка для этой DLL. Или, если там ничего нет, может быть в исходниках poppler'а — MS позволяет указать библиотеку на уровне исходника с помощью pragma comment (справка). В любом случае эта статическая обертка должна быть где-то в окрестностях, иначе бы проект не собрался. Вам нужно ее отключить в настройках проекта — явно, или, если она прописана в исходниках, то через /NODEFAULTLIB:<name>.

Не знаю насчет Qt, но для C есть библиотеки, правда, только под GPL: xpdf или MuPDF.

Обычно советуют Кернигана и Ричи. Хотя сам, признаюсь, их не читал :(

Я использую второй вариант если у меня есть имя переменной (при объявлении) и первый вариант, если имени нет (например, в функции).

char*
foo(int*);

char*
foo(
     int *bar)
{
    char *baz1,
         *baz2;
   ...
}