DLL hell with Carbide.c++ 1.1 (Developer)

[dschwabe]

I have been observing this for quite some time now:
I'm importing a MMP file for a DLL that compiled, linked and runs fine when
doing the same thing under Carbide 1.0.
It does build in 1.1 as well, but when launching an exe that relies on the dll later on, will cause a Signal (access denied) and the process cannot continue because the loading of the DLL seems to fail. Closer investigation shows, that
the dll that gets created in the workspace directory and the one that is created in the emulator udeb output directory differ in size. Something seems
to get modified while copying to the epoc32 directory and this seems to render the dll unusable. The dll in the workspace though works fine. What is going on here?
The linker does print out a warning which might be a hint:
mwldsym2.exe|Usage|Warning
>Option overrides the effect of 'm|main'; only one of '-m[ain], -noentry' should be specified
>while parsing option '-noentry'
I have no idea where the '-noentry' comes from, but it doesn't sound good.
It's not apparent where this get's set. I could not find it anywhere in the project settings.

Any ideas?

You can easily reproduce this problem by using the project wizard to create a dll project and an exe project that uses the dll.

[dschwabe]

One more thing:
It seems that C.c++ 1.1 treats my static dll project as a polymorphic dll project. That would explain the -noentry (and -noimplib) options to the mwldsym2 linker.
I forgot to mention that the build process also fails to copy the import lib over to the epoc32 output directory.

[slibrenti]

Hello Nokia people,
I have the same problem with Carbide 1.1 Express and S60_2nd_FP2_CW.
If you want to reproduce the problem, you can use the example in Symbian\8.0a\S60_2nd_FP2_CW\Examples\basics\staticdll.
The only warning received during compilation is:
"Severity Description Resource In Folder Location Creation Time Id
1 Option overrides the effect of 'm|main'; only one of '-m[ain], -noentry' should be specified while parsing option '-noentry' createstaticdll line 0 30 dicembre 2006 15.16.29 256".
In the path MyWorkSpace\createstaticdll\S60 2.6 Emulator Debug
I can find the following files:
createstaticdll.dll 86.168 byte
CreateStaticDLL.lib 3.358 byte

while, with my big disapoint, in path
Symbian\8.0a\S60_2nd_FP2_CW\Epoc32\release\winscw\udeb
I can find the following files:
createstaticdll.dll 84.360 byte
CreateStaticDLL.lib 2.314 byte.

The result is that this version (placed in the correct place by the compilation process) is not working; an access violation happends before my code starts execution.

But if I copy files from MyWorkSpace\createstaticdll\S60 2.6 Emulator Debug over files in Symbian\8.0a\S60_2nd_FP2_CW\Epoc32\release\winscw\udeb
everithing works.

At the moment I'll return to previous version Carbide 1.0, but I think that a macro problem like this shouldn't be difficoult to solve.
Hoping to receive a quick replay,
happy new year at everybody (Nokia & Symbian included!).

PS: who does insert the -noentry linker option? How can I remove it?

[scarex80]

I Test with StaticDLL Example.

I'm using Carbide.c++ 1.1 pro with S60 SDK 3rd Edition MR.

CreateStaticDLL.dll 97,580 bytes (workspace and symbian library udeb directory)
CreateStaticDLL.lib 3,990 bytes (workspace) and 2,314 bytes (symbian udeb library)

CreateStaticDLL.dll 1,289 bytes (symbian gcce library)

Now I've some problem with exe registration in debugger so I can't say if it work or no.

[uniras]

I am having a similar problem but not sure why.
The dll files that get put in C:\Symbian\8.1a\S60_2nd_FP3\Epoc32\release\winscw\udeb
always seem to be slightly smaller than the ones produced in
\S60 2.8 Emulator Debug

Likewise the lib files seem to be different.
If i try to debug the application straight after a build it fails on application startup, BUT it does load the symbols for the dll.
If i copy the dll and lib from \S60 2.8 Emulator Debug to C:\Symbian\8.1a\S60_2nd_FP3\Epoc32\release\winscw\udeb and try to debug the application loads and it seems to work fine except it now does not load the symbols and i therefore cannot break into the dll.

I have had a quick look at the build output but could not see anything obviously building 2 versions of the dll/lib so i am not sure why i get 2 versions.

Comparing them in a hex editor reveals LOTS of differences so its not simply had something added/removed.

I assume i have something wrong in the build/depoly process but not sure where.

Any help greatly appreciated

Thanks

[paipeng]

I want to create DLL with Carbide c++ 1.1, but DLL is not usable by exe.
I don't know, if I must wait for update of Carbide?