Вопрос по CBuilder-у и Дельфи

← →
SPeller © (2003-09-07 07:10) [0]

У меня такая проблема. Есть у меня скомпилированный в BCB obj-файл. В нём есть функция, которая объявлена так:

HANDLE PASCAL RAROpenArchive(struct RAROpenArchiveData *r)

Линковка obj-файла к Дельфийскому проекту проходит нормально, объявляю в своём модуле эту функцию так:

function RAROpenArchive( ArchiveData: PRAROpenArchiveData ): THandle; stdcall; external;

Но Дельфи выдаёт ошибку Unsatisfied forward or external declaration: "RAROpenArchive".
Подскажите, что я делаю не так, где камни? Может, дело в сишном объявлении функции? Может ещё что-то?

← →
SPeller © (2003-09-07 11:23) [1]

Нашёл ответ наполовину. Решил попробовать с таким кодом, для отладки и для начала:

----- some.cpp: -------
extern "C" { int __export __cdecl MYFUNCTION(int N) { return N * 5; } } // end of extern "C"
-----------------------

Объявил эту функцию так:

function MYFUNCTION( S: Integer ): Integer; cdecl; external;

И опять нифига. Мучался-мучался - так и ничего не получилось. Скачал пример, посмотрел, сделал так же - всё-равно не работает. И вдруг я заметил, что в примере не С++, а С! Сменив расширение моего файла на .с, убрав директиву extern "C" и перекомпилив его, он прекрасно подлинковался и прекрасно заработал! Компилировал такой строкой:
C:\Programs\Borland\BCC55\Bin\bcc32.exe -u- some.c
Кто-нибудь знает, как можно скомпилировать код на С++ чтобы Дельфи поняла его? Мне надо откопилить исходники рар-распаковщика, написанного на С++. Можно ведь, наверное, это сделать?
Использую компилятор BCB 5.5.1

← →
DrPass © (2003-09-07 14:37) [2]

На самом деле ларчик открывается просто: в С++ возможность перегрузки функций решена радикально: компилятор их переименовывает, т.е. добавляет к имени в obj-файле мишуру вида $trwg - в зависимости от параметров функции. Отключи опцию mangle names

← →
SPeller © (2003-09-07 17:59) [3]

Эта опция точно так называется? У меня от всего си-билдера один компилятор. Чё-то я в нём ничего подобного не нашёл. Посмотрел в опциях bcc32 и make - ничего нет. Может, не там смотрю? И ещё в книжке одной вычитал, что якобы Дельфи с этим справляется просто - её компилятор просто отбрасывает служебную информацию (@ и всё что после $). Ещё там рекомендация не использовать перегружаемые функции там, где они будут вызываться из паскалевских модулей.

← →
SPeller © (2003-09-07 18:37) [4]

У меня ведь никаких перегрузок функций нет...

← →
SPeller © (2003-09-08 20:00) [5]

Никто не знает?

← →
clickmaker © (2003-09-08 20:21) [6]

а линкуешь так {$L FILE.OBJ} ?

← →
SPeller © (2003-09-09 11:10) [7]

> а линкуешь так {$L FILE.OBJ} ?

ну да, по другому-то никак.

← →
Игорь Шевченко © (2003-09-09 11:26) [8]

А почему бы тебе не объявить имя функции в Delphi, так как сишный компилятор ее делает после extern "C" ? Может, подчеркивание добавить в начало имени ? (Как делает компилятор, можно по obj-файлу посмотреть)

← →
SPeller © (2003-09-09 11:30) [9]

Подчеркивание я убрал ключем -u-.

← →
SPeller © (2003-09-09 11:57) [10]

Посмотрел obj-файл - без extern "C" она выглядит так:
@MYFUNCTION$qi
с extern "C" так:
MYFUNCTION

Но Дельфи всё-равно не хочет распознавать её. Может, в сишном объявлении что-то можно сделать?

← →
SPeller © (2003-09-09 12:01) [11]

Попробовал убрать ключ -u- и разрешить подчеркивание и в Дельфийском описании добавил это подчеркивание. Ничего не изменилось, всё так же Unsatisfied forward or external declaration: "_MYFUNCTION"

← →
SPeller © (2003-09-09 12:07) [12]

А кто-нибудь может вкратце объяснить для чего нужны подчеркивания перед export, cdecl, да ещё и неоднократные? Export без подчеркивания требует предварительное объявление какое-то.

← →
Игорь Шевченко © (2003-09-09 13:34) [13]

