Проблемы линковки с OBJ файлом

[vada]

Никогда такого не делал, а вот понадобилось. Взяли меня на работе за детородные органы, грят: "Засчисчай программу, ибо, тырят."
Стандартными средствами HASP конверта не получается. Программа становится неработоспособной. Обращались к поставщикам защиты.
Они там целый год что-то ковырялись. Сделали что контрольный пример защищается и работает, ну, типа, и все.
Я на время забил на, думал забудут меня, ан нет. Вспомнили. Так что пытаюсь зайти с другого борта. Есть там в поставке API с примером под дельфи.
Вот и ковыряюсь. Пытаюсь прицепить obj файл к проекту. В obj куча функций,которые описываю в разделе interface
Ну как-то так:

Код: Выделить всё

const
  HASP_Obj = 'hasp_windows_x64_delphixe_БЛА_БЛА_БЛА.obj';

function hasp_login(feature_id: hasp_feature_t;  vendor_code: hasp_vendor_code_t;  var handle: hasp_handle_t): hasp_status_t;  stdcall; external HASP_Obj Name 'hasp_login';
function hasp_logout(handle: hasp_handle_t): hasp_status_t;  stdcall; external HASP_Obj Name 'hasp_logout';
..............................

Там их много.

В объектном файле еще уйма системных вызовов к kernel32.dll. Практически все эти вызовы есть в модулях Windows и SysUtils. Модули в подключены в uses. Но вот только линкер не желает их цеплять и ругается что у него 125 неразрешенных ссылок. Пробовал описывать эти вызовы вот так:

Код: Выделить всё

function GetComputerNameA(lpBuffer:LPSTR; nSize:LPDWORD):WINBOOL; external 'kernel32' name 'GetComputerNameA';
function MulDiv(nNumber:longint; nNumerator:longint; nDenominator:longint):longint; external 'kernel32' name 'MulDiv';
procedure GetSystemTime(lpSystemTime:LPSYSTEMTIME); external 'kernel32' name 'GetSystemTime';
procedure GetSystemTimeAsFileTime(lpSystemTimeAsFileTime:LPFILETIME); external 'kernel32' name 'GetSystemTimeAsFileTime';
function SetSystemTime(lpSystemTime:LPSYSTEMTIME):WINBOOL; external 'kernel32' name 'SetSystemTime';
procedure GetLocalTime(lpSystemTime:LPSYSTEMTIME); external 'kernel32' name 'GetLocalTime';
function SetLocalTime(lpSystemTime:LPSYSTEMTIME):WINBOOL; external 'kernel32' name 'SetLocalTime';
procedure GetSystemInfo(lpSystemInfo:LPSYSTEM_INFO); external 'kernel32' name 'GetSystemInfo';
procedure GetNativeSystemInfo(lpSystemInfo:LPSYSTEM_INFO); external 'kernel32' name 'GetNativeSystemInfo';
.......................

Компилятор все без проблем хавает, а вот линковщик шкварчит и ругается. Говорит что я дубина, и как было 125 неразрешенных ссылок, так и осталось.

Уже неделю ковыряюсь читаю в инете все подряд. Не помогает.

Что я делаю не так? Ткните носом дурака. Куда копать?

[Дож]

Попробуйте к kernel32 функциям добавить обёртки вот таким образом:

Код: Выделить всё

function _GetComputerNameA(lpBuffer:LPSTR; nSize:LPDWORD):WINBOOL; stdcall; public name 'GetComputerNameA';
begin
  Result := GetComputerNameA(lpBuffer, nSize);
end;

[olegy123]

kernel32.dll вызывается во всех win приложениях, если линковщик не может сшить obj то скорее разрядность разная..

[Снег Север]

Может поможет Object file converter - https://www.agner.org/optimize/#objconv ?

[vada]

olegy123

kernel32.dll вызывается во всех win приложениях, если линковщик не может сшить obj то скорее разрядность разная..

Первое что пришло на ум это разность разрядности.
- Obj файл 64 разряда;
- Приложение 64 разряда;
- kernel32.dll 32 разряда.
Но! В приложенном сентенелом примере все это перемешивается в одну кучу. Может быть делфи умеет так.
Попробую подергать недостающие 125 ссылок из 64-разрядного kerell

Снег Север
Спасибо! Интересная утилитка.

Добавлено спустя 3 часа 4 минуты 30 секунд:

Попробую подергать недостающие 125 ссылок из 64-разрядного kerell

Пофиг веники. Линковщик попрежнему не видит 125 ссылок.

Добавлено спустя 19 минут 6 секунд:

Код: Выделить всё

interface
  function GetWindowsDirectoryA(lpBuffer: LPSTR; uSize: UINT): UINT; stdcall;
............................

implementation
  function GetWindowsDirectoryA; external kernelBase name 'GetProcessTimes';
......................

Линковщик говорит:

Код: Выделить всё

Error: Undefined symbol: GetWindowsDirectoryA

[Лекс Айрин]

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

[Vadim]

Компилятор все без проблем хавает, а вот линковщик шкварчит и ругается.

Вы линковку делаете отдельно от компиляции?

[vada]

Лекс Айрин
Вы правильно помните. Файл такой есть. В нем прописаны функции которые и нужны для работы. Но! Кроме того, в объектном файле есть куча системных вызовов к kernel и еще паре DLL-елок. Вот на эту кучу линковщик и ругается. Все эти функции есть в модулях Windows и SysUtils. Они подключены через uses. Это не помогает.
Ктому же при компиляции получаю предупреждение что Windows не используется. Я пробовал специально сделать вызовы к функциям Windows и SysUtils. Ну чтобы прилинковались модули. Модкли линкуются, но это тоже не помогло. Линковщик ругается на неразрешенные ссылки из объектного файла.
Я напрягся и все эти 125 ссылок описал. Теже фаберже, только с боку.

Vadim

Вы линковку делаете отдельно от компиляции?

И так и так пробовал.
"Запуск"/"Быстрая компиляция" это без линковки. Ошибок нет.
"Запуск"/"Собрать" получаю ругательства линковщика.

[Vadim]

vada
А Вы пробовали вместо " external 'kernel32' " писать " external 'kernel32.dll' "?

[vada]

Vadim
Повсякому пробовал.

[Лекс Айрин]

vada, так может надо тупо удалить эти функции из файла для линковщика? Чисто в виде предположения, есть шанс, что ты не можешь их добавить, так как они уже подключены. Если это реально системные функции. Хотя, конечно, линковщик должен понимать подобные дублирования правильно.

[скалогрыз]

Что я делаю не так? Ткните носом дурака. Куда копать?

проблема в том, что ты пытаешься использовать делфийские .obj файлы с FPC, а это не прокатит.
Внутренний FPC компоновщик (как и внешний "ln") работает только с gnu форматом ( .o -файлы, ну или .а).

варианты действий:
1) найти .o файлы в gnu формате) - обратись к поставщику же. Они смогут собрать его на FPC.
2) использовать .dll-ку, вместо статической линковки
3) (аналогичен №2) - написать свою dll-ку в delphi, которая будет использовать .obj файлы, а потом подключить .dll-ку в проект на fpc
4) использовать что-нить другое. Например OnGuard

[Sergei I. Gorelkin]

Дело не в формате. Факт сообщения о 125 неразрешенных ссылках говорит о том, что компилятор успешно прочитал объектный файл и определил наличие там этих ссылок...
Дело в том, что в FPC исправили "баг", связанный с возможностью импортировать функцию из неправильной dll.
Раньше, если объявить

Код: Выделить всё

procedure p1; external 'lib1.dll' name 'p';
procedure p2; external 'lib2.dll' name 'p';

то в таблице имен создавалось одно имя 'p', а какой из двух dll оно было сопоставлено в таблице импорта - тут как повезет.

Теперь же для объявлений функций из dll создаются декорированные имена, видные только пасклевскому коду. Из-за этого прилинковать внешний код с неразрешенными символами стало по сути невозможно. Ну разве что пытаться линковать библиотеки импорта из SDK...

[olegy123]

Трудности перевода..
по линуху знаю если начать линковать статично библиотеку в c++ то легко можно перебрать пол системы, "undefined reference to" выловить в самых экзотических местах.
Последний пример - openssl, тама решили ревизию провести после неоднократных дыр, да взяли все переломали.. во история будет если нужно старый проект скомпилировать на новую систему..

таковы особенности системы. это тянется еще со времен битв форматов и компиляторов.

насколько я знаю fpc не совсем delphi. Либо нужно ключиками поиграться чтобы obj сел.. либо проще взять чисто сишную (только не c++!!!) gnu библиотеку, fpc с GNU живет дружно.
Visual C+ Lib неравно GNU C++, даже Visual C+ не равно с Visual C#

[Лекс Айрин]

olegy123, у ТС винда. Причем, он четко знает какой файл содержит экспортируемые в прогу функции.