New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Error running gRPC greeter example with electron #6138

Closed
cyberflohr opened this Issue Apr 11, 2016 · 28 comments

Comments

Projects
None yet
@cyberflohr

cyberflohr commented Apr 11, 2016

Running the node gRPC greeter example with electron will throw the following error.
I'm using electron v0.37.5 which is using Node 5.10.0.
I'm not sure if this error should be fixed inside gRPC or electron. If it should be fixed inside electron, maybe someone could give some details how to fix this, so I can file a bug against the electron project.

[Error: /projects/grpc/examples/node/node_modules/grpc/src/node/extension_binary/grpc_node.node: undefined symbol: GENERAL_NAME_free]
A JavaScript error occurred in the main process
Uncaught Exception:
Error:
/projects/grpc/examples/node/node_modules/grpc/src/node/extension_binary/grpc_node.node: undefined symbol: GENERAL_NAME_free
at Error (native)
at process.module.(anonymous function) as dlopen
at Object.Module._extensions..node (module.js:440:18)
at Object.module.(anonymous function) as .node
at Module.load (module.js:357:32)
at Function.Module._load (module.js:314:12)
at Module.require (module.js:367:17)
at require (internal/module.js:16:19)
at Object. (/projects/grpc/examples/node/node_modules/grpc/src/node/src/grpc_extension.js:38:15)

@sdgn

This comment has been minimized.

Show comment
Hide comment
@sdgn

sdgn Apr 12, 2016

Try linking your gRPC library against libcrypto, e.g.

diff --git a/binding.gyp b/binding.gyp
index 8efc8a2..c391efe 100644
--- a/binding.gyp
+++ b/binding.gyp
@@ -735,6 +735,9 @@
       'include_dirs': [
         "<!(node -e \"require('nan')\")"
       ],