Q:
I"ve been doing some tests myself because I need to statically link C++ code
in Delphi. Unfortunately I found that Delphi indeed cannot link to symbols
in OBJ files that were generated from C++ code. The reason being that the
Delphi linker does not recognize the COMDEF records in the OBJ file. I do
not think that behaviour is correct as the OMF specs do mention that
external symbols should be searched for in both PUBDEF and COMDEF records.

A:
"Rudy Velthuis (TeamB)" <rvelthuis@gmx.de> wrote in message
news:8vuk9v$f7r15@bornews.inprise.com...
> Wade wrote in <3A22C821.11CAD9D3@n2.net>...
>
> > I"m trying to link an object file into my unit and am having trouble. I
> > created the object file in C++Builder 4 and am trying to link to it in
> > Delphi 4. The procedure is declared in C++ builder as follows(I tried a
> > few different ways):
> >
> > extern "C" _stdcall _export void DrawT2Outline(HDC hDC,
>
> Define it in a C, not in a C++ file (if possible, of course):
>
> extern __stdcall void DrawT2Outline(HDC hDC, etc...
>
> The compiled .c file will be linked correctly. I couldn"t make a compiled
> .cpp link correctly.>
> If you must use C++ files, you"ll have to use a DLL, I"m afraid.
> --
> Rudy Velthuis (TeamB) http://delphi-jedi.org

Увы :(

← →
PVOzerski © (2003-09-09 13:38) [14]

А вот во FreePascal проблема с name mangling решается элементарно:
function SomeFunc(x,y:longint);stdcall;
external name "_SomeFunc@8";

Странно, что в Delphi до этого не додумались.

← →
Игорь Шевченко © (2003-09-09 13:47) [15]

PVOzerski © (09.09.03 13:38)

Привет! Да не в манглинге здесь дело, увы :) Можно объявить и extern "C", запретив манглинг, проблемы это не решает, к сожалению :)

← →
PVOzerski © (2003-09-09 14:01) [16]

А туда обратно конвертнуть OMF->COFF->OMF не поможет?

← →
Игорь Шевченко © (2003-09-09 14:26) [17]

PVOzerski © (09.09.03 14:01)

Я доверяю Руди :)

И потом, и он, и автор вопроса сказали, что с C у них все получается, так что проблема решаемая несколько обходным путем - например, написанием интерфейса на C или DLL

Я пытался переименовать все исходники unrar в .с, но компилятор билдера сругнулся на то, что какаято фигня может быть использована только в С++. Всем спасибо за участие. Ещё попробую выкарабкаться, если у кого есть желание помочь - буду благодарен.

Ну надо мне :-)))

Фигня:

Fatal F1003 C:\Programs\Borland\BCC55\Include\stdcomp.h 5: Error directive: Must use C++ for STDCOMP.H

Это стандартный инклуд сибилдера. Может, его можно заменить на другой?

Виноваты вот эти строчки:

#ifndef __cplusplus
#error Must use C++ for STDCOMP.H
#endif

Посматриваю исходники unrar. Мне кажется, что их можно откомпилить на С, потому что там есть такая строчка в заголовочном файле экспортируемых функций:

#ifdef __cplusplus
extern "C" {
#endif

HANDLE PASCAL RAROpenArchive(struct RAROpenArchiveData *ArchiveData);
HANDLE PASCAL RAROpenArchiveEx(struct RAROpenArchiveDataEx *ArchiveData);
int PASCAL RARCloseArchive(HANDLE hArcData);
int PASCAL RARReadHeader(HANDLE hArcData,struct RARHeaderData *HeaderData);
int PASCAL RARReadHeaderEx(HANDLE hArcData,struct RARHeaderDataEx *HeaderData);
int PASCAL RARProcessFile(HANDLE hArcData,int Operation,char *DestPath,char *DestName);
void PASCAL RARSetCallback(HANDLE hArcData,UNRARCALLBACK Callback,LONG UserData);
void PASCAL RARSetChangeVolProc(HANDLE hArcData,CHANGEVOLPROC ChangeVolProc);
void PASCAL RARSetProcessDataProc(HANDLE hArcData,PROCESSDATAPROC ProcessDataProc);
void PASCAL RARSetPassword(HANDLE hArcData,char *Password);
int PASCAL RARGetDllVersion();

#ifdef __cplusplus
}
#endif

Можно откомпилить. А ты убери #include "stdcomp.h" :))))

Ага :) Я уже посмотрел :) Нигде в исходниках такой строки нет! :-)) По всей видимости на этот инклуд ссылаются другие стандартные инклуды.

Вопрос по CBuilder-у и Дельфи Найти похожие ветки