C / C++ / MFC

26-Jun-06 5:02

Hi,

Does anyone have experience on this issue. I tried to call a vc++ 6 FMC dll from a regular vc++6 dll. I got a link error "afxcw.lib(dllmodul.obj) : error LNK2005: _DllMain@12 already defined in usersec32.obj", where usersec32.obj is the calling object. It seems to me _DllMain is defined in both dll.

I am wondering whether it is possible to call a dll from a dll. If possible, what do I have missed?

Very appreciate if I get assistance. Thanks in advance.

hli

hli

Sarath C26-Jun-06 5:06

26-Jun-06 5:06

Are using that header file or other dll for compilation? or loading using "GetProcAddress" ???

SaRath.

"It is your attitude, not your aptitude, that determines your altitude - Zig Ziglar."
My Blog | Understanding State Pattern in C++

hli126-Jun-06 5:19

26-Jun-06 5:19

I inserted a line #include "secondDll.h" in the first dll. It caused the link error. This worked for calling a dll from .exe file.

#include <stdio.h>
#include <cmath>

#include "secondDll.h"

hli

hli126-Jun-06 5:23

26-Jun-06 5:23

Sorry, my code is

#include <stdio.h>
#include <cmath>

#include "dbInsert\DBArea.h"

hli

hli126-Jun-06 5:30

26-Jun-06 5:30

The previous posts do not display the #include values. They should be: #include <stdio.h> and #include <cmath>

hli

Sarath C26-Jun-06 5:24

26-Jun-06 5:24

that is the problem. when it is linking, with other lib file, it is seeing there are two dll main functions(its own and others).

Try using loadlibray and GetProcAddress it will resolve your problem.

SaRath.

"It is your attitude, not your aptitude, that determines your altitude - Zig Ziglar."
My Blog | Understanding State Pattern in C++

hli126-Jun-06 5:35

26-Jun-06 5:35

Many thanks. May I have a brief sample code for that.

hli

Zac Howland26-Jun-06 5:55

Zac Howland

26-Jun-06 5:55

Or just include the header files for the classes you intend to use instead of the main header for the DLL.

You don't have to use LoadLibrary/GetProcAddress to call methods from one DLL in another. You just have to make sure that both DLLs are built with the same threading library and you properly include header files and link with the libs.

As a side note, make sure you don't create cross-dependencies between DLLs when doing this ... they are NOT fun to work with.

If you decide to become a software engineer, you are signing up to have a 1/2" piece of silicon tell you exactly how stupid you really are for 8 hours a day, 5 days a week

Zac

hli126-Jun-06 7:42

26-Jun-06 7:42

Hi,

Thank both of you first. I am wondering that in my case I have to use LoadLibrary/GetProcAddress. I am attaching the example below which caused the link error. Please let me know if I can use Zac's suggestion instead of LoadLibrary/GetProcAddress approach.

A head file in the second dll project is named as DBArea.h. There are several classes in the second dll that are defined in dataWork.h. So dataWork.h is included in the DBArea.h file. The first dll is designed to use member functions "rowInsert" and "getConnection" in class DBArea.

#include "dataWork.h"
#if !defined(AFX_DBAREA_H__93C879DF_44A0_4D6E_87E4_87EA36BE815A__INCLUDED_)
#define AFX_DBAREA_H__93C879DF_44A0_4D6E_87E4_87EA36BE815A__INCLUDED_

#if _MSC_VER >> 1000
#pragma once
#endif // _MSC_VER >> 1000

class DBArea
{

public:
__declspec(dllexport) int rowInsert(char *SQLStr);
__declspec(dllexport) int GetConnection(char *connectionStr);
__declspec(dllexport) DBArea();
__declspec(dllexport) virtual ~DBArea();

protected:
CADORecordset m_pRs;
CADODatabase m_pDb;

};

#endif // !defined(AFX_DBAREA_H__93C879DF_44A0_4D6E_87E4_87EA36BE815A__INCLUDED_)

hli

Zac Howland26-Jun-06 9:02

Zac Howland

26-Jun-06 9:02

For starters, when you include this file in the DLL that will be calling into it, the __declspec(dllexport) should be changed to __declspec(dllimport). Typically, this is done by defining a macro that checks to see if the file is being compiled as a DLL or as an application; however, since both will be DLLs, you may need to define another macro that doesn't depend on that to check to see which is should use.

Second, you should __declspec the class, not individual methods. You will have a hard time calling these methods because they are exported, but they are part of a class that isn't exported.

Just FYI, you almost never "have" to use LoadLibrary/GetProcAddress. The only time you have to do so is when your requirements call for late-binding DLLs, and even then, there are some other options.

If you decide to become a software engineer, you are signing up to have a 1/2" piece of silicon tell you exactly how stupid you really are for 8 hours a day, 5 days a week

Zac

hli127-Jun-06 3:28

