Sign in to follow this  
Guest zip

C and C++ - duplicate dllmain

Recommended Posts

Hi,I'm working with Visual C++ (VS2003) and have a gauge in three modules, two are in C++ (cpp) using DirectX, and the main gauge file in straight C. No problem compiling but I have a conflict between the CPP libraries and the C libraries, in that I have two _DLLMain entries (one for the CPP libraries, one for the C library) and a linker 2005 error (duplicate symbol). The gauge compiles just fine as long as I don't use any of the libraries (.lib) written in CPP.The culprit is no doubt the GAUGE.H file that declares the DLL main entry point, but MS also says you can't combine some libraries.My choices are (I think):1) write the gauge code in CPP so the libraries are used throughout2) split the C and CPP code as two DLLs and link to the external DLL from the C gauge code.I think 1) is far better, given that most all the code I've seen in DirectX is in C++ or C#, but alas, the SDK example, and Dai Griffith's excellent tutorial haven't shed any light on the subject. Anyone can share a config or tips on how to resolve this? I can't seem to locate an example Gauge in C++. Is there a header file (gauge.h) modified to work with C++ and classes?Thanks,

Share this post


Link to post
Share on other sites
Help AVSIM continue to serve you!
Please donate today!

All gauges.h, including the current fs9gauges.h, from Dais tutorials are C++ compatible. In my experience there is no need to add the DirectX part as a DLL, this will always lead to the DLLMain conflict. Just use the parts that you need, e.g. from application examples or suchlike. I'm currently working on a tracffic radar gauge example, completetly in C++ which might find it's way to Dais tutorial in future.Arne Bartels

Share this post


Link to post
Share on other sites

Thanks Arne,after playing with it some more, it looks like that short of eliminating MFC and ATL from the equation, I'm not going to get the linker to cooperate.Looking at doing just that, or using separate DLLs. This is so far the type of project where 25% of the time is spent on the "meat" and bug fixing, the rest losing hair on playing a sleuth detective.But, that's part of the fun isn't it?

Share this post


Link to post
Share on other sites

25%! Wow that's good. I'm usually around 10% and 90% is doctoring! As you said that's the fun actually.Which DirectX components do you want to insert in the gauge? I doodled around with DirectInput some time ago. It was relatively easy to adapt the example code to my needs without any need of MFC or suchlike. It is even possible to mix C coded gauges together with C++ DirectX code.Arne Bartels

Share this post


Link to post
Share on other sites

What I did was to declare all DirectX function that interact with C code as extern "C". Only tried with DirectSound and directInput. Directplay I use in external program. You don't need MFC just plain Win32 API.Here:http://www.jcboliveira.flysplash.org/you can find DirectSound and DirectPlay, for DirectInput I have the code but no comments on it :(Jos

Share this post


Link to post
Share on other sites

I believe you're both right - it's 5% meat, 20% debugging, and the rest a sordid mixture (in no particular order) of fermented grape juice (keeps spirits up), tylenol (fixes the de-facto grape juice overdose), choice (but nice) words to describe "what were they thinking!" (the FS team) and "ok, this has gotta work, someone else when through this and survived". Did I mention the fishing expedition? :DOk, I finally got it to link in VS2003 with no errors and in CPP mode by yanking the AFX stuff from the code (eg, eliminate stdafx.h from the equation). Took all day (most of it is my learning curve). Part of my problem is that nearly all the examples in the DirectX SDK are in C++ or C# using AFX or .NET, a far cry from being usable as is with straight C. It is evident that the moment ATL or MFC is involved, it becomes impossible to link as a normal FS9 DLL. If you change the priority of the linking (library wise), even though supposedly MFS has "weak" definitions for DLLMain, the rest of AFX blows up with missing symbols (at least in my case).Conclusion: don't mix MFC/ATL framework with this, or use separate DLLs.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this