[moved] Carbide C++ IDE problem by compiling C-DLL

[paipeng]

hello,

i have a problem by compiling a DLL in C.

I have a C function. in mmp:

OPTION		CW -lang c++

after compiling this DLL, there is a DLL file created in the directory:
Epoc32\release\GCCE\UREL
e.g.: test.dll & test.map

But there is no dso file created in:
\Epoc32\release\armv5\lib
g.g.: test{000a00000}.dso & test.dso


So, i tried again with command line:

abld build gcc urel

these two dso files created automatically.


Is this already a known issue for Carbide?
Or the setting of Carbide is not correct?


Thanks

Pai

[paipeng]

and because there is no reply for this issue from Carbide C++ developers/nokia,

I advice the people, who has the same problem, to compile the C DLL files with command line at first, after freezing, then can use Carbide C++ continue.

e.g.:
bldmake bldfiles
abld build gcce urel
abld freeze
(abld clean)
(Don't forget compiling this DLL again with Carbide C++!!)


BTW: I am using OpenC for this issue.


Regards

Pai

[ltomuta]

Dear Pai,

it seems that thos post remaind unnoticed, sorry about that. Please note that Carbide.c++ has a bug report channel that can be accesse throug the "Report new bug ..." option from the Help menu. That is the best way for you to report any problem to Carbide.c++'s developers.

And if all you want is a confirmation of your finding, or some help in solving your problem, then do use the "Carbide.c++ IDE and plug-ins" forum.

[paipeng]

Thank you, ltomuta, for your notice on my problem.


I just sent a bug-report through Carbide C++, althrough it is not easy also (Need an Account at first).


Regards

Pai

[Sorcery-ltd]

I didn't understand this bug report - I've compiled DLLs that were written in C. They compile just fine for GCCE in Carbide.c++ when you switch the active build configuration...

I don't use:

OPTION CW -lang c++

but note that this option is only for emulator builds. If there is some problem with building the C files as C code then you need to hack the SDK (GCCE.mk has the relevant setting hard-coded) which is definitely not recommended.

Mark

[paipeng]

Hi Mark,


thanks for your info. It is just what I want to know, if the problem is caused by myself along or anyone got the same problem also.


It should be something wrong with the compile-output/compile-configuration... I have tried with some tests. And now DLL-Compile works again with Carbide IDE.

I still don't know, what exactly causes the problem, also maybe nobody is interesting on it.


Regards

Pai

[paipeng]

To all:

updated:

I solved this problem by inserting EXPORTUNFROZEN in DLL's mmp file.

these two files are created by Carbide:
\Epoc32\release\armv5\lib
g.g.: test{000a00000}.dso & test.dso


Regards

Pai

[Sorcery-ltd]

Hi,

Yes, for target builds you need to define which are the exported functions and in what order - you should have had some warning about a missing .def file and that the lib wouldn't be created when you attempted the build.

For 3rd FP2 onwards you should be able to use the STDDLL target type which will export all functions by name - which is useful if you don't have the necessary EXPORT_C and IMPORT_C macros in legacy/ported code.

Mark