+      'libraries': [
+        "-Wl,-rpath, /path/to/grpc/third_party/openssl-1.0.2f/libcrypto.a"
+      ],
       'cflags': [
         '-std=c++11',
         '-Wall',

You can download and build openssl-1.0.2f using this script:
https://github.com/grpc/grpc/blob/86dd47d355b93ba136fc5a0eaa6f2de0ad0e9b75/tools/openssl/use_openssl.sh

After building grpc_node, you can then npm link to it from your node_modules.

sdgn commented Apr 12, 2016

Try linking your gRPC library against libcrypto, e.g.

diff --git a/binding.gyp b/binding.gyp
index 8efc8a2..c391efe 100644
--- a/binding.gyp
+++ b/binding.gyp
@@ -735,6 +735,9 @@
       'include_dirs': [
         "<!(node -e \"require('nan')\")"
       ],
+      'libraries': [
+        "-Wl,-rpath, /path/to/grpc/third_party/openssl-1.0.2f/libcrypto.a"
+      ],
       'cflags': [
         '-std=c++11',
         '-Wall',

You can download and build openssl-1.0.2f using this script:
https://github.com/grpc/grpc/blob/86dd47d355b93ba136fc5a0eaa6f2de0ad0e9b75/tools/openssl/use_openssl.sh

After building grpc_node, you can then npm link to it from your node_modules.

@starboy

This comment has been minimized.

Show comment
Hide comment
@starboy

starboy May 8, 2016

I'm having this same issue, also using the same versions of node and electron 0.37.8. I've also done as you said and pulled the repo, downloaded openssl, updated my binding.gyp however I'm not seeing anything confirming that libcrypto was linked and after linking my self-built grpc_node@0.15.0-dev I still get the error...

Symbol not found: _GENERAL_NAME_free

starboy commented May 8, 2016

I'm having this same issue, also using the same versions of node and electron 0.37.8. I've also done as you said and pulled the repo, downloaded openssl, updated my binding.gyp however I'm not seeing anything confirming that libcrypto was linked and after linking my self-built grpc_node@0.15.0-dev I still get the error...

Symbol not found: _GENERAL_NAME_free
@murgatroid99

This comment has been minimized.

Show comment
Hide comment
@murgatroid99

murgatroid99 May 9, 2016

Member

Can you try installing the grpc module using the instructions here, with --build-from-source as an additional argument on the npm install line?

Member

murgatroid99 commented May 9, 2016

Can you try installing the grpc module using the instructions here, with --build-from-source as an additional argument on the npm install line?

@sdgn

This comment has been minimized.

Show comment
Hide comment
@sdgn

sdgn May 9, 2016

With Electron 0.37.8 and a recent copy of libssl-dev, npm install with --build-from-source succeeds. Unfortunately, there will remain a few unresolved symbols in the grpc module (e.g. X509_NAME_free), leading to crashes at startup like the one in the original report.

$ nm -u node_modules/grpc/build/Release/grpc_node.node | grep X509
                 U PEM_read_bio_X509
                 U PEM_read_bio_X509_AUX
                 U X509_NAME_ENTRY_get_data
                 U X509_NAME_dup
                 U X509_NAME_free
                 U X509_NAME_get_entry
                 U X509_NAME_get_index_by_NID
                 U X509_STORE_add_cert
                 U X509_free
                 U X509_get_ext_d2i
                 U X509_get_subject_name

sdgn commented May 9, 2016

With Electron 0.37.8 and a recent copy of libssl-dev, npm install with --build-from-source succeeds. Unfortunately, there will remain a few unresolved symbols in the grpc module (e.g. X509_NAME_free), leading to crashes at startup like the one in the original report.

$ nm -u node_modules/grpc/build/Release/grpc_node.node | grep X509
                 U PEM_read_bio_X509
                 U PEM_read_bio_X509_AUX
                 U X509_NAME_ENTRY_get_data
                 U X509_NAME_dup
                 U X509_NAME_free
                 U X509_NAME_get_entry
                 U X509_NAME_get_index_by_NID
                 U X509_STORE_add_cert
                 U X509_free
                 U X509_get_ext_d2i
                 U X509_get_subject_name
@murgatroid99

This comment has been minimized.

Show comment
Hide comment
@murgatroid99

murgatroid99 May 9, 2016

Member

That output you posted isn't directly related to the problems you're seeing. I get the exact same output with a working copy of the library that is built against regular Node. Those symbols are expected to be dynamically resolved when the extension is loaded because the Node binary itself makes the libssl and libcrypto symbols available to extensions.

It looks like Electron may stop it from doing that. I am not familiar with the internals of Electron, so I don't know exactly what's going on. I may have to do the same trick I do on Windows, and ship precompiled binaries that are statically linked with BoringSSL.

Member

murgatroid99 commented May 9, 2016

That output you posted isn't directly related to the problems you're seeing. I get the exact same output with a working copy of the library that is built against regular Node. Those symbols are expected to be dynamically resolved when the extension is loaded because the Node binary itself makes the libssl and libcrypto symbols available to extensions.

It looks like Electron may stop it from doing that. I am not familiar with the internals of Electron, so I don't know exactly what's going on. I may have to do the same trick I do on Windows, and ship precompiled binaries that are statically linked with BoringSSL.

@sdgn

This comment has been minimized.

Show comment
Hide comment
@sdgn

sdgn May 10, 2016

Yes, exactly, see electron/electron@88b6a60.
Apparently, this was done to avoid conflicts with BoringSSL (given that Electron ships with with the Chromium content module). We resolved to linking with OpenSSL for now, but I suppose it would be cleaner to make Electron play well with BoringSSL, instead.

sdgn commented May 10, 2016

Yes, exactly, see electron/electron@88b6a60.
Apparently, this was done to avoid conflicts with BoringSSL (given that Electron ships with with the Chromium content module). We resolved to linking with OpenSSL for now, but I suppose it would be cleaner to make Electron play well with BoringSSL, instead.

@wdawson4

This comment has been minimized.

Show comment
Hide comment
@wdawson4

wdawson4 Jul 7, 2016

@murgatroid99 I am attempting to resolve the same issue with grpc failing to run in electron. Can you offer any guidance on how to:

do the same trick I do on Windows, and ship precompiled binaries that are statically linked with BoringSSL.

I forked grpc and modified the binding.gyp to link to BoringSSL ( i think I did it correctly.. this is my first time working with gyp), but I am still getting the same error as @cyberflohr

Can you see anything wrong with my binding.gyp that might prevent BoringSSL from being linked correctly? Is this the right process to begin with?

wdawson4 commented Jul 7, 2016

@murgatroid99 I am attempting to resolve the same issue with grpc failing to run in electron. Can you offer any guidance on how to:

do the same trick I do on Windows, and ship precompiled binaries that are statically linked with BoringSSL.

I forked grpc and modified the binding.gyp to link to BoringSSL ( i think I did it correctly.. this is my first time working with gyp), but I am still getting the same error as @cyberflohr

Can you see anything wrong with my binding.gyp that might prevent BoringSSL from being linked correctly? Is this the right process to begin with?

@murgatroid99

This comment has been minimized.

Show comment
Hide comment
@murgatroid99

murgatroid99 Jul 7, 2016

Member

@wdawson4 One problem there is that the entire BoringSSL target is under the OS == "win" condition. Another is that in the target_defaults section at the top, some of the stuff under the OS == "win" condition are needed to use BoringSSL, and some of the stuff in the else case of that condition make it link against OpenSSL instead.

Member

murgatroid99 commented Jul 7, 2016

@wdawson4 One problem there is that the entire BoringSSL target is under the OS == "win" condition. Another is that in the target_defaults section at the top, some of the stuff under the OS == "win" condition are needed to use BoringSSL, and some of the stuff in the else case of that condition make it link against OpenSSL instead.

@wdawson4

This comment has been minimized.

Show comment
Hide comment
@wdawson4

wdawson4 Jul 8, 2016

@murgatroid99 thanks for looking it over. Your first point was a simple correction, but I would appreciate it if you could identify what in the OS == "win" condition is required to use BoringSSL and verify that I removed everything in the else condition that was causing it to link to OpenSSL.

in the target_defaults section at the top, some of the stuff under the OS == "win" condition are needed to use BoringSSL

What specifically in the OS == "win" section is required to use BoringSSL?
      ['OS == "win"', {
        "include_dirs": [
          "third_party/boringssl/include",
          "third_party/zlib"
        ],
        "defines": [
          '_WIN32_WINNT=0x0600',
          'WIN32_LEAN_AND_MEAN',
          '_HAS_EXCEPTIONS=0',
          'UNICODE',
          '_UNICODE',
          'NOMINMAX',
          'OPENSSL_NO_ASM',
          'GPR_BACKWARDS_COMPATIBILITY_MODE'
        ],
        "msvs_settings": {
          'VCCLCompilerTool': {
            'RuntimeLibrary': 1, # static debug
          }
        },
        "libraries": [
          "ws2_32"
        ]
},

some of the stuff in the else case of that condition make it link against OpenSSL instead.

I made these changes to correct this:

diff --git a/binding.gyp b/binding.gyp
index 69fa3da..f4947d0 100644
--- a/binding.gyp
+++ b/binding.gyp
@@ -83,7 +83,6 @@
           'GPR_BACKWARDS_COMPATIBILITY_MODE'
         ],
         'include_dirs': [
-          '<(node_root_dir)/deps/openssl/openssl/include',
           '<(node_root_dir)/deps/zlib'
         ],
         'conditions': [
@@ -98,16 +97,7 @@
               '-fprofile-arcs'
             ]
           }
-         ],
-         ["target_arch=='ia32'", {
-             "include_dirs": [ "<(node_root_dir)/deps/openssl/config/piii" ]
-         }],
-         ["target_arch=='x64'", {
-             "include_dirs": [ "<(node_root_dir)/deps/openssl/config/k8" ]
-         }],
-         ["target_arch=='arm'", {
-             "include_dirs": [ "<(node_root_dir)/deps/openssl/config/arm" ]
-         }]
+         ]
         ]
       }]
     ]

