Meteor: [Meteor 1.3-rc.3] - Error when building for os.linux.x86_64

[clayne11]

_2 Upvotes_ When I try to build my app for os.linux.x86_64 I get the following error:

Errors prevented bundling:
While linking the program:
error: this app is not compatible with architecture 'os.linux.x86_64'

This was working fine in Meteor 1.2, and after making the minimal changes required to build in Meteor 1.3 I get this error and cannot build / deploy my app.

[clayne11]

This exact same app was also building fine under beta 12.

[skirunman]

Not sure if this helps, but I was getting a similar error message on upgrade to meteor-1.3.rc-3. I had to delete my app node_modules directory and run npm install again and then the build completed. You may also try doing meteor reset and remove the .meteor/local directory before building.

[clayne11]

You can't just remove the .meteor directory can you? It contains information about what packages are included in the app and their versions as well. Did you mean .meteor/local? I've tried both deleting node_modules and .meteor/local and neither of those fixed the issue I'm seeing.

[skirunman]

Edited my comment to .meteor/local

[tmeasday]

I've seen a similar issue when including (unused by the app) binary packages in node_modules/. For example:

meteor --release 1.3-rc.3 create deploy-test
cd deploy-test
meteor npm install
DEPLOY_HOSTNAME=galaxy ... 

Works.

If you then run:

# a development dependency, clearly not used by the app
meteor npm install chimp
DEPLOY_HOSTNAME=galaxy ... 

You will see:

error: this app is not compatible with architecture 'os.linux.x86_64'

@benjamn it sounds to me like a fix for #6118 would be causing this. Did you end up doing that and not closing the issue? If so, then this is an issue for the guide where we recommend using chimp in this way. I _could_ fall back to recommending you npm install -g it however.

[clayne11]

I do use chimp for end-to-end tests but obviously just as a dev dependency.

[clayne11]

I can confirm that removing chimp from my devDependencies allows me to build and deploy my app.

[benjamn]

Yes, now that I think about it, 26e3cd7df26dfbfac2f752919023ac310fabe8cf likely made incompatible binary dependencies in local node_modules directories fail at deploy time, due to this code.

Though it may be obvious to us humans when a dependency is not used in production, I'm afraid there's not a reliable way for meteor deploy to make that distinction. The dev dependency is still there in your node_modules directory, and it gets deployed along with everything else, so it might be used in production for all the portability checking logic can say.

If you want to keep installing npm packages with binary dependencies in node_modules, and you don't want to run npm install on a machine matching the production architecture, I suppose the only answers here are to

1. make the error dynamic, so you can get away with incompatible binary packages that are never used in production,
2. give the developer some way to specify which binary packages are unused, or
3. make the production machine run npm install if the portability check fails.

[clayne11]

What's the advantage of not running npm install on the production machine?

[benjamn]

@clayne11 It might be slow, but that's the only real objection I can think of. I think that's my preferred solution at this point.

[clayne11]

Jumping through a bunch of hoops and doing meteor specific stuff just to save a couple minutes at deploy time is not worth it at all IMO. I'm all for running npm install on the production machine if that's the case.

[benjamn]

A proper fix for this issue could pave the way for upgrading Node more easily.

[clayne11]

When I remove chimp and delete my node_modules folder, then when I run npm install Meteor does not build fibers and my app won't start up. When I re-install chimp, it seems to build fibers and then my app will start.

Same issue when I deploy. Missing fibers.

[clayne11]

I've tried installing fibers on it's own and that isn't working either. Installing chimp as a dev dependency definitely does work, but I'm not sure why.

[tmeasday]

@clayne11 likely because chimp has a dependency on fibers.

You are supposed to run npm install inside the programs/server directory in the application bundle. Are you doing that?

[clayne11]

I'm using mupx to deploy. I'm pretty sure it's doing that - everything deploys fine on Meteor 1.2.

Additionally, this is happening even on my development machine - I get the infamous Exited with code: 1. Even installing fibers using meteor npm install fibers doesn't fix the issue. When I install chimp, though, all is well.

[tmeasday]

@benjamn

make the production machine run npm install if the portability check fails.

I'm guessing we are going to have to figure out a solution of this form as part of the "figure out how to do binary packages in NPM thing" anyway, no?

I guess for now I should duck the issue by not recommending people locally install chimp; instead telling them to npm install --global it.

---

I think this is a problem we'll see biting people pretty regularly. If you have random gunk in your node_modules/ dir (highly possible) then it can get you even if you have a package.json that is binary-free. @zol / @rohit2b I think we should probably consider updating some Galaxy docs to cover this error.

Basically something like:

If you see this app is not compatible with architecture 'os.linux.x86_64' when deploying, you may have binary NPM dependencies.
Ensure you've removed them from your package.json, and then run meteor npm prune to remove them from your node_modules directory.

I guess people can work around it on galaxy with the METEOR_BINARY_DEP_WORKAROUND? I'll investigate.

Update:

METEOR_BINARY_DEP_WORKAROUND does not resolve this issue on Galaxy.

[tmeasday]

Additionally, this is happening even on my local machine - I get the infamous Exited with code: 1. Even installing fibers using meteor npm install fibers doesn't fix the issue. When I install chimp, though, all is well.

How are you making it happen locally? Are you bundling and then running from the app bundle?

[clayne11]

I mean I can't even run the app in development mode using meteor - I get Exited with code: 1. It's not just an issue with deploying.

[tmeasday]

@clayne11 and all you've done is rm -r node_modules inside the app's directory? That seems strange -- or doubtful that it's fibers anyway.

Can you post the steps that you've followed (if you can remember them?)

[clayne11]

To start, let me reiterate that everything works fine in Meteor 1.2. I've been using chimp for a few months so that's been one of my npm devDependencies since 1.2 came out.

When I upgraded to 1.3-rc.3, I created this thread because I could no longer deploy. I found out that I had to remove chimp because it has binary dependencies.

I removed chimp, which allowed me to build the app using meteor build. But then my deploy failed because Meteor required node v0.10.43. That change was then reverted in 1.3-rc.4.

I upgraded to 1.3-rc.4 and once again tried to deploy using mupx. When my deployment failed, I went back to my dev workspace (which is a separate folder from my deployment workspace), I cleaned everything by doing rm -rf node_modules && rm -rf .meteor/local.

Then after doing npm install I tried to run my app with meteor. It was failing to start.

I reinstalled chimp, and everything was happy. I noticed the fibers dependency and thought that might be the issue. I uninstalled chimp and installed fibers. Still not able to run. Uninstalled fibers and reinstalled chimp - everything works as expected.

I then went back to my 1.3-rc.3 commit and tried building (without chimp). Same issue. My app will not start. Installed chimp, and everything is happy.

Installing fibers does NOT seem to fix the issue.

[tmeasday]

@clayne11 your development machine is ubuntu?

[clayne11]

No it is a mac running 10.11.3.

[tmeasday]

Can you try something like:

cd /tmp
git clone https://github.com/meteor/todos
cd todos
npm install --production
meteor

If you see an issue there can you perhaps open a new ticket as it sounds like a slightly different ticket to the original one of not being able to deploy? Thanks

[danlg]

same issue confirmed on 1.3-rc.4 on todos application running on my Mac

 meteor build ./out --architecture=os.linux.x86_64 --server=my.ip:3000

Errors prevented bundling:                    
While processing files with templating (for target web.browser):
out/bundle/programs/web.browser/head.html:1: Expected one of: <body>, <head>, <template>
While linking the program:
error: this app is not compatible with architecture 'os.linux.x86_64'

This means basically there is no fix for #6525. I want to avoid at all cost doing a partial build on 1 machine (mac) and npm install on another one (Ubuntu= stage/production). This is really not clean. Doing cross platform build with ABI compatibility is super important.

[tmeasday]

@danlg

1. I think maybe set the output directory outside of the meteor app? Not sure if that error on line three is stopping the build or not.
2. If not, check your node_modules/ -- is there a binary dependency in there?
3. You will need to npm install to get fibers on the server. I'm pretty sure this will be case in 1.3 no matter what.

[tmeasday]

For step 2., try npm prune to cleanup extraneous dependencies. If you still get the binary issue, perhaps post your dependencies from package.json here.

[danlg]

@tmeasday same error with output directory outside the app and cleaning before

rm -rf .meteor/local/
meteor build ../out --architecture=os.linux.x86_64 --server=my.ip:3000

Regarding your request no dependencies file on my mac and package.json

cat ./.meteor/local/build_tar/bundle/programs/server/package.json
{
  "name": "meteor-dev-bundle",
  "version": "0.0.0",
  "dependencies": {
    "fibers": "1.0.8",
    "meteor-promise": "0.5.1",
    "underscore": "1.5.2",
    "source-map-support": "https://github.com/meteor/node-source-map-support/tarball/1912478769d76e5df4c365e147f25896aee6375e",
    "semver": "4.1.0"
  },
  "devDependencies": {
    "eachline": "https://github.com/meteor/node-eachline/tarball/ff89722ff94e6b6a08652bf5f44c8fffea8a21da",
    "chalk": "0.5.1"
  }
}

Besides, why would we need to have npm install if the --architecture=os.linux.x86_64 works? Isn't it supposed to build the full tarball for this architecture...this is really annoying.

