--features=windows_export_all_symbols does not export all symbols

[vnghia]

Description of the problem / feature request:

--features=windows_export_all_symbols does not export all symbols ( extern variable )

Bugs: what's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.

// utils.h
extern const int a;
// utils.cpp
const int a = 1;
// main.cpp
std::cout << a; // main.obj : error LNK2001: unresolved external symbol "int const a" (?a@@3HB)

// utils.h
DLL_EXPORT extern const int a;
// utils.cpp
const int a = 1;
// main.cpp
std::cout << a; // ok

What operating system are you running Bazel on?

Windows 10

What's the output of bazel info release?

3.3

Have you found anything relevant by searching the web?

I I had a look at this file https://github.com/bazelbuild/bazel/blob/master/third_party/def_parser/def_parser.cc
I think those lines cause the bug

bazel/third_party/def_parser/def_parser.cc

Lines 257 to 262 in 1dbf65b

	if (!pSymbolTable->Type && (SectChar & IMAGE_SCN_MEM_WRITE)) {
	// Read only (i.e. constants) must be excluded
	this->DataSymbols.insert(symbol);
	} else {
	if (pSymbolTable->Type || !(SectChar & IMAGE_SCN_MEM_READ) ||
	(SectChar & IMAGE_SCN_MEM_EXECUTE)) {

Because IMAGE_SCN_MEM_READ variable is not inserted to the TableSymbol

Beside, I found something https://stackoverflow.com/questions/19373061/what-happens-to-global-and-static-variables-in-a-shared-library-when-it-is-dynam which say that the extern global variables are not part of the exported symbols ( but __declspec(dllexport) can export it ? )

Any other information, logs, or outputs that you want to share?

If this is a bug, I am very happy to contribute to fix this bug

[Riatre]

This might be a bug, depends on how you see it.

Basically, according to MSDN, on Windows, it is required to mark the declaration of the function/class/variable as dllexport on the export side, and dllimport on the consuming side.

I believe --features=windows_export_all_symbols is meant to be similar to CMake's WINDOWS_EXPORT_ALL_SYMBOLS, for easier porting. Unfortunately, both does not work out of the box for global variables. That's because MS toolchain enforces the following constraint: global variables (extern) must be marked as __declspec(dllimport) if it will be imported from other library. So even if your dll does export the global variable, you still have to change your header file to consume it, pretty much defeating the purpose of windows_export_all_symbols. Because of all this, I'm not sure whether it is more "correct" to still export those symbols (like CMake), or don't do it since it cannot be used without code change.

[vnghia]

I think it maybe easier if we add __declspec(dllimport) to the code than have a macro to switch between __declspec(dllimport) and __declspec(dllexport). What do you think ?

[Riatre]

Yeah, that makes sense. I'm not sure if you can export a symbol marked as __declspec(dllimport) though.

[vnghia]

I add (Setchar & IMAGE_SNC_MEM_READ) && (Setchar & IMAGE_SCN_MEM_SHARED) and the symbol is still exposed. But I am not sure this is the correct way