Is that correct? Is there anything else that is causing it to link to OpenSSL?

{ # OS != "win"
        'variables': {
          'config': '<!(echo $CONFIG)',
          # The output of "node --version" is "v[version]". We use cut to
          # remove the first character.
          'target%': '<!(node --version | cut -c2-)'
        },
          # Empirically, Node only exports ALPN symbols if its major version is >0.
          # io.js always reports versions >0 and always exports ALPN symbols.
          # Therefore, Node's major version will be truthy if and only if it
          # supports ALPN. The target is "[major].[minor].[patch]". We split by
          # periods and take the first field to get the major version.
        'defines': [
          'TSI_OPENSSL_ALPN_SUPPORT=<!(echo <(target) | cut -d. -f1)',
          'GPR_BACKWARDS_COMPATIBILITY_MODE'
        ],
        'include_dirs': [
          '<(node_root_dir)/deps/zlib'
        ],
        'conditions': [
          ['config=="gcov"', {
            'cflags': [
              '-ftest-coverage',
              '-fprofile-arcs',
              '-O0'
            ],
            'ldflags': [
              '-ftest-coverage',
              '-fprofile-arcs'
            ]
          }
         ]
        ]
      }]
    ]
  },

Thank you for your help.

wdawson4 commented Jul 8, 2016