Fighting with deployment issue for a couple of days (whereas Meteor is supposed to ease the life of developer) breaks the simplicity promise and shows that MDG makes it very difficult for independent developer to use 3rd party production hosting to push Galaxy $$ ;-( : very little docs on deployment http://guide.meteor.com/deployment.html#custom-deployment doesn't say anything about native deployment binaries, lack of deploy tool supporting third-party cloud supported by MDG proves it (i.e. mup-like should be supported by MDG). I believe my request is not a fancy feature and a Must-have otherwise the platform is not in business.

Basically, the productivity promise is broken. A fix is required asap or you can say goodbye to a customer ;-( and count me as detractor in your NPS index...

[tmeasday]

So I guess the question here is: why do you have that set of dependencies in package.json? They look like a bunch of node modules will end up being included by Meteor core packages (and which will sidestep this binary issue). Did you place them there because you are using them directly in your app, or was it an attempt to deal with the earlier issue? (If the latter, I'd try simply getting rid of them).

Fighting with deployment issue for a couple of days breaks the simplicity promise

In our defence you are using a pre-release version of Meteor with a 3rd party hosting tool.

We are literally just discovering this binary issue in the last few days--I just recently updated that section of the guide for the 1.3 release to emphasize the --architecture flag: http://guide.meteor.com/v1.3/deployment.html#custom-deployment

MDG makes it very difficult for independent developer to use 3rd party production hosting to push Galaxy $$

I don't think it's fair to complain about an "issue" (the need to npm install for on the server) that has literally been there since the first version of Meteor as being an attempt to push Galaxy! And this binary issue is new in 1.3, as I've stated above.

PS I agree that providing the --architecture flag should ideally remove the need for install step on the server, although I'm not sure it's possible, given fibers requires compilation.

If you are concerned about creating a self-contained tarball, I'd suggest bundling on the same architecture that you plan to deploy to, opening the bundle, running npm install, and then re-bundling. This is an approach that has been successful for me in the past.

[danlg]

Why should we do npm install when we are supposed to have isobuild? I quote https://www.meteor.com/isobuild:

The output of Isobuild is a set of runnable programs. For example, one simple Isobuild project could build into:
(..)
A Unix daemon that provides the app's trusted server-side services, in the form of a ready-to-run tarball, targeting a particular machine type such as Linux on 64-bit Intel. The point of Isobuild is to simplify the process of building modern applications: applications that run multiple processes (such as clients and servers) in multiple environments (such as browsers, mobile devices, and node.js under Unix).

From that we can see the gap between the marketing and the reality. This isobuild "feature" is misleading at best. This gap may not be new in 1.3 but it gets worse as there is no *_upgrade path to production *_from 1.2 and the promise broken. The reason: mup/mupx is broken since it is not supported by MDG and isobuild is not more than a prophecy.

I was super hopeful and enthusiatic about 1.3 but I have to say I'm disappointed now.

PS: I have managed in the end to deploy todo app by building it on the server Ubuntu and npm install but I find it really not productive as all the continuous deployment script are now broken. Why can't I build it on my dev mac and deploy it on Ubuntu in a simple manner ??

[danlg]

My Linux box config:

root@dolgdev2:/var/log/upstart# which npm 
/root/.nvm/v0.10.43/bin/npm
root@dolgdev2:/var/log/upstart# npm -v
3.8.2
root@dolgdev2:/var/log/upstart# node -v
v0.10.43

Build on Linux above and npm install. I managed to run it:

root@dolgdev2:/opt/todolinux/app# file /opt/todolinux/app/programs/server/npm/node_modules/meteor/npm-bcrypt/node_modules/bcrypt/build/Release/obj.target/bcrypt_lib.node
/opt/todolinux/app/programs/server/npm/node_modules/meteor/npm-bcrypt/node_modules/bcrypt/build/Release/obj.target/bcrypt_lib.node: **ELF 64-bit LSB  shared object**, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=3ef4da11e93535067b796ca5e66feb65a3d18062, not stripped

Build not working on Linux from a Mac build machine using --architecture os.linux.x86_64
build on Mac above using --architecture os.linux.x86_64 and scp the archive and npm install. Error complaining about bcrypt_lib.node: invalid ELF header:

root@dolgdev2:/opt/todolinux/app# file  /opt/stodos-1-3/app/programs/server/npm/node_modules/meteor/npm-bcrypt/node_modules/bcrypt/build/Release/bcrypt_lib.node
/opt/stodos-1-3/app/programs/server/npm/node_modules/meteor/npm-bcrypt/node_modules/bcrypt/build/Release/bcrypt_lib.node: **Mach-O** 64-bit x86_64 bundle

[pors]

@danlg I have exactly the same issue. I decided to run mup from a linux virtual box. That works :)

[danlg]

@pors I tried to compile on Ubuntu with mup. but I get endless babel message when I run with DEBUG=* mup deploy. Compile time is super long (looks like it goes into an infinite loop). Removing the DEBUG removes the statements output but the build hangs (so it just seems to hide it).

However, on Ubuntu, meteor build --architecture os.linux.x86_64 followed by npm install seems to work...

Mon, 21 Mar 2016 21:53:13 GMT babel program.body[7].expression.arguments[1].properties[8].value.callee.body.body[0].body.body[1].expression.arguments[0].body.body[1].expression.arguments[0].arguments[0].body.body[0].body.body[7].expression.arguments[0].body.body[1].expression.arguments[3].arguments[0].body.body[0].block.body[0].alternate.test.left.left.argument.property Identifier: Recursing into...

[danlg]

@pors I have found a workaround by modifying mup to allow architecture os.linux.x86_64 https://github.com/danlg/meteor-up.git to build on my mac and install it globally. And then run mup deploy as usual on my mac. So this issue of building for linux.x86_64 is fixed for me.

Web version is working ok but Cordova hot code push is broken for now. To be more specific I get on iOS 9 using force-ssl and https. The ATS security setting were working before the upgrade to 1.3 (the app is in production with 1.2.1).
Failed to load resource: An SSL error has occurred and a secure connection to the server cannot be made https://mydomain.com/sockjs/info.js?cb=xxxx

@pors Did you manage to get a Cordova client working or are just on the web?

[tmeasday]

@danlg I think you'll need to update your app to get the new Cordova version (http://guide.meteor.com/v1.3/1.3-migration.html#breaking-changes-mobile)

@martijnwalraven is this correct? Do we need to update that documentation a little to explain this?

[danlg]

@tmeasday @martijnwalraven Thanks for the tip. But how do I upgrade Cordova ( I have upgraded meteor obviously but I understand from the doc that the the latest Cordova version was embedded in 1.3). I have explicitly upgraded the Cordova _plugins_ though (but not the core Cordova unless this is done as part of the meteor update --release 1.3 process)

PS: I've described above more specifically the error.

[martijnwalraven]

@danlg: That indeed seems like an issue with App Transport Security.

Earlier versions of Cordova disabled ATS entirely (setting NSAllowsArbitraryLoads). But the latest versions use the existing access rules to allow HTTP for specific domains (setting NSExceptionAllowsInsecureHTTPLoads for those domains). They still need to meet the default ATS requirements for SSL however (which means using TLS v1.2 and supporting forward secrecy).

Since you have control over your server, you may want to upgrade your SSL connection to meet these requirements (Apple's point in making these the default in ATS is that anything less wouldn't be fully secure).

It also seems Cordova has recently added new access options specifically to weaken these requirements (minimum-tls-version and requires-forward-secrecy), so we should also add these to our App.accessRule options. I'll open an issue for this.

[danlg]

@martijnwalraven My server is already with TLS 1.2 in UAT and prod with meteor 1.2. I'm trying --hard -- to upgrade my UAT to Meteor 1.3. Would you consider this release to be production ready for Cordova clients or advise to wait until later ? I cannot drop SSL on my prod app and this is breaking change for my app... Any workaround ? thanks

[martijnwalraven]

If this is just a temporary workaround for a production build, I would suggest editing Info.plist directly (can also be done by opening the Xcode project in the build directory).

Is there any way you can enable support for forward secrecy on your servers? If you're already on TLS v1.2, that should be the only change required to meet the default ATS requirements.

[pors]

@danlg It also works on mobile (tried iOS only). My back-end is over SSL.

[payner35]

I'm a little lost on this one as well..

can't seem to deploy to Galaxy due to this error..

Deploying your app...

Errors prevented deploying:
While linking the program:
error: this app is not compatible with architecture 'os.linux.x86_64'

[tmeasday]

@payner35 Can you try

npm prune
# deploy again

If that doesn't help, perhaps post what dependencies you have in your package.json?

[payner35]

NPM prune does not seem to work for me

{
  "name": "myApp",
  "version": "1.0.0",
  "description": "",
  "scripts": {
    "lint": "eslint ./libs ./client ./server --ext .js --ext .jsx",
    "lintfix": "npm run lint -- --fix",
    "test": "npm run lint",
    "galaxy": "DEPLOY_HOSTNAME=galaxy.meteor.com meteor deploy --settings settings.json www.myApp.com",
    "ios": "sh mobileStartUp.sh"
  },
  "devDependencies": {
    "babel-core": "6.x.x",
    "babel-plugin-react-require": "2.x.x",
    "babel-polyfill": "6.x.x",
    "babel-preset-es2015": "6.x.x",
    "babel-preset-react": "6.x.x",
    "babel-preset-stage-2": "6.x.x",
    "babel-root-slash-import": "1.x.x",
    "eslint": "1.10.x",
    "eslint-plugin-react": "3.14.x",
    "react-addons-test-utils": "^0.14.6"
  },
  "dependencies": {
    "classnames": "^2.2.3",
    "domready": "^1.0.8",
    "google-map-react": "^0.10.1",
    "load-script": "^1.0.0",
    "mantra-core": "^1.2.0",
    "material-ui": "v0.15.0-alpha.1",
    "react": "^0.14.6",
    "react-addons-css-transition-group": "^0.14.7",
    "react-addons-shallow-compare": "^0.14.7",
    "react-coverflow": "^0.1.12",
    "react-dom": "^0.14.6",
    "react-headroom": "^1.7.3",
    "react-image-gallery": "^0.5.11",
    "react-image-responsive": "^1.0.18",
    "react-lazy-load": "^3.0.5",
    "react-motion": "^0.3.1",
    "react-mounter": "^1.0.0",
    "react-notification": "^4.2.0",
    "react-quill": "^0.4.1",
    "react-selectize": "^0.8.1",
    "react-sticky": "^3.0.0",
    "react-swipeable-views": "^0.3.6",
    "react-tap-event-plugin": "^0.2.1",
    "react-waypoint": "^1.3.0"
  },
  "private": true
}

[RWizard]

+1 after upgrade to 1.3-rc.10
error: this app is not compatible with architecture 'os.linux.x86_64'

[payner35]

Im assuming some people can deploy to Galaxy right? (i have checked again with 1.3)

making this an issue with one of my NPM packages?

[tmeasday]

@payner35 it's your react-coverflow dependency. It ends up depending on fsevents which is a binary package. Not sure why.

[payner35]

Thanks @tmeasday .. i removed.. meteor reset.. and pruned

Still have the same error. Must be an additional package with the same issue. How do i spot a binary dependency? what should i be looking for?

Thanks

[tmeasday]

Search for files named .node inside node_modules. It's definitely the fsevents module, I guess there's a second dependency on it...

[benwalks]

I'm getting this as well on 1.3 deploying to Galaxy.

"dependencies": {
"cloudinary": "^1.3.0",
"fibers": "^1.0.10",
"meteor-node-stubs": "^0.2.1",
"moment": "^2.12.0",
"moment-recur": "^1.0.5",
"react": "^0.14.7",
"react-addons-pure-render-mixin": "^0.14.7",
"react-bootstrap": "^0.28.3",
"react-bootstrap-datetimepicker": "0.0.22",
"react-dom": "^0.14.7",
"react-komposer": "^1.4.1",
"react-mounter": "^1.1.0"
}

Edit:

I had installed wkhtmltopdf which does include binaries via meteor install but removing the package, deleting .meteor/local, deleting npm_modules didn't solve the problem. I ended up rolling back to before installing the package (and therefore back onto 1.3 RC 2) and it's now working, as you'd expect. I'll upgrade to 1.3 again today and re-test.

[tmeasday]

@benwalks - I would expect that fibers includes a binary dependency too?

[benwalks]

Hmmm, I'm 99% sure I tried deleting fibers from my list and retrying.

I just checked and I have fibers as a dependency in 1.3 RC.2 and it's uploading fine to Galaxy. Not sure mate. I haven't had a chance to retry again with 1.3 today, I'll keep you posted.

[payner35]

i can confirm that the package "react-image-responsive": "^1.0.18", was using fsevents as well.

have removed and my app deploys to galaxy.

i had to search the code for reference to fsevents to catch its use.

Big thanks @tmeasday ... this was starting to get the better of me ;)

[tmeasday]

Glad you figured it out @payner35. I think we need to do something to help with this (likely npm installing on the server?)

[crapthings]

meteor 1.3.0

While linking the program:
error: this app is not compatible with architecture 'os.linux.x86_64'

{
  "name": "cube",
  "version": "1.0.0",
  "main": "server/main.js",
  "browser": "client/main.js",
  "options": {
    "mocha": "--require .scripts/mocha_runner client/**/tests/**/*.js"
  },
  "scripts": {
    "lint": "eslint ./libs ./client ./server --ext .js --ext .jsx",
    "lintfix": "npm run lint -- --fix",
    "testonly": "mocha $npm_package_options_mocha",
    "test": "npm run lint && npm run testonly"
  },
  "devDependencies": {
    "babel": "^6.3.26",
    "babel-core": "6.x.x",
    "babel-eslint": "^4.1.8",
    "babel-loader": "^6.2.0",
    "babel-plugin-add-module-exports": "^0.1.2",
    "babel-plugin-react-require": "2.x.x",
    "babel-plugin-react-transform": "^2.0.0",
    "babel-plugin-transform-class-properties": "^6.4.0",
    "babel-plugin-transform-decorators-legacy": "^1.3.2",
    "babel-polyfill": "6.x.x",
    "babel-preset-es2015": "6.x.x",
    "babel-preset-react": "6.x.x",
    "babel-preset-stage-0": "^6.3.13",
    "babel-preset-stage-2": "6.x.x",
    "chai": "3.x.x",
    "css-loader": "^0.23.0",
    "enzyme": "1.x.x",
    "eslint": "1.10.x",
    "eslint-config-airbnb": "^3.1.0",
    "eslint-plugin-react": "3.15.x",
    "expose-loader": "^0.7.1",
    "extract-text-webpack-plugin": "^0.9.1",
    "faker": "^3.1.0",
    "file-loader": "^0.8.5",
    "less": "^2.6.0",
    "less-loader": "^2.2.2",
    "lodash._basefor": "^3.0.3",
    "lodash._bindcallback": "^3.0.1",
    "lodash._isiterateecall": "^3.0.9",
    "lodash.isarguments": "^3.0.8",
    "lodash.keysin": "^4.1.3",
    "lodash.restparam": "^3.6.1",
    "mocha": "2.x.x",
    "my-ip": "^1.1.1",
    "react-addons-test-utils": ">=0.14.3 <=0.15.0",
    "react-transform-catch-errors": "^1.0.0",
    "react-transform-hmr": "^1.0.1",
    "redbox-react": "^1.2.0",
    "sinon": "^1.17.3",
    "style-loader": "^0.13.0",
    "url-loader": "^0.5.7",
    "webpack": "^1.12.9",
    "webpack-hot-middleware": "^2.4.1"
  },
  "dependencies": {
    "bowser": "^1.0.0",
    "cal-heatmap": "^3.5.4",
    "d3": "^3.5.16",
    "d3-circle": "^1.0.0",
    "domready": "^1.0.8",
    "fastclick": "^1.0.6",
    "highcharts": "^4.2.1",
    "js-cookie": "^2.1.0",
    "lodash": "^4.6.1",
    "material-ui": "^0.14.2",
    "moment": "^2.11.1",
    "nprogress": "^0.2.0",
    "react": "0.14.x",
    "react-addons-pure-render-mixin": "^0.14.6",
    "react-dom": "0.14.x",
    "react-komposer": "1.x.x",
    "react-modal": "^0.6.1",
    "react-motion": "^0.3.1",
    "react-mounter": "1.x.x",
    "react-simple-di": "1.x.x",
    "react-swipeable-views": "^0.3.6",
    "react-tap-event-plugin": "^0.2.1",
    "sweetalert": "^1.1.3",
    "warning": "^2.1.0"
  },
  "private": true
}

[sferoze]

I have this issue to.

Its is due to fibers.

I added fibers by using meteor npm install --save fibers

But after I add fibers, I cannot deploy with MupX anymore.

It runs locally but when I try and deploy I get error:

Errors prevented bundling:
While linking the program:
error: this app is not compatible with architecture 'os.linux.x86_64'

[roark]

I'm also experiencing the same...
error: this app is not compatible with architecture 'os.linux.x86_64'

It would be beneficial if the error provided more information as to which NPM package or Meteor package has the binary dependency that is causing the issue. I know people are spending a lot of time trying to hunt down these binary dependencies.

As example, after much hunting I found that one of my many NPM packages had an:

"optionalDependencies": {
  "hiredis": "^0.4.1"
 },

To fix, I had to fork the package and remove the optionalDependencies... (not ideal).

However, that was only on a smaller project... On my main project I still see the not compatible with architecture error and no details on where the cause of the problem might be.

I love Meteor and I know you guys are swamped. But I'd say this should be very high on the priority list.

I've got my CC in Galaxy, ready to pay, but MDG isn't receiving any money yet. As I haven't been able to get anything running that is more complex than a simple skeleton app.

I've tried jumping through all the extra hoops... setting up a VirtualBox Ubuntu VM, trying to build packages for certain architectures (how to do with private packages?)... only to run into multitudes of other issues and forever build times.

I think recommending people avoid binary packages is the wrong direction and a dead end if we want Meteor to truly interact with the NPM universe.

Ultimately, the goal should be to support the ability to use binary dependencies, as well as simple deployment from OS X. (or any guest OS)

@tmeasday & @benjamn ... It sounds like you have the solution with npm installing on the server. If that easily satisfies the goal I mentioned above, than I say go for it!

[adrianmcli]

I'm having the same issue here. I even tried Modulus so I didn't have to use Mup. Same issue of course.

[rkstar]

if the solution is to build on the server, can someone provide an example or link to a tutorial on how exactly to deploy an app with this workaround?

this upgrade to 1.3 is supposed to be awesome but is being ruined by what seems to be a pretty big oversight.

please help!

[GatsbyBOS]

Any update on this??? we were using one of the RC and it was all working fine.. how come it's breaking in the actual release...

[roark]

I may not be the best person to provide an answer since I've still had some troubles myself. That said, I believe booting up a Linux VM and deploying from there can theoretically solve the problem.

However, the "solution" I was referencing was something the Meteor team should undertake. That is, having Galaxy do an NPM Install and build the isobuild on the their servers. Rather than how it appears to work now, building the isobuild on the development machine and then uploading it.

[benjamn]

Running meteor npm rebuild in the parent directory of the node_modules directory containing packages with binary packages appears to be a better solution than trying to run npm install. Note, however, that you may have to run meteor npm rebuild for more than one node_modules directory.

I would strongly recommend using meteor npm rather than just npm here, so that you're guaranteed to compile for the right architecture and Node/V8 versions.

I'm sure we can put a script in the meteor build bundle that does the right thing, and run that script from Galaxy.

[ericmcgregor]

will whatever solution you come up with for Galaxy also work with a mup or mupx deployment to ec2? as @danlg said, this issue really breaks the promise of productivity for me and very much caught me by surprise. I've been working for several days to try and get this working.

[rkstar]

sounds good @benjamn thank you!
some clarification though: which dir here do i need to run meteor npm rebuild in (in my dir below)?

$ find . -name "*.node"
./node_modules/webpack/node_modules/watchpack/node_modules/chokidar/node_modules/fsevents/lib/binding/Release/node-v11-darwin-x64/fse.node

... and can i run meteor npm rebuild on my local machine, or do i need to run that on the server in order to get a binary that will work on the server?

my apologies if these are things that should be obvious.

[benjamn]

@rkstar The meteor npm rebuild command is the same as npm rebuild, just with more reliable versions, so it's something you would need to run on the server that you're deploying to, probably right after you run meteor npm install in the bundle/programs/server/ directory.

This will definitely work:

cd ./node_modules/webpack/node_modules/watchpack/node_modules/chokidar/
meteor npm rebuild

I need to play with npm rebuild more to understand its behavior completely, but I think you might actually be able to run meteor npm rebuild in any of these directories:

./node_modules/webpack/node_modules/watchpack/node_modules/chokidar/
./node_modules/webpack/node_modules/watchpack/
./node_modules/webpack/
./

Try deleting fse.node node first if you want to verify the rebuild works.

[benjamn]

@ericmcgregor I'm pretty sure mup and mupx run npm install in bundle/programs/server/, so I'm tempted to put a post-install script in bundle/programs/server/package.json that rebuilds everything else at the same time. :smiling_imp:

[roark]

@benjamn Thanks for the updates... How can this be done with Galaxy?

[adrianmcli]

But what about something like Modulus where I don't use Mup at all and I don't really get to do much on the server side since it's a PaaS?

[benjamn]

@adrianmc if you're deploying Meteor apps built with meteor build, you must be running npm install in bundle/programs/server/, so the strategy I mentioned above should just work (once implemented in Meteor 1.3.2).

[benjamn]

This will be fixed in the next release! See the referencing commits above if you'd like to see how it's done.

[dgolds]

I am also having this issue with 1.3.1..

meteor build ../tmpBuild --architecture os.linux.x86_64
Errors prevented bundling:
While linking the program:
error: this app is not compatible with architecture 'os.linux.x86_64'

I have looked for .node files (there was one in the npm 'tern' package in a test folder, so i just deleted that .node file).

my package.json dependencies are:

"dependencies": {
    "babel-plugin-transform-class-properties": "^6.6.0",
    "blueimp-md5": "^2.3.0",
    "codemirror": "^5.13.4",
    "data-uri-to-buffer": "0.0.4",
    "history": "^2.0.1",
    "js-beautify": "^1.6.2",
    "moment": "^2.12.0",
    "react": "^15.0.0",
    "react-addons-create-fragment": "^15.0.1",
    "react-addons-css-transition-group": "^15.0.1",
    "react-addons-linked-state-mixin": "^15.0.1",
    "react-addons-perf": "^15.0.1",
    "react-addons-pure-render-mixin": "^15.0.1",
    "react-addons-test-utils": "^15.0.1",
    "react-addons-transition-group": "^15.0.1",
    "react-addons-update": "^15.0.1",
    "react-color": "^2.0.0",
    "react-dom": "^15.0.1",
    "react-helmet": "^3.0.1",
    "react-mixin": "^3.0.4",
    "react-router": "^2.0.1",
    "tern": "^0.18.0"
  },
  "devDependencies": {},

My meteor packages are:

# Meteor packages used by this project, one per line.
# Check this file (and the other files in this directory) into your repository.
#
# 'meteor add' and 'meteor remove' will edit this file for you,
# but you can also edit it by hand.

meteor-base             # Packages every Meteor app needs to have
mobile-experience       # Packages for a great mobile UX
mongo                   # The database Meteor supports right now
blaze-html-templates    # Compile .html files into Meteor Blaze views
session                 # Client-side reactive dictionary for your app
jquery                  # Helpful client-side library
tracker                 # Meteor's client-side reactive programming library

es5-shim                # ECMAScript 5 compatibility for older browsers.
ecmascript              # Enable ECMAScript2015+ syntax in app code

standard-minifier-css
standard-minifier-js

accounts-password

nimble:restivus         # REST API package
service-configuration
react-meteor-data
flemay:less-autoprefixer
babel-runtime

Any ideas? I'm getting no clues from the meteor command line even with --verbose.

[raphaelkross]

Hi! I'm also deploying from a Mac to an Ubuntu instance at Digital Ocean using mupx deploy. You can use the command:

find . -name "*.node"

To find the modules that are using binaries (in my case, node-sass) - then, uninstall the module (remove from package.json as well) and deploy again - now it works.

Waiting for an official fix! :)

Kindly,
Rafael

[hems]

find . -name "*.node" helped me loads to go further ( had to remove chimp from devDependencies ).

another issue i notice was that i had to remove "android" platform from my .meteor/platforms before deploying

after that problem the deploy happened, but i got a problem

Error: Can't find npm module 'lodash'. Did you forget to call 'Npm.depends' in package.js within the 'modules-runtime' package?

to solve that issue i entered my app folder and did a manual "npm install" before deploying, which solved that issue.

after that i have another issue which was related to using .env, for some reason the settings were not being loaded on the server ( as reported here: https://github.com/kadirahq/meteor-up/issues/96 ) so i had to manually copy my .env variables into my mup.json file.

EDIT: sorry i end up adding mupx related problems here, i thought i was on a mupx repo.

[benjamn]

Support for rebuilding binary dependencies as part of cd bundle/programs/server && npm install will be released with Meteor 1.3.2 this Friday. You can test it out by doing meteor update --release 1.3.2-rc.5, and then deploying an app to Galaxy or any other hosting service. Thanks for your feedback, everyone!

[rkstar]

i just tried to use mupx to deploy and got a slew of NEW errors! :(

it's worh noting that i'm using the webpack:webpack package with this app

here is a gist with my error log

[Batistleman]

When trying out 1.3.2-rc.5 I'm getting these errors when I try to run my app locally:

W20160413-13:24:26.377(2)? (STDERR)
W20160413-13:24:26.378(2)? (STDERR) /Users/batist/.meteor/packages/meteor-tool/.1.3.2-rc.5.984ztw++os.osx.x86_64+web.browser+web.cordova/mt-os.osx.x86_64/dev_bundle/server-lib/node_modules/fibers/future.js:267
W20160413-13:24:26.378(2)? (STDERR)                             throw(ex);
W20160413-13:24:26.378(2)? (STDERR)                                   ^
W20160413-13:24:26.392(2)? (STDERR) ReferenceError: meteorInstall is not defined
W20160413-13:24:26.392(2)? (STDERR)     at /Users/batist/Projects/antobase-instructions/app/.meteor/local/build/programs/server/packages/antobase_meteor-svg-editor.js:14:15
W20160413-13:24:26.392(2)? (STDERR)     at /Users/batist/Projects/antobase-instructions/app/.meteor/local/build/programs/server/packages/antobase_meteor-svg-editor.js:146:3
W20160413-13:24:26.392(2)? (STDERR)     at /Users/batist/Projects/antobase-instructions/app/.meteor/local/build/programs/server/boot.js:283:10
W20160413-13:24:26.392(2)? (STDERR)     at Array.forEach (native)
W20160413-13:24:26.392(2)? (STDERR)     at Function._.each._.forEach (/Users/batist/.meteor/packages/meteor-tool/.1.3.2-rc.5.984ztw++os.osx.x86_64+web.browser+web.cordova/mt-os.osx.x86_64/dev_bundle/server-lib/node_modules/underscore/underscore.js:79:11)
W20160413-13:24:26.392(2)? (STDERR)     at /Users/batist/Projects/antobase-instructions/app/.meteor/local/build/programs/server/boot.js:133:5

[Batistleman]

it seems to be a problem with a package... is there a minimum requirement for the API version?

I'm using
api.versionsFrom('1.2.0.1');

[Batistleman]

Adding

api.use('modules');

to the package.js file of my package fixes the error.

I should note I only have this problem with 1.3.2-rc.5, not with 1.3.0.

[benjamn]

@Batistleman is it the peerlibrary:util package?

[Batistleman]

No, it's my own package. These are the requirements:

api.use([
    'ecmascript',
    'session',
    'reactive-var',
    'jquery',
    '[email protected] || 2.5.0',
    'spacebars',
    '[email protected] || 2.5.0',
    'accounts-base',
    'underscore',
    'templating',
    'anti:i18n'
], 'client');

api.use([
    'cfs:standard-packages',
    'cfs:filesystem',
    'cfs:graphicsmagick',
    'cfs:s3',
    'matb33:collection-hooks',
    'percolate:paginated-subscription'
], ['client', 'server']);

api.versionsFrom('1.2.0.1');

[GroofyIT]

FYI
Had the same due to native building fibers package.
Just tested out with the fresh 1.3.2 release and worked like a charm.
(source Osx 10.11.3, target Ubuntu 14.04.4 x64

[benjamn]

Fixed in Meteor 1.3.2!

[crapthings]

good job! it works