Need 64-bit version for Mac OS X #296

Closed
jadonk opened this Issue Dec 27, 2012 · 19 comments
@jadonk

I'm attempting to use the mdns node module which has several C files that need to be compiled. I've tried every '-arch i386' and '-m32' dance I can come up with and even entirely rebuilt gcc, but I'm not having success in building a 32-bit toolchain that works with the 32-bit build of node-webkit.

Is it possible to provide a 64-bit build and/or provide instructions on how to build for your 32-bit build under OS X Mountain Lion?

@mblinsitu

I had a similar problem trying to use client-side now.js in node-webkit. Client-side now.js requires node-proxy which compiles into a 64-bit build on the Mac.

I managed to build a 32-bit version of node-proxy as follows:

  • I installed nw-gyp
  • I ran nw-gyp configure --target=0.3.6
  • I edited the generated file nodeproxy.target.mk in the build directory by replacing -arch x86_64 by -arch i386
  • I ran nw-gyp build

I got a 32-bit version of the compiled library (nodeproxy.node), which I put in place of the one in the standard install.

A bit dirty but it worked - Hope it will work for you too!

Having said that, I too would like a 64-bit version of node-webkit!

@heavyk

I tried generating the gyp files for chromium with -Dtarget_arch=x64 and also adding 'target_arch': 'x64' to the variables section of ~/.gyp/include.gypi. that should force chromium to 64 bits, but from then on, I got compiler errors from node. specifically in the crypto section where it's using mmx/asm. node is obviously compiling for i386.

it may be as easy as setting node to x64 but I doubt it ... dunno. if I have time, I will look at it later

@heavyk

ok, I got further... both host_arch and target_arch need to be overridden ... which just leaves ffmpeg errors now. still feel like I'm not doing it "the right way" :)

@mblinsitu

Sounds promising to me. This page has a script to compile 64-bit ffmpeg, if this helps: https://gist.github.com/1632062.

Side question: do you or anybody know if it is possible to enable the Harmony features of V8 in node-webkit?
For node alone, "node --harmony" does it, but "node-webkit --harmony" does not do anything.

@jadonk

I think you can do it from the command-line, rather than overriding in the autogenerated Makefiles. My current problem is that I don't have a valid 32-bit toolchain. I just installed the Xcode command-line tools as I am currently using a gentoo-prefix built gcc.

jason@timbird ~/beaglebone-getting-started/app/node_modules/mdns $ nw-gyp configure --target=0.3.6 -target_arch=ia32
gyp info it worked if it ends with ok
gyp info using nw-gyp@0.7.3-3
gyp info using node@0.8.15 | darwin | x64
gyp info spawn python
gyp info spawn args [ '/Users/jason/.nw-gyp/0.3.6/tools/gyp/gyp',
gyp info spawn args 'binding.gyp',
gyp info spawn args '-f',
gyp info spawn args 'make',
gyp info spawn args '-I',
gyp info spawn args '/Users/jason/beaglebone-getting-started/app/node_modules/mdns/build/config.gypi',
gyp info spawn args '-I',
gyp info spawn args '/Users/jason/gentoo/usr/lib/node_modules/nw-gyp/addon.gypi',
gyp info spawn args '-I',
gyp info spawn args '/Users/jason/.nw-gyp/0.3.6/common.gypi',
gyp info spawn args '-Dlibrary=shared_library',
gyp info spawn args '-Dvisibility=default',
gyp info spawn args '-Dnode_root_dir=/Users/jason/.nw-gyp/0.3.6',
gyp info spawn args '-Dmodule_root_dir=/Users/jason/beaglebone-getting-started/app/node_modules/mdns',
gyp info spawn args '--depth=.',
gyp info spawn args '--generator-output',
gyp info spawn args 'build',
gyp info spawn args '-Goutput_dir=.' ]
gyp info ok
jason@timbird ~/beaglebone-getting-started/app/node_modules/mdns $ nw-gyp build
gyp info it worked if it ends with ok
gyp info using nw-gyp@0.7.3-3
gyp info using node@0.8.15 | darwin | x64
gyp info spawn make
gyp info spawn args [ 'BUILDTYPE=Release', '-C', 'build' ]
make: Entering directory /Users/jason/beaglebone-getting-started/app/node_modules/mdns/build'
CXX(target) Release/obj.target/dns_sd_bindings/src/dns_sd.o
g++:
-arch i386' does not match current compiler arch x86_64'
make: *** [Release/obj.target/dns_sd_bindings/src/dns_sd.o] Error 1
make: Leaving directory
/Users/jason/beaglebone-getting-started/app/node_modules/mdns/build'
gyp ERR! build error
gyp ERR! stack Error: make failed with exit code: 2
gyp ERR! stack at ChildProcess.onExit (/Users/jason/gentoo/usr/lib/node_modules/nw-gyp/lib/build.js:232:23)
gyp ERR! stack at ChildProcess.EventEmitter.emit (events.js:99:17)
gyp ERR! stack at Process.ChildProcess._handle.onexit (child_process.js:678:10)
gyp ERR! System Darwin 12.2.0
gyp ERR! command "node" "/Users/jason/gentoo/usr/bin/nw-gyp" "build"
gyp ERR! cwd /Users/jason/beaglebone-getting-started/app/node_modules/mdns
gyp ERR! node -v v0.8.15
gyp ERR! nw-gyp -v v0.7.3-3
gyp ERR! not ok

