Windows Node 6.3.0 binary exports SSL symbols

[Flarna]

• Version: 6.3.0
• Platform: Windows (32 + 64 bit)
• Subsystem: build/deps

I work on a project using a native addon where libcurl is used.
If I build with node 6.3.0 headers/libs I get a linker error because of duplicate symbols:

1>libcurl_a.lib(cversion.obj) : error LNK2005: _SSLeay_version already defined in node.lib(node.exe)
1>libcurl_a.lib(ssl_lib.obj) : error LNK2005: _SSL_CTX_ctrl already defined in node.lib(node.exe)
1>libcurl_a.lib(cryptlib.obj) : error LNK2005: _CRYPTO_num_locks already defined in node.lib(node.exe)
1>libcurl_a.lib(cryptlib.obj) : error LNK2005: _CRYPTO_set_dynlock_create_callback already defined in node.lib(node.exe)
1>libcurl_a.lib(cryptlib.obj) : error LNK2005: _CRYPTO_set_dynlock_destroy_callback already defined in node.lib(node.exe)
1>libcurl_a.lib(cryptlib.obj) : error LNK2005: _CRYPTO_set_dynlock_lock_callback already defined in node.lib(node.exe)
1>libcurl_a.lib(cryptlib.obj) : error LNK2005: _CRYPTO_set_locking_callback already defined in node.lib(node.exe)

Looks like node 6.3.0 exports SSL functions for some reason which was not the case for 6.2.2.

Is this intended?

[addaleax]

See #6274 for where this comes from; so, yes, it’s intended that these symbols are available to addons, but of course not that they conflict with other libraries.

/cc @bnoordhuis @nodejs/platform-windows

[bnoordhuis]

With what options is that add-on compiled and linked?

[Flarna]

It's quite a big project with several other 3rd party libraries. Because of this I'm also not using node-gyp to build as it would be quite hard to get this manageable.
In the end I extracted the compiler/linker settings used by node-gyp and use it in my project. This works fine since quite a while now.

Anyhow, I found meanwhile that I can workaround/solve this via the sequence of the libs passed to the linker: I have to ensure that I first pass my 3rd parties (libcurl + ssl,..) first and node.lib at the end.

No idea why the linker is no longer complaining then as the number of symbols doesn't change because of this...

[bnoordhuis]

I'm going to guess that your libcurl_a.lib indiscriminately re-exports symbols from its own dependencies, creating conflicts (or not) depending on the final link order.

On UNIX platforms, you normally compile static libraries with -fvisibility=hidden to stop symbols from getting exported unless explicitly marked as public. Windows probably has a similar flag.

[Flarna]

MSVC acts like gcc with -fvisibility=hidden since I can remember - for MSVC the default is to not export any symbol on default. You explicitly have to specify what your dso/exe should export instead of explicitly hide as for gcc.
Other platform tools like solaris have nothing like -fvisibility=hidden so they export always (like old gcc).

But this is not really the area of my issue as it defines what is visible from the dso/exe created by link step - my issue happens during this link step where libs are put together.
Major diff between linux and windows is that the symbols exported by the node binary are not visible at link step for linux (there is no node.lib). Linux resolves this at load time.
In my case above symbols get resolved by the linker (using my 3rd party libs) and loader resolves just the remaining ones (e.a. towards V8, Node,...).
But on windows the import lib for node is here therefore the linker actually sees both symbols in the link step.

Anyhow, I know how to proceed and that the change in node was intended. From my point of view this issue can be closed.

Thanks for you fast help!

[bnoordhuis]

MSVC acts like gcc with -fvisibility=hidden since I can remember - for MSVC the default is to not export any symbol on default. You explicitly have to specify what your dso/exe should export instead of explicitly hide as for gcc.

Right, that's certainly the case for DLLs and executables (it took me a godawful amount of work to get those openssl symbols exported from node.exe) but my understanding is that in static libraries everything is public by default.

Anyhow, I know how to proceed and that the change in node was intended. From my point of view this issue can be closed.

I'll close then, cheers!

[Flarna]

Yes, for static libs everything is public for MSVC - and also for gcc. -fvisibility=hidden just marks the symbols to get them hidden in the final dso/binary.

[maxkorp]

Edit: Asking my questions in a separate thread in the help repo.

Just a heads up here that https://github.com/nodegit/nodegit is having issues with this as well, and we're using node-gyp.