@murgatroid99 thanks for looking it over. Your first point was a simple correction, but I would appreciate it if you could identify what in the OS == "win" condition is required to use BoringSSL and verify that I removed everything in the else condition that was causing it to link to OpenSSL.

in the target_defaults section at the top, some of the stuff under the OS == "win" condition are needed to use BoringSSL

What specifically in the OS == "win" section is required to use BoringSSL?
      ['OS == "win"', {
        "include_dirs": [
          "third_party/boringssl/include",
          "third_party/zlib"
        ],
        "defines": [
          '_WIN32_WINNT=0x0600',
          'WIN32_LEAN_AND_MEAN',
          '_HAS_EXCEPTIONS=0',
          'UNICODE',
          '_UNICODE',
          'NOMINMAX',
          'OPENSSL_NO_ASM',
          'GPR_BACKWARDS_COMPATIBILITY_MODE'
        ],
        "msvs_settings": {
          'VCCLCompilerTool': {
            'RuntimeLibrary': 1, # static debug
          }
        },
        "libraries": [
          "ws2_32"
        ]
},

some of the stuff in the else case of that condition make it link against OpenSSL instead.

I made these changes to correct this:

diff --git a/binding.gyp b/binding.gyp
index 69fa3da..f4947d0 100644
--- a/binding.gyp
+++ b/binding.gyp
@@ -83,7 +83,6 @@
           'GPR_BACKWARDS_COMPATIBILITY_MODE'
         ],
         'include_dirs': [
-          '<(node_root_dir)/deps/openssl/openssl/include',
           '<(node_root_dir)/deps/zlib'
         ],
         'conditions': [
@@ -98,16 +97,7 @@
               '-fprofile-arcs'
             ]
           }
-         ],
-         ["target_arch=='ia32'", {
-             "include_dirs": [ "<(node_root_dir)/deps/openssl/config/piii" ]
-         }],
-         ["target_arch=='x64'", {
-             "include_dirs": [ "<(node_root_dir)/deps/openssl/config/k8" ]
-         }],
-         ["target_arch=='arm'", {
-             "include_dirs": [ "<(node_root_dir)/deps/openssl/config/arm" ]
-         }]
+         ]
         ]
       }]
     ]

Is that correct? Is there anything else that is causing it to link to OpenSSL?

{ # OS != "win"
        'variables': {
          'config': '<!(echo $CONFIG)',
          # The output of "node --version" is "v[version]". We use cut to
          # remove the first character.
          'target%': '<!(node --version | cut -c2-)'
        },
          # Empirically, Node only exports ALPN symbols if its major version is >0.
          # io.js always reports versions >0 and always exports ALPN symbols.
          # Therefore, Node's major version will be truthy if and only if it
          # supports ALPN. The target is "[major].[minor].[patch]". We split by
          # periods and take the first field to get the major version.
        'defines': [
          'TSI_OPENSSL_ALPN_SUPPORT=<!(echo <(target) | cut -d. -f1)',
          'GPR_BACKWARDS_COMPATIBILITY_MODE'
        ],
        'include_dirs': [
          '<(node_root_dir)/deps/zlib'
        ],
        'conditions': [
          ['config=="gcov"', {
            'cflags': [
              '-ftest-coverage',
              '-fprofile-arcs',
              '-O0'
            ],
            'ldflags': [
              '-ftest-coverage',
              '-fprofile-arcs'
            ]
          }
         ]
        ]
      }]
    ]
  },

Thank you for your help.

@zerbobo

This comment has been minimized.

Show comment
Hide comment
@zerbobo

zerbobo Jul 8, 2016

