Not building uws correctly?

[maikelmclauflin]

I'm not sure if this is a bug per-se because i don't know who is building uws, but the problem is manifesting itself there and the only module requiring it is this one so here i am.

You want to:

• report a bug?

Current behaviour

error on build in uws

Expected behaviour

not to error on build

Setup

• OS: mac osx
• browser: electron
• engine.io version: 3.1.3

Other information (e.g. stacktraces, related issues, suggestions how to fix)

in stdout

dyld: lazy symbol binding failed: Symbol not found: _SSL_library_init
  Referenced from: /Users/michaelmclaughlin/Sites/specless/cloud-compiler/sync/node_modules/uws/uws_darwin_57.node
  Expected in: flat namespace

dyld: Symbol not found: _SSL_library_init
  Referenced from: /Users/michaelmclaughlin/Sites/specless/cloud-compiler/sync/node_modules/uws/uws_darwin_57.node
  Expected in: flat namespace

in build log

  CXX(target) Release/obj.target/uws/src/Extensions.o
  CXX(target) Release/obj.target/uws/src/Group.o
In file included from ../src/Group.cpp:1:
In file included from ../src/Group.h:4:
In file included from ../src/WebSocket.h:4:
In file included from ../src/WebSocketProtocol.h:5:
../src/Networking.h:7:10: fatal error: 'openssl/opensslv.h' file not found
#include <openssl/opensslv.h>
         ^~~~~~~~~~~~~~~~~~~~
1 error generated.
make: *** [Release/obj.target/uws/src/Group.o] Error 1
gyp ERR! build error 
gyp ERR! stack Error: `make` failed with exit code: 2
gyp ERR! stack     at ChildProcess.onExit (/usr/local/lib/node_modules/npm/node_modules/node-gyp/lib/build.js:258:23)
gyp ERR! stack     at emitTwo (events.js:125:13)
gyp ERR! stack     at ChildProcess.emit (events.js:213:7)
gyp ERR! stack     at Process.ChildProcess._handle.onexit (internal/child_process.js:200:12)
gyp ERR! System Darwin 16.7.0
gyp ERR! command "/usr/local/Cellar/node/8.4.0/bin/node" "/usr/local/lib/node_modules/npm/node_modules/node-gyp/bin/node-gyp.js" "rebuild"
gyp ERR! cwd /Users/michaelmclaughlin/Sites/specless/cloud-compiler/sync/node_modules/uws
gyp ERR! node -v v8.4.0
gyp ERR! node-gyp -v v3.6.2
gyp ERR! not ok 

[vincentbriglia]

I'm getting the same in stdout, but the latter error is a question of setting the right location for your openssl headers.

Something like LDFLAGS=-L/usr/local/opt/openssl/lib CPPFLAGS=-I/usr/local/opt/openssl/include HOME=~/.electron-gyp node-gyp rebuild --target=1.7.9 --arch=x64 --dist-url=https://atom.io/download/electron in your uws folder might do the trick.

however, for me that doesn't remove the first error and it's doing my head in

[d4tocchini]

this was a nightmare of a bug. my solution:

eliminate socketio.

i was looking for an excuse to use webrtc as the interwindow ipc mechanism in electron anyway...

[airtoxin]

Set environment variable export EIO_WS_ENGINE=ws to use ws instead of uws.

[ghost]

1. uws is not an Electron module. It is a Node.js module. This is clearly stated in the README and FAQ. You're far from the first one to report such a "bug".

2. uws is not a PlayStation 4 game. It is also not an app for Windows Phone. Neither is it a swimming pool. It is a Node.js module.

3. uws (for Node.js) has precompiled binaries and will gracefully fall back to these if compilation fails. Also, there is no need whatsoever to tinker with headers like @vincentbriglia - that's not even the proper way! Nobody tells you to mix and match like that! "npm install uws" is official, nothing else!

4. Electron is not even a server project!

[253153]

What's the best way to resolve this?

[ghost]

Wow, that's a lot of downvotes. Yeah, I guess it all falls on me to somehow fix up completely separate environments that I didn't even target.

../src/Networking.h:7:10: fatal error: 'openssl/opensslv.h' file not found
#include <openssl/opensslv.h>

Electron is not providing OpenSSL headers, go shame Electron for this - I'm no magician and I cannot just make third-parties obey by Node.js rules. They are not even the same platform!

This would be the same as require('fs') failing due to missing the fs module in Node.js - it makes no sense from a Node.js module's perspective.

Consider this thought experiment:

What if I took, say, Express.js and shoved that JavaScript code into a third-party JavaScript environment that lacked 90% of all prorgamming interfaces that are in Node.js. Would you blame Express.js for this? Because it obviously wouldn't work.

What if I took Socket.IO and tried to run it in a Python environment? Ruby environment?

You starting to get my point? I can't fix things I have no control over and I never said it would work in Electron, they are not the same platform just because a portion of some JavaScript happens to work in both.

C++ is not scripting, you can't just take a Box and shove it through a Round hole and expect it to just magically work.

In any case, just use ws instead because with Socket.IO you don't see any difference since the bottleneck is not in ws nor uws, it is in Socket.IO itself.

[OliverRadini]

In case anyone stumbles across this and is confused about how to switch to ws from uws, I found that you can just change this on the options, for instance:

var io = require('socket.io')(80, { wsEngine: 'ws' });

If there's a better way, please correct me.

[mtrabelsi]

if you use socket io in node install this as well :

npm i --save uws
npm i --save utf-8-validate
npm i --save bufferutil

[darrachequesne]

@Donutttt @mtrabelsi uws is not the default websocket engine anymore (since 3.2.0)

So by default, require('socket.io')(80); will now use ws.

The performance of the ws package can be improved with two native libs (which are not included by default):

npm i --save utf-8-validate bufferutil

To use uws, you have to install it and select it as wsEngine:

npm i --save uws
// and then
var io = require('socket.io')(80, { wsEngine: 'uws' });

Hope that clears things up!

[ProductOfAmerica]

I solved this in WebStorm by entering yarn add socket.io into the console manually. WebStorm seemed to think the package was installed, and yarn wouldn't do anything when I yarn install'd.