27-Jun-06 3:28

Thank you Zac,

However, I failed to change dllexport to dllimport with a warning: "warning C4273: 'GetConnection' : inconsistent dll linkage. dllexport assumed". So, I changed it back. Did I miss something?

I simplified my case by exporting one function only. Because I am a new VC++ programmer and don't know how to create a macro, I hope you could give me a further suggestion. This project is so import to me. I would very much appreciate if I could get assistance here.

Below is a brief detail. Many thanks.

-----------------------------------

Error message:

nafxcwd.lib(dllmodul.obj) : error LNK2005: _DllMain@12 already defined in firstDll.obj
nafxcwd.lib(dllmodul.obj) : warning LNK4006: _DllMain@12 already defined in firstDll.obj; second definition ignored
Creating library Debug/firstDll.lib and object Debug/firstDll.exp

In the second dll (made by MFC), I declared an export function in the header file, DBArea.h.

__declspec(dllexport) int GetConnection(char *connectionStr);

In the first dll (made by stardard C++), I defined FIRSTDLL_EXPORTS in the firstDll.cpp

#include "stdafx.h"
#define FIRSTDLL_EXPORTS /////////////
#include "firstDll.h" ////////////////

I created a class, callSecondDll, and a member function callDll(), which was accessed from firstDll class. The header file DBArea.h (in second dll) was included in the file callSecondDll.cpp

#include "stdafx.h"
#include "callSecondDll.h"
#include "DBArea.h" //////////////////

...............

int callSecondDll::callDll()
{
................
int n = GetConnection(myString);
return 0;
}

hli

Zac Howland27-Jun-06 4:24

Zac Howland

27-Jun-06 4:24

Here is a simplified case of some old code I use to have to work with:

Macro defined for both Dll's

#ifdef __IMPORT_LIBRARY__<br />
#define EXTENDED_MODULE __declspec(dllimport)<br />
#else<br />
#define EXTENDED_MODULE __declspec(dllexport)<br />
#endif // __IMPORT_LIBRARY__

In Dll 1:

// dll1.h<br />
EXTENDED_MODULE void myfunction();

In the project settings for DLL2, add __IMPORT_LIBRARY__ to the preprocesser definitions. (NOTE: DO NOT use EXTENDED_MODULE for defining your methods in DLL2 otherwise nothing will be exported from DLL2 -- either create another macro name with the same style build, or use MFC's AFX_EXT_CLASS macro). Included the dll1.h header file where you need to call myFunction(), and add the lib file that is created for the dll to Dll2's link settings.

If you decide to become a software engineer, you are signing up to have a 1/2" piece of silicon tell you exactly how stupid you really are for 8 hours a day, 5 days a week

Zac

hli127-Jun-06 7:43

27-Jun-06 7:43

Let me try it. I will let you know if I need further assistance. Thank you very much.

hli

Debugger issues

capricious_00126-Jun-06 4:39

26-Jun-06 4:39

Hey guys,

When I'm running my debugger, I am getting a strange problem that keeps occuring. If I click run, the debugger follow throughs the whole source code and gives me an access violation of 0xC0000005. If I do a run to cursor, then I am forced by the debugger to provide the location of CRT0.C. The program runs fine without the debugger, just doesnt output the correct results. Would anyone know the reason for that?

Thanks

Robbie

David Crow26-Jun-06 4:42

David Crow

26-Jun-06 4:42

capricious_001 wrote:
If I click run...

Is that F5 or Ctrl+F5?

capricious_001 wrote:
The program runs fine...just doesnt output the correct results.

How can a program run fine but not output the correct results?

"The largest fire starts but with the smallest spark." - David Crow

"Judge not by the eye but by the heart." - Native American Proverb

capricious_00126-Jun-06 4:59

26-Jun-06 4:59

DavidCrow wrote:

Is that F5 or Ctrl+F5?

With F5 I get an access violation. CTRL+F5 produces no run-time error and the program is executed.

DavidCrow wrote:
How can a program run fine but not output the correct results?

It does not fail at run-time, meaning there are no run-time errors, but the results it outputs, say to console, is not whats expected.

Sarath C26-Jun-06 4:51

26-Jun-06 4:51

check for missing resources.

SaRath.

"It is your attitude, not your aptitude, that determines your altitude - Zig Ziglar."
My Blog | Understanding State Pattern in C++

capricious_00126-Jun-06 5:01

26-Jun-06 5:01

SaRath C wrote:
check for missing resources.

What do you mean? Resources in the preprocesser directives? The debuggers resources? Or somewhere else?

Sarath C26-Jun-06 5:05

26-Jun-06 5:05

there's might have entries in the DoDataExchange function of deleted resources!

SaRath.

"It is your attitude, not your aptitude, that determines your altitude - Zig Ziglar."
My Blog | Understanding State Pattern in C++

capricious_00126-Jun-06 5:19