This is my hack to the 0.13.0 version binding.gyp , and we have made grpc run in electron 0.36.4 under ubuntu1604. Hope this can help :)

diff binding.gyp binding-new.gyp
81c81,82
<           'TSI_OPENSSL_ALPN_SUPPORT=<!(echo <(target) | cut -d. -f1)'
---
>           'TSI_OPENSSL_ALPN_SUPPORT=<!(echo <(target) | cut -d. -f1)',
>           'OPENSSL_NO_ASM'
84,85c85,88
<           '<(node_root_dir)/deps/openssl/openssl/include',
<           '<(node_root_dir)/deps/zlib'
---
>           #'<(node_root_dir)/deps/openssl/openssl/include',
>           #'<(node_root_dir)/deps/zlib'
>           "third_party/boringssl/include",
>           "third_party/zlib"
114c117
<     ['OS == "win"', {
---
>     ['OS == "linux"', {
142c145
<             '-std=c99',
---
>             '-std=gnu99',
750a754,755
>         "boringssl",
>         "z"

zerbobo commented Jul 8, 2016

This is my hack to the 0.13.0 version binding.gyp , and we have made grpc run in electron 0.36.4 under ubuntu1604. Hope this can help :)

diff binding.gyp binding-new.gyp
81c81,82
<           'TSI_OPENSSL_ALPN_SUPPORT=<!(echo <(target) | cut -d. -f1)'
---
>           'TSI_OPENSSL_ALPN_SUPPORT=<!(echo <(target) | cut -d. -f1)',
>           'OPENSSL_NO_ASM'
84,85c85,88
<           '<(node_root_dir)/deps/openssl/openssl/include',
<           '<(node_root_dir)/deps/zlib'
---
>           #'<(node_root_dir)/deps/openssl/openssl/include',
>           #'<(node_root_dir)/deps/zlib'
>           "third_party/boringssl/include",
>           "third_party/zlib"
114c117
<     ['OS == "win"', {
---
>     ['OS == "linux"', {
142c145
<             '-std=c99',
---
>             '-std=gnu99',
750a754,755
>         "boringssl",
>         "z"
@juicemia

This comment has been minimized.

Show comment
Hide comment
@juicemia

juicemia Jul 24, 2016

Hi, I'm having this issue on OS X El Capitan. Anybody had any success?

I tried reinstalling openssl through homebrew and it gave me a message about how Apple is ditching OpenSSL in favor of their own implementation. It said when compiling, I would have to add in some flags myself. The environment variables are:

LDFLAGS=-L/usr/local/opt/openssl/lib
CPPFLAGS=-I/usr/local/opt/openssl/include

I'm currently trying to edit the bindings.gyp file to pass in these variables, and then rebuilding grpc from source by doing:

# from node_modules/grpc
npm install --build-from-source

I'm not very experienced with node-gyp. As a result I haven't had much luck.

EDIT: I don't think the above flags are relevant. I ran brew link openssl --force. However, still no luck. Also, I followed the "npm" instructions here. I'm now rebuilding grpc using the last time in those instructions with --build-from-source.

EDIT (again): I got it working. I added the following condition to 'target_defaults' in binding.gyp.

['OS == "mac"', {
  'libraries': [
    "/usr/local/opt/openssl/lib/libcrypto.a"
  ],
}]

I don't really know how to make this into something cleaner, but I'm willing to work with someone on a pull request. 😄

juicemia commented Jul 24, 2016

Hi, I'm having this issue on OS X El Capitan. Anybody had any success?

I tried reinstalling openssl through homebrew and it gave me a message about how Apple is ditching OpenSSL in favor of their own implementation. It said when compiling, I would have to add in some flags myself. The environment variables are:

LDFLAGS=-L/usr/local/opt/openssl/lib
CPPFLAGS=-I/usr/local/opt/openssl/include

I'm currently trying to edit the bindings.gyp file to pass in these variables, and then rebuilding grpc from source by doing:

# from node_modules/grpc
npm install --build-from-source

I'm not very experienced with node-gyp. As a result I haven't had much luck.

EDIT: I don't think the above flags are relevant. I ran brew link openssl --force. However, still no luck. Also, I followed the "npm" instructions here. I'm now rebuilding grpc using the last time in those instructions with --build-from-source.

EDIT (again): I got it working. I added the following condition to 'target_defaults' in binding.gyp.

['OS == "mac"', {
  'libraries': [
    "/usr/local/opt/openssl/lib/libcrypto.a"
  ],
}]

I don't really know how to make this into something cleaner, but I'm willing to work with someone on a pull request. 😄

@rmarku

This comment has been minimized.

Show comment
Hide comment
@rmarku

rmarku Aug 13, 2016

Hi there, some news about this? I'm having the same problem here. Tryed @Zerqkboo patch but i'm on 0.15 release.

rmarku commented Aug 13, 2016

Hi there, some news about this? I'm having the same problem here. Tryed @Zerqkboo patch but i'm on 0.15 release.

@murgatroid99 murgatroid99 assigned adanilo and unassigned adanilo Aug 15, 2016

@murgatroid99

This comment has been minimized.

Show comment
Hide comment
@murgatroid99

murgatroid99 Aug 15, 2016

Member

I'm working on this, but it's tricky, The fundamental problem is that when building for Node under Linux and Mac, we need to use the OpenSSL that's built into Node because the Node headers include the OpenSSL headers, but when building for Electron, we need to use BoringSSL because Electron doesn't export those symbols. Unfortunately, there's no way to check in the gyp file whether you're building for Electron. I filed electron/electron#6556 to change that.

So, as this issue demonstrates, it's easy enough to compile this library for Electron; the hard part is determining when to choose those compilation options.

Member

murgatroid99 commented Aug 15, 2016

I'm working on this, but it's tricky, The fundamental problem is that when building for Node under Linux and Mac, we need to use the OpenSSL that's built into Node because the Node headers include the OpenSSL headers, but when building for Electron, we need to use BoringSSL because Electron doesn't export those symbols. Unfortunately, there's no way to check in the gyp file whether you're building for Electron. I filed electron/electron#6556 to change that.

So, as this issue demonstrates, it's easy enough to compile this library for Electron; the hard part is determining when to choose those compilation options.

@boodyvo

This comment has been minimized.

Show comment
Hide comment
@boodyvo

boodyvo Sep 21, 2016

How did you compile grpc? I have the DLL issue

boodyvo commented Sep 21, 2016

How did you compile grpc? I have the DLL issue

@FTAndy

This comment has been minimized.

Show comment
Hide comment
@FTAndy

FTAndy Sep 30, 2016

same problem, but we decide to wrap the grpc with http, so we just request http in the electron to solve it. currently, there is not a clean way to deal with it.

FTAndy commented Sep 30, 2016

same problem, but we decide to wrap the grpc with http, so we just request http in the electron to solve it. currently, there is not a clean way to deal with it.

@bootstraponline

This comment has been minimized.

Show comment
Hide comment
@bootstraponline

bootstraponline Oct 4, 2016

it's easy enough to compile this library for Electron;

@murgatroid99 How do you compile grpc for Electron on Windows?

It'd be nice to have this information somewhere. electron-rebuild is not working with the greeter example.

bootstraponline commented Oct 4, 2016

it's easy enough to compile this library for Electron;

@murgatroid99 How do you compile grpc for Electron on Windows?

It'd be nice to have this information somewhere. electron-rebuild is not working with the greeter example.

@murgatroid99

This comment has been minimized.

Show comment
Hide comment
@murgatroid99

murgatroid99 Oct 4, 2016

Member

That quotation was referring to the binding.gyp modifications that others suggested above. On Linux, gRPC does not currently work with Electron out of the box. But on Windows, I would expect it to already work, because those binding.gyp changes are already applied to Windows.

What specific errors are you seeing when you try to run electron-rebuild?

Member

murgatroid99 commented Oct 4, 2016

That quotation was referring to the binding.gyp modifications that others suggested above. On Linux, gRPC does not currently work with Electron out of the box. But on Windows, I would expect it to already work, because those binding.gyp changes are already applied to Windows.

What specific errors are you seeing when you try to run electron-rebuild?

@bootstraponline

This comment has been minimized.

Show comment
Hide comment
@bootstraponline

bootstraponline Oct 4, 2016

I keep getting:

..\src\node\ext\call.cc(616): error C2039: 'SetHiddenValue': is not a member of 'v8::Object' [C:\myproj\node_modules\grpc\build\grpc_node.vcxproj]

bootstraponline commented Oct 4, 2016

I keep getting:

..\src\node\ext\call.cc(616): error C2039: 'SetHiddenValue': is not a member of 'v8::Object' [C:\myproj\node_modules\grpc\build\grpc_node.vcxproj]

@murgatroid99

This comment has been minimized.

Show comment
Hide comment
@murgatroid99

murgatroid99 Oct 4, 2016

Member

OK, that's the same error that's getting reported in #8166. My best guess at the moment is that Electron uses a very new version of v8, and that specific method has been deprecated and removed. I expect to remove the call to that method soon, and then the following release should build properly.

Alternatively, you may be able to get it to work for now with a slightly older version of Electron.

Member

murgatroid99 commented Oct 4, 2016

OK, that's the same error that's getting reported in #8166. My best guess at the moment is that Electron uses a very new version of v8, and that specific method has been deprecated and removed. I expect to remove the call to that method soon, and then the following release should build properly.

Alternatively, you may be able to get it to work for now with a slightly older version of Electron.

@bootstraponline

This comment has been minimized.

Show comment
Hide comment
@bootstraponline

bootstraponline Oct 4, 2016

There's a npm shrinkwrap + forking grpc work around as an alternative to using Electron v1.2.x.

bootstraponline commented Oct 4, 2016

There's a npm shrinkwrap + forking grpc work around as an alternative to using Electron v1.2.x.

@troylelandshields

This comment has been minimized.

Show comment
Hide comment
@troylelandshields

troylelandshields Oct 13, 2016

I am experiencing this issue as well. There are a lot of ideas in here but none of them really spell out exactly what to do and whether or not it's actually worked for anyone.

troylelandshields commented Oct 13, 2016

I am experiencing this issue as well. There are a lot of ideas in here but none of them really spell out exactly what to do and whether or not it's actually worked for anyone.

@eltoro

This comment has been minimized.

Show comment
Hide comment
@eltoro

eltoro Oct 26, 2016

Is there any fix for this that works for Sierra? I'm using electron 1.4.4 and node 6.8.1. I've done:

brew install openssl --force

and then

LDFLAGS=-L/usr/local/opt/openssl/lib CPPFLAGS=-I/usr/local/opt/openssl/include ./node_modules/.bin/electron-rebuild

It rebuilds the extension binary but I still get the error: Symbol not found: _GENERAL_NAME_free

I even tried manually building with:

cd node_modules/grpc
LDFLAGS=-L/usr/local/opt/openssl/lib CPPFLAGS=-I/usr/local/opt/openssl/include HOME=~/.electron-gyp node-pre-gyp rebuild --target=1.4.4 --arch=x64 --dist-url=https://atom.io/download/atom-shell

eltoro commented Oct 26, 2016

Is there any fix for this that works for Sierra? I'm using electron 1.4.4 and node 6.8.1. I've done:

brew install openssl --force

and then

LDFLAGS=-L/usr/local/opt/openssl/lib CPPFLAGS=-I/usr/local/opt/openssl/include ./node_modules/.bin/electron-rebuild

It rebuilds the extension binary but I still get the error: Symbol not found: _GENERAL_NAME_free

I even tried manually building with:

cd node_modules/grpc
LDFLAGS=-L/usr/local/opt/openssl/lib CPPFLAGS=-I/usr/local/opt/openssl/include HOME=~/.electron-gyp node-pre-gyp rebuild --target=1.4.4 --arch=x64 --dist-url=https://atom.io/download/atom-shell
@trusktr

This comment has been minimized.

Show comment
Hide comment
@trusktr

trusktr Apr 25, 2018

Try linking your gRPC library against libcrypto, e.g.

@sdgn Besides building openssl then adding those lines to binding.gyp, what else so we have to do?

I try node-gyp configure in the grpc-node/packages/grpc-native-core but I get

gyp: Undefined variable module_name in binding.gyp while trying to load binding.gyp

I see it has some lines like this:

    {
      "target_name": "action_after_build",
      "type": "none",
      "dependencies": [ "<(module_name)" ],
      "copies": [
        {
          "files": [ "<(PRODUCT_DIR)/<(module_name).node"],
          "destination": "<(module_path)"
        }
      ]
    }

trusktr commented Apr 25, 2018

Try linking your gRPC library against libcrypto, e.g.

@sdgn Besides building openssl then adding those lines to binding.gyp, what else so we have to do?

I try node-gyp configure in the grpc-node/packages/grpc-native-core but I get

gyp: Undefined variable module_name in binding.gyp while trying to load binding.gyp

I see it has some lines like this:

    {
      "target_name": "action_after_build",
      "type": "none",
      "dependencies": [ "<(module_name)" ],
      "copies": [
        {
          "files": [ "<(PRODUCT_DIR)/<(module_name).node"],
          "destination": "<(module_path)"
        }
      ]
    }
@trusktr

This comment has been minimized.

Show comment
Hide comment
@trusktr

trusktr Apr 25, 2018

Do you mind explaining how to build this from scratch, so it can finally be linked into a project? (I looked at docs on grpc.io, but it isn't clear, or I've missed it).

trusktr commented Apr 25, 2018

Do you mind explaining how to build this from scratch, so it can finally be linked into a project? (I looked at docs on grpc.io, but it isn't clear, or I've missed it).

@sdgn

This comment has been minimized.

Show comment
Hide comment
@sdgn

sdgn Apr 25, 2018

@sdgn Besides building openssl then adding those lines to binding.gyp, what else so we have to do?

I am not sure if this is what you are looking for, but the Node.js package for gRPC now comes with precompiled binaries for Electron.

npm install grpc --runtime=electron --target=<electron version>

sdgn commented Apr 25, 2018

@sdgn Besides building openssl then adding those lines to binding.gyp, what else so we have to do?

I am not sure if this is what you are looking for, but the Node.js package for gRPC now comes with precompiled binaries for Electron.

npm install grpc --runtime=electron --target=<electron version>
@trusktr

This comment has been minimized.

Show comment
Hide comment
@trusktr

trusktr Apr 25, 2018

@sdgn Thanks, that works! How do I store those flags somewhere (f.e. package.json) so that I just run npm install in my project and it works? (I have grpc listed in dependencies). I can't find any documentation on these flags.

trusktr commented Apr 25, 2018

@sdgn Thanks, that works! How do I store those flags somewhere (f.e. package.json) so that I just run npm install in my project and it works? (I have grpc listed in dependencies). I can't find any documentation on these flags.

@trusktr

This comment has been minimized.

Show comment
Hide comment
@trusktr

trusktr Apr 25, 2018

Basically, just want end users to run npm i and that's it.

trusktr commented Apr 25, 2018

Basically, just want end users to run npm i and that's it.

@trusktr

This comment has been minimized.

Show comment
Hide comment
@trusktr

trusktr Apr 25, 2018

Found a solution that works for now: I removed grpc from package.json's dependencies, then I added

	"postinstall": "npm install grpc@1.7.3 --runtime=electron --target=1.7.9"

So, all that is needed is npm install in the project root.

Seems like grpc should be listed in dependencies, and somehow those flags passed to grpc (taken from somewhere) during npm install with no flags. Again, I just want end users to run npm install with no extra flags.

trusktr commented Apr 25, 2018

Found a solution that works for now: I removed grpc from package.json's dependencies, then I added

	"postinstall": "npm install grpc@1.7.3 --runtime=electron --target=1.7.9"

So, all that is needed is npm install in the project root.

Seems like grpc should be listed in dependencies, and somehow those flags passed to grpc (taken from somewhere) during npm install with no flags. Again, I just want end users to run npm install with no extra flags.

@dachinat

This comment has been minimized.

Show comment
Hide comment
@dachinat

dachinat Jul 16, 2018

npm install grpc --runtime=electron --target=<electron version> this works if I run electron as globally installed binary, but if I write "electron": "electron ." in package.json and run yarn electron or npm run electron then I'm still getting an error. Could you help please.

Sorry, I had different version installed non-globally.

dachinat commented Jul 16, 2018

npm install grpc --runtime=electron --target=<electron version> this works if I run electron as globally installed binary, but if I write "electron": "electron ." in package.json and run yarn electron or npm run electron then I'm still getting an error. Could you help please.

Sorry, I had different version installed non-globally.

@lock lock bot locked as resolved and limited conversation to collaborators Oct 14, 2018

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