Question

I am trying to create a shared library on Windows. I am able to create this shared library on linux but on windows I get linker errors. I am using the MinGW G++ 4.5 compiler. I will first present the source code to the example on linux , and then present the file which I tried to change on windows.

/home/nxd/Progs/C++/shared-lib>cat lib_interface.h 

#ifndef LIBINTERFACE_H
#define LIBINTERFACE_H

int func(int a);

#endif /* LIBINTERFACE_H */
/home/nxd/Progs/C++/shared-lib>cat sh_lib.cpp 
extern int b;

int func(int a)
{
 return a+b;
}
/home/nxd/Progs/C++/shared-lib>cat main.cpp 
#include <iostream>
#include "lib_interface.h"

int b;

int main()
{
 b=10;
 std::cout << func(20) << std::endl;
}

/home/nxd/Progs/C++/shared-lib>cat Makefile 
OBJS = main.o sh_lib.o

test: main.o libshared.so
 g++ -L. -o$@ main.o -lshared

main.o: main.cpp lib_interface.h
 g++ -c -Wall -fPIC $<

sh_lib.o: sh_lib.cpp lib_interface.h
 g++ -c -Wall -fPIC $<

libshared.so: sh_lib.o
 ld -shared -soname=libshared.so -o libshared.so.1 $<
 ln -s libshared.so.1 libshared.so

.PHONY: clean

clean:
 rm *.o *.so *.so.1
/home/nxd/Progs/C++/shared-lib>make
g++ -c -Wall -fPIC main.cpp
g++ -c -Wall -fPIC sh_lib.cpp
ld -shared -soname=libshared.so -o libshared.so.1 sh_lib.o
ln -s libshared.so.1 libshared.so
g++ -L. -otest main.o -lshared
/home/nxd/Progs/C++/shared-lib>LD_LIBRARY_PATH=. ./test
30

I tried to make a shared library out of sh_lib.cpp using MinGW g++ on Windows. The reason there are so many comments is because of the many things I tried before I decided to post this.

/home/nxd>cat sh_lib.cpp 
//extern "C" __declspec(dllimport) int b;
//#ifdef __cplusplus 
//extern "C" { 
//#endif 

__declspec(dllimport) extern int b;
//__declspec(dllimport) int b;
//extern int b;

//#ifdef __cplusplus 
//} 
//#endif 

int func(int a)
{
 return a+b;
}

Here is the relevant portion of the Makefile with various tweaks. The options passed to the linker that you see below were added one by one to try to get rid of the link error. The ld command below was just to be sure that the linker was indeed getting the options. The preceding hyphen tells make to run the next command even if the current one had errors.

sh_lib.o: sh_lib.cpp lib_interface.h
 g++ -c -Wall -fPIC $<

libshared.so: sh_lib.o
 -ld -shared --enable-auto-import --unresolved-symbols=ignore-in-shared-libs   -soname=libshared.so --allow-shlib-undefined -o libshared.so.1 $<
 g++ -shared  -Wl,--unresolved-symbols=ignore-in-shared-libs  -Wl,--enable-auto-import -Wl,--allow-shlib-undefined -Wl,-soname,libshared.so -o libshared.so.1 $<

My Question: how can I compile sh_lib.cpp into a dll using the extern variable like the way it works in linux?. I did read the stackoverflow article :
Can't access variable in C++ DLL from a C app , but “I think” there is a subtle difference here between the 2 cases. There he was trying to link with a file, here I am trying to create a shared library, using a variable for which storage has not been allocated (extern), and I want to tell the linker to ignore this variable’s storage when creating the library – it will be resolved when I am linking with an exe. I am currently managing this problem with static linking.

Many thanks for your help in advance.

Answer 1

I provided my answer in email (because the original poster repeated his question in email to a list I follow) complete with modified sample source that works as he wanted. See http://mingw-users.1079350.n2.nabble.com/using-an-external-variable-in-C-in-a-shared-library-tp5521039p5521149.html . I won’t bother repeating the whole thing here. Just some key points:

• declspec(dllimport/dllexport) is required for variables, yes
• to import a variable from the .exe, you need to treat the exe as a dll in the sense that you generate an import library for it to link the shared library with
• but actually, you don’t want to import variables from the exe as that means only an exe with that name can use the shared library in question
• instead, redesign the software to not have variables in the API boundaries. Just have the an API in the library a function to “register” data in the main (or wherever) needed by subsequent calls to the library instead
• and actually, just as an advice, don’t use variables in the API of libraries either, a pure function-based API is much nicer
• note that the original poster uses MinGW, so don’t bother commenting if you have experience only of MSVC. They might well differ in some key aspects here
• finally, I am not really a C++ guy, so I talk from a pure C aspect above, sorry. C++ classes etc will definitely make the situation more complex, and cause even more annoying differences between gcc on Linux / gcc on Windows (MinGW) / MSVC / and others