views:

832

answers:

4

I am planning to use libraries in my C++ program. Development is happening on LINUX but application is designed to compile on both LINUX and Windows. I understand direct equivalent for shared libraries(.so) in windows is DLL, right?

In LINUX using g++, I can create shared library using -fPIC and -shared flags. AFAIK, there is no other code change required for a shared library. But things are different in a Windows DLL. There I should specify the functions which has to be exported using dllexport, right?

My question is how do I manage this situation? I mean dllexport is invalid in LINUX and compiler will give error. But it is required in windows. So how do I write the function which will compile on both platforms without any code change?

Compilers used

g++ - LINUX

VC++ - Windows

Any help would be great!

+2  A: 

You can use #ifdef preprocessor directive for conditional compiling. For example:

#ifdef WIN32
    // Win32 specific code
#else
    // Elsewhere
#endif
Alan Haggai Alavi
+5  A: 

We specify __declspec(dllexport) for class:

#define EXPORT_XX __declspec(dllexport)

class EXPORT_XX A
{
};

You can then check for platform and only define the macro on windows. E.g.:

#ifdef WIN32
#define EXPORT_XX __declspec(dllexport)
#else
#define EXPORT_XX
#endif

We mostly build static libraries so there might be more stuff to do for dynamic libs but the concept is the same - use preprocessor macro to define string that you need to insert into Windows code.

stefanB
Thanks. What will be the type of DLL created in the windows? Will that be a COM dll? Are there chances for running into DLL hell issues?
Appu
Using dllexport does not cause the dll to be exposed to the COM system. Chances of dll hell depend upon how you distribute the dll and application. If you always install the dlls your app requires, then the problem as it relates to this dll is not an issue.
sean e
@sean e : Thanks. I will always install the DLL's app requires into the application directory. Sometimes there may be small updates which will just replace one DLL rather than whole application. Will that be a problem?
Appu
@Appu - should only be a problem if you remove functions and/or change their signature. And of course if you adversely change the expected functionality.
Marc Bernier
+5  A: 

Another alternative is to just use a .def file for your windows project. This file specifies the DLL exports, so you won't have to mess up your code base. (But macros are definately the way to go if you want to avoid the extra file.)

Peter Ruderman
Using C++ symbols in .def files can get pretty messy.
sean e
Depends on what he's doing, if by libraries he means some sort of plugin architecture, he's better off with a C interface and .def files would work.
You can call me Chuck
+1  A: 

Another option, one that I use now, is to use MinGW on Windows. This way you can use gcc on Windows, and you don't have to worry about the declspec nonsense.

Mark Beckwith
Thanks for the reply. Well, this is an open-source application and I want to support wide range of compilers to compile application successfully. So I guess all these nonsense are required.
Appu