@jadonk

I was able to build 32-bit binaries using the Xcode command-line tools, but I am still getting my original error that I thought was due to me building 64-bit binaires:

dlopen(/private/var/folders/m3/tgq8ljn171n8g4_7c117jhdh0000gn/T/.org.chromium.Chromium.EQsSoc/node_modules/mdns/build/Release/dns_sd_bindings.node, 1): no suitable image found. Did find:
/private/var/folders/m3/tgq8ljn171n8g4_7c117jhdh0000gn/T/.org.chromium.Chromium.EQsSoc/node_modules/mdns/build/Release/dns_sd_bindings.node: mach-o, but wrong architecture

timbird:mdns jason$ file build/Release/dns_sd_bindings.node
build/Release/dns_sd_bindings.node: Mach-O dynamically linked shared library i386

Here is how I built:

timbird:mdns jason$ npm install nw-gyp
npm WARN prefer global nw-gyp@0.7.3-3 should be installed with -g
nw-gyp@0.7.3-3 ./node_modules/nw-gyp
├── which@1.0.5
├── osenv@0.0.3
├── graceful-fs@1.1.14
├── rimraf@2.1.1
├── semver@1.1.1
├── mkdirp@0.3.4
├── request@2.9.203
├── nopt@2.0.0 (abbrev@1.0.3)
├── fstream@0.1.21 (inherits@1.0.0)
├── glob@3.1.14 (inherits@1.0.0)
├── npmlog@0.0.2 (ansi@0.1.2)
├── minimatch@0.2.9 (sigmund@1.0.0 lru-cache@2.0.4)
└── tar@0.1.14

timbird:mdns jason$ file node_modules/nw-gyp/bin/nw-gyp.js
node_modules/nw-gyp/bin/nw-gyp.js: a node script text executable
timbird:mdns jason$ node_modules/nw-gyp/bin/nw-gyp.js configure --target=0.3.6 -target_arch=ia32
gyp info it worked if it ends with ok
gyp info using nw-gyp@0.7.3-3
gyp info using node@0.6.5 | darwin | x64
gyp info spawn python
gyp info spawn args [ '/Users/jason/.nw-gyp/0.3.6/tools/gyp/gyp',
gyp info spawn args 'binding.gyp',
gyp info spawn args '-f',
gyp info spawn args 'make',
gyp info spawn args '-I',
gyp info spawn args '/Users/jason/beaglebone-getting-started/app/node_modules/mdns/build/config.gypi',
gyp info spawn args '-I',
gyp info spawn args '/Users/jason/beaglebone-getting-started/app/node_modules/mdns/node_modules/nw-gyp/addon.gypi',
gyp info spawn args '-I',
gyp info spawn args '/Users/jason/.nw-gyp/0.3.6/common.gypi',
gyp info spawn args '-Dlibrary=shared_library',
gyp info spawn args '-Dvisibility=default',
gyp info spawn args '-Dnode_root_dir=/Users/jason/.nw-gyp/0.3.6',
gyp info spawn args '-Dmodule_root_dir=/Users/jason/beaglebone-getting-started/app/node_modules/mdns',
gyp info spawn args '--depth=.',
gyp info spawn args '--generator-output',
gyp info spawn args 'build',
gyp info spawn args '-Goutput_dir=.' ]
gyp info ok
timbird:mdns jason$ node_modules/nw-gyp/bin/nw-gyp.js build
gyp info it worked if it ends with ok
gyp info using nw-gyp@0.7.3-3
gyp info using node@0.6.5 | darwin | x64
gyp info spawn make
gyp info spawn args [ 'BUILDTYPE=Release', '-C', 'build' ]
CXX(target) Release/obj.target/dns_sd_bindings/src/dns_sd.o
CXX(target) Release/obj.target/dns_sd_bindings/src/dns_service_browse.o
CXX(target) Release/obj.target/dns_sd_bindings/src/dns_service_enumerate_domains.o
CXX(target) Release/obj.target/dns_sd_bindings/src/dns_service_get_addr_info.o
CXX(target) Release/obj.target/dns_sd_bindings/src/dns_service_process_result.o
CXX(target) Release/obj.target/dns_sd_bindings/src/dns_service_ref.o
CXX(target) Release/obj.target/dns_sd_bindings/src/dns_service_ref_deallocate.o
CXX(target) Release/obj.target/dns_sd_bindings/src/dns_service_ref_sock_fd.o
CXX(target) Release/obj.target/dns_sd_bindings/src/dns_service_register.o
CXX(target) Release/obj.target/dns_sd_bindings/src/dns_service_resolve.o
CXX(target) Release/obj.target/dns_sd_bindings/src/mdns_utils.o
CXX(target) Release/obj.target/dns_sd_bindings/src/txt_record_ref.o
CXX(target) Release/obj.target/dns_sd_bindings/src/txt_record_create.o
CXX(target) Release/obj.target/dns_sd_bindings/src/txt_record_deallocate.o
CXX(target) Release/obj.target/dns_sd_bindings/src/txt_record_set_value.o
CXX(target) Release/obj.target/dns_sd_bindings/src/txt_record_get_length.o
CXX(target) Release/obj.target/dns_sd_bindings/src/txt_record_buffer_to_object.o
SOLINK_MODULE(target) Release/dns_sd_bindings.node
SOLINK_MODULE(target) Release/dns_sd_bindings.node: Finished
gyp info ok
timbird:mdns jason$ file build/Release/dns_sd_bindings.node
build/Release/dns_sd_bindings.node: Mach-O dynamically linked shared library i386

