Skip to content

Windows Node 6.3.0 binary exports SSL symbols #7608

Closed
Closed
Windows Node 6.3.0 binary exports SSL symbols#7608
Labels
addonsIssues and PRs related to native addons.opensslIssues and PRs related to the OpenSSL dependency.windowsIssues and PRs related to the Windows platform.

Description

@Flarna
Flarna
opened on Jul 8, 2016
  • 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?

Activity

  1. addaleax
    added
    opensslIssues and PRs related to the OpenSSL dependency.
    addonsIssues and PRs related to native addons.
    windowsIssues and PRs related to the Windows platform.
    on Jul 8, 2016

  2. addaleax commented on Jul 8, 2016

    @addaleax
    addaleax
    on Jul 8, 2016
    Member

    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

  3. bnoordhuis commented on Jul 8, 2016

    @bnoordhuis
    bnoordhuis
    on Jul 8, 2016
    Member

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

  4. Flarna commented on Jul 8, 2016

    @Flarna
    Flarna
    on Jul 8, 2016
    MemberAuthor

    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...

  5. bnoordhuis commented on Jul 8, 2016

    @bnoordhuis
    bnoordhuis
    on Jul 8, 2016
    Member

    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.

  6. Flarna commented on Jul 8, 2016

    @Flarna
    Flarna
    on Jul 8, 2016
    MemberAuthor

    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!

  7. bnoordhuis commented on Jul 8, 2016

    @bnoordhuis
    bnoordhuis
    on Jul 8, 2016
    Member

    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!

  8. bnoordhuis
    closed this as completedon Jul 8, 2016

  9. Flarna commented on Jul 8, 2016

    @Flarna
    Flarna
    on Jul 8, 2016
    MemberAuthor

    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.

  10. maxkorp commented on Aug 12, 2016

    @maxkorp
    maxkorp
    on Aug 12, 2016

    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.

  11. JCMais commented on Oct 6, 2018

    @JCMais
    JCMais
    on Oct 6, 2018
    Contributor

    I'm having a similar problem at the issue linked above (nodejs/node-gyp#1559), and I would love some help there.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    addonsIssues and PRs related to native addons.opensslIssues and PRs related to the OpenSSL dependency.windowsIssues and PRs related to the Windows platform.

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions