Наши проекты:
Журнал · Discuz!ML · Wiki · DRKB · Помощь проекту |
||
ПРАВИЛА | FAQ | Помощь | Поиск | Участники | Календарь | Избранное | RSS |
[18.216.186.164] |
|
Страницы: (2) [1] 2 все ( Перейти к последнему сообщению ) |
Сообщ.
#1
,
|
|
|
Есть проект на C++, Win32 dll, в нём никаких зависимостей, всё на самом низком уровне, из инклюдов только #include <windows.h>.
В проекте было много асм-вставок, решил переписать всё на C++, чтобы портировать на x64. Использовались MMX инструкции, поэтому добавил #include <intrin.h>, проблем не возникло. В другом месте копировал память с помощью "rep movsd", переписал циклом - стало заметно медленнее, тогда решил задействовать memcpy(), для этого подключаю #include <cstring>. Использую VS 2017 Community. Такая функция: extern "C" __declspec(dllexport) void __stdcall PAINT(int* src, int* dst, int w, int h, int ws, int wd) { w = w * 4; for (int y = 0; y < h; y++) { memcpy(dst, src, w); dst += wd; src += ws; } } при компиляции даёт ошибку: Цитата Ошибка LNK2019 ссылка на неразрешенный внешний символ _memcpy в функции _PAINT@24 Этот же код в VS 2008 Express без проблем компилируется и корректно работает. Куда копать? |
Сообщ.
#2
,
|
|
|
Вроде #include <memory> помогало.
|
Сообщ.
#3
,
|
|
|
Цитата Славян @ Вроде #include <memory> помогало. Тот же эффект, что и от #include <cstring>. Функция memcpy() видится, даже компилируется, она не линкуется. |
Сообщ.
#4
,
|
|
|
Действительно странно, у меня эти 6 строчек успешно в DLL собираются:
#include <memory> extern "C" __declspec(dllexport) void __stdcall PAINT(int* src, int* dst, int w, int h, int ws, int wd) { memcpy( (void*)1, (void*)2, 3); } Добавлено А мож надо всё же прямо привести int* к void*, а то (помнится) сейчас и на такое компиляторы могут ругаться!.. ??? Добавлено Э-э... или правильно сказать "компоновщики"? Короче, кто-то из них. |
Сообщ.
#5
,
|
|
|
Там ещё .def файл присоединён, чтобы избавиться в именах от окончаний типа "@24", экспортируется функция с именем PAINT.
А линкер пишет об ошибке в _PAINT@24, вот тут у меня и сомнения возникают, может баг студии, ведь в 2008 это работает. А без memcpy() работает и в 2017. Цитата Славян @ и на такое компиляторы могут ругаться! Ругается линкер. |
Сообщ.
#6
,
|
|
|
А! Нет, это не баг, там какая-то своя хитрая схема. Надо вспоминать. Всё там норм!
|
Сообщ.
#7
,
|
|
|
Я эту проблему решил заменой memcpy() на соответствующий интринсик, но разобраться всё равно интересно.
|
Сообщ.
#8
,
|
|
|
Добавил test.def в проект, всё успешно прошло:
EXPORTS PAINT @1 |
Сообщ.
#9
,
|
|
|
Славян
В моём случае это так: EXPORTS PAINT |
Сообщ.
#10
,
|
|
|
Да нет никакой разницы. Ну убрал указание на вызов по ординалу 1, всё равно успешно собралось. Надо что-то в настройках вашего проекта колдовать.
Добавлено Впрочем, может оттого, что у меня VS 2017 Professional?, - не очень я в этих кашах разбираюсь. |
Сообщ.
#11
,
|
|
|
Mikle, а каталоги для VS - пути файлов библиотек, исполнимых файлов и хеадеров
указаны правильно ? в том числе VC, SDK, а также всех других, которые необходимы. Цитата Mikle @ Славян В моём случае это так: EXPORTS PAINT Если ты используешь def - файл в dll проекте, то это: extern "C" __declspec(dllexport) можно не использовать. Это, как-бы, определено самим фактом использования имён в def-файле. |
Сообщ.
#12
,
|
|
|
Цитата Славян @ Там нет, случайно, какого-нибудь /NODEFAULTLIB? Ибо у меня синтетический пример прекрасно собрался:Наверное, всё же трабла в настройках проекта. // .DLL #include <cstring> extern "C" __declspec(dllexport) void __stdcall f(void *dst, const void *src, size_t size) { memcpy(&dst, &src, size); } // .EXE int a; int b; extern "C" __declspec(dllimport) void __stdcall f(void *dst, const void *src, size_t size); int main() { f(&a, &b, sizeof(a)); } |
Сообщ.
#13
,
|
|
|
Цитата Qraizer @ нет, случайно, какого-нибудь /NODEFAULTLIB? Нет. |
Сообщ.
#14
,
|
|
|
Вопрос решился прилинковкой vcruntime.lib.
Да, теперь появилась зависимость от рантайма, да, его вроде можно статически прилинковать, да, он несовместим с XP (а я пока не хочу терять совместимость), да, в студии, вроде как, можно ещё что-то прилинковать для совместимости. Но интринсик с этим справляется без всех этих проблем. Источник проблемы установлен, вопрос решён. |
Сообщ.
#15
,
|
|
|
Цитата Mikle @ да, он несовместим с XP (а я пока не хочу терять совместимость), Тогда не понятно, зачем отказываться от VS 2008 ? Цитата Этот же код в VS 2008 Express без проблем компилируется и корректно работает |