@jadonk

Nevermind, I was silly. I forgot to rebuild the .zip! Seems there are still a few more modules I need to rebuild and our original request for a 64-bit version of node-webkit still stands. :)

@Mithgol

@mblinsitu

Side question: do you or anybody know if it is possible to enable the Harmony features of V8 in node-webkit?
For node alone, node --harmony does it, but node-webkit --harmony does not do anything.

You really should create a new issue for this feature request.

@heavyk

so, after a while spinning my wheels a bit, it appears that this is actually a chrome limitation:

https://code.google.com/p/chromium/issues/detail?id=18323

since the issue has existed since 2009 and no clear progress has been made since 2010, it doesn't appear to be something we'll see happen any time soon...

@jiyinyiyong

I still suspect the 32bit may have unpredictable problem on a 64bit OS.
Want a 64bit package +1

@rogerwang
nwjs member

@jiyinyiyong it shouldn't have problem on 64bit OS. I read your original report on node-gyp in #1088 , but you should use nw-gyp instead for node-webkit.

@tlammens

A 64-bit package is actually necessary for running 64-bit plugins (for example the VLC plugin which doesn't seem to support 32-bit anymore on OS X.)

There were already successful attempts to compile a 64-bit version
https://groups.google.com/forum/#!topic/node-webkit/YsRduA0X_qg

Only a small patch is necessary for Google's protocol buffers:
https://code.google.com/p/protobuf/issues/attachmentText?id=412&aid=4120000000&name=mac-64.patch&token=-XG3a-3k2CsNhWdktFMBZOiYR4g%3A1384377212643

@trevorlinton

If anyone wants to try out the 64-bit MacOSX/Windows version you can find a build of 0.8.1 here:

http://www.trueinteractions.com/tint_preview_x64.zip

This was referenced Dec 2, 2013
@tojocky

seems is working fine for me. Could you please provide the instruction how to build on 64-bit?

@sarangsapre

On Mac OSX -
We have application using node-webkit. This needs to interact with some native libraries through ffi. The native library was written in C and built for x86_64 architecture.

This doesn't work because backend library is 64 bit and node-webkit is 32 bit.

As per above discussions following are the options
1. Rebuild Native/C library for 32 bit. - NOT possible.It has matlab dependency which supports only 64-bit libraries.
2. Rebuild specific version of node-webkit for 64 bit on OSX - Seems to have some success by other users long ago. Does it still work? Are there any clear instructions on what to do? I'm using nw 0.8.5 .
3. Wait for official support for Mac OSX 64 bit. Is it even planned? If so, when is it expected? If no, are there any specific reasons why this is not possible?

@jokeyrhyme

@sarangsapre have you looked at https://github.com/atom/atom-shell ? I think it might have 64-bit OSX support.

@rogerwang
nwjs member

Yeah we plan to support it soon since upstream supports it now.

@rogerwang rogerwang closed this Jul 29, 2014
@jokeyrhyme

Great work!

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