i've replaced my DS212 (on ARM) by a new DS214Play (on Intel).
I tried to install MeteorJs using required command line by any user (admin) :
curl http://install.meteor.com | sh
Then it tells me that it's installed, but in fact meteor is not callable :
sh: meteor: not found
After install i get those files:
/volume1/homes/admin/.meteor/*
/usr/local/bin/meteor
[edit]
trying to install throught https://github.com/4commerce-technologies-AG/meteor and i get the following errors (make has been installed throught ipkg) :
Node.js configure error: No acceptable C compiler found!
Please make sure you have a C compiler installed on your system and/or
consider adjusting the CC environment variable if you installed
it in a non-standard prefix.
python ./configure
Node.js configure error: No acceptable C compiler found!
Please make sure you have a C compiler installed on your system and/or
consider adjusting the CC environment variable if you installed
it in a non-standard prefix.
python tools/gyp_node.py -f make
gyp: Undefined variable node_tag in /tmp/generate-dev-bundle-IKZIGinD/build/node/node.gyp
make: *** [out/Makefile] Error 1
Hi I am not sure if your architecture is supported by now with a pre-bundle.
You can try to check if our "universal" bundler will help you.
https://github.com/4commerce-technologies-AG/meteor
P.S.: Make sure to have node, npm and mongo natively installed on your system when using above.
P.P.S.: You also can try to checkout meteor directly from their repos, depends on architecture.
Related
I have cross compiled gRPC (v1.27.3) for QNX 7 (ARM) platform. I am using the protobuf which was already available for our system (QNX ARM v3.11.4).
I used following cmake command to build gRPC for compilation process
cmake -DCMAKE_CROSSCOMPILING=1 -DgRPC_BUILD_TESTS=OFF -DgRPC_PROTOBUF_PROVIDER=package -DgRPC_SSL_PROVIDER=package -DgRPC_ZLIB_PROVIDER=package -DOPENSSL_CRYPTO_LIBRARY=$QNX_TARGET/aarch64le/usr/lib/libcrypto.a -DOPENSSL_SSL_LIBRARY=$TARGET/aarch64le/usr/lib/libssl.a -DCMAKE_BUILD_TYPE=Release -DCMAKE_TOOLCHAIN_FILE=/tmp/qnxarm/toolchain.cmake -DCMAKE_INSTALL_PREFIX=/tmp/qnxarm/inst ../..
make plugins
make -j4
sudo make install
After compiling, I am able to see the binaries in /tmp/qnxarm/inst folder.
I copied those binaries in our code to compile the application for QNX.
While compiling I am getting this issue:
<local_directory>/grpc/aarch64/qnx/bin/grpc_cpp_plugin: program not found or is not executable
Please specify a program using absolute path or make sure the program is available in your PATH system variable
--grpc_out: protoc-gen-grpc: Plugin failed with status code 1.
lib/qmonitor/proto/CMakeFiles/QMonitorProto.dir/build.make:105: recipe for target 'lib/qmonitor/proto/QAicMonitorInternal.grpc.pb.cc' failed
make[2]: *** [lib/qmonitor/proto/QAicMonitorInternal.grpc.pb.cc] Error 1
Please help me to know what is wrong? or what should be done to solve this.
Do we need to add the PATH in gRPCTargets.cmake file which is generated in lib folder?
You've compiled the gRPC tools for your QNX ARM system -- so the version of grpc_cpp_plugin you made is expecting to be run on your QNX system, not your build host.
The usual approach for this sort of thing is to make a second copy of gRPC compiled for your build host, and then instruct your application build to link the libraries from the cross build, but call the grpc_cpp_plugin compiled for the build host.
I am building the Visual Studio Code from the source checked out from the git repository:
git clone https://github.com/microsoft/vscode
I am building using:
export NODE_OPTIONS=--max_old_space_size=2048
./scripts/npm.sh install --arch=armhf
./scripts/code.sh
I am using node 10.16.3 on a Raspberry PI 4, using Raspbian buster
There were no errors during build.
The installation downloads a precompiled version of electron on the first run.
However each time I try and run code, it starts but with an error:
[storage state.vscdb] open(): Unable to open DB due to Error: Cannot find module '../build/Release/sqlite
If I look in node_modules/vscode-sqlite3/build/Release/
I can see:
sqlite3.a
sqlite.a
It is unclear to me why electron/vscode cannot find this library. I would be greatful for any pointers on how to tell the runtime where to look for the modules.
On inspecting the build scripts and after many painful experiments, I've found and solved the 2 problems leading to this error.
The fact that .a static libraries are left behind hinted that some settings in the binding.gyp, config.gpy and/or makefiles are wrong, as Native Node Modules are normally dynamic libraries with an .node extension. One conditional line in the binding.gyp file under vscode-sqlite3 seems to the the culprit:
...
["target_arch=='arm'", {"type": "static_library"}]
...
Disable that line (by removing it or changing 'arm' to something else) and then run:
node-gyp configure
to regenerate the config.gpy file(s) under the build directory. Then build the module with:
node-gyp build
A sqlite.node will be generated in build/Release.
Unfortunately, the latest electron ABI version rarely matches that of the Node.js version. In my configuration, the electron ABI version is 72 (v6.0.12) but the latest stable Node version is for ABI 64. Therefore we have to do an electron-rebuild to update the sqlite.node to match the electron version.
To do this, you would have to first install electron-rebuild (yarn add electron-rebuild) then run electron-rebuild by giving supplying explicitly the version number of the electron binary that vscode downloaded:
electron-rebuild -v 6.0.12 -m /home/dev/vscode -o vscode-sqlite3
Of course you would have to state the version number of your particular version of electron you are building for.
(Please look up electron-rebuild --help for the meaning of the options. It takes a while to rebuild the binary module...)
The resulting sqlite.node can then be moved into the build/Release/. directory under the vscode project directory. Voila, we have a working latest version VS-Code for Raspbian!
I'm installing dotnet core on Linux ARM64 using tarball as explained here. After installing I followed the suggestion to set DOTNET_ROOT=$PATH:$HOME/dotnet. However global tools fail with A fatal error occurred, the required library libhostfxr.so could not be found.
I fixed by changing the env variable to DOTNET_ROOT=$HOME/dotnet.
Is this a bug in the docs ?
Yes, this appears to be a bug in the documentation. The code which interprets DOTNET_ROOT does not split the string on :. DOTNET_ROOT should be set to an absolute file path which points to the directory containing the dotnet executable. If dotnet is on your PATH already, you can set it like this in bash/zsh.
export DOTNET_ROOT="$(dirname $(which dotnet))"
came across this problem while working on porting .net libraries from Windows to Raspberry PI. On the Raspberry the .net core 3.1 installs in /opt/dotnet, and that's where DOTNET_ROOT ought to point at:
export DOTNET_ROOT="/opt/dotnet"
This should eliminate the "fatal error occurred. The required library libhostfxr.so could not be found." error when attempting to run portable code using the 'dotnet' command on the RPI
I was getting an error trying to execute the dotnet ef from the EF cli global tools install.
Added this to the bottom of my /home/<user>/.bashrc worked for me.
# User specific aliases and functions
export DOTNET_ROOT=$HOME/.dotnet
export PATH=$PATH:$DOTNET_ROOT:$DOTNET_ROOT/tools
Then the dotnet ef command worked correctly.
I had to add this to my ~/.zshrc
export DOTNET_ROOT=~/.dotnet
export PATH=$PATH:$DOTNET_ROOT
I found that I had different locations for different sdk/runtime versions. One was installed at "/home/{username}/.dotnet" and the other at "/usr/share/dotnet".
I found a post stating the default DOTNET_ROOT is "/usr/share/dotnet" and errors showed dotnet command was executing this location. I copied all files from "home/{username}/.dotnet" to "/usr/share/dotnet" with rsync.
sudo apt install rsync;
sudo rsync -a /home/{username}/.dotnet/ /usr/share/dotnet
I know how to package and then deploy meteor application. But recently for one project i'm stuck at an error which i couldn't resolve.
Steps I followed for package and deploy of my meteor app:
1. meteor build package
2. cd package
3. tar -xf inventoryTool.tar.gz
4. cd bundle/programs/server
5. npm install
6. cd ../..
7. PORT=<port> MONGO_URL=mongodb://127.0.0.1:27017/dbName ROOT_URL=http://<ip> node main.js
Here is the log for the error when i run the npm install(STEP 5) command.
Is there anything missing in my execution?. I'm not using the fibers package anywhere in my project. Does anyone have solution to this problem? Thanks in advance.
Why this happens (a lot)?
Your local version of node is v8.9.4. When using the build command, you will export your application and build the code against this exact node version. Your server environment will require this exact version, too.
An excerpt from the custom deployment section of the guide:
Depending on the version of Meteor you are using, you should install
the proper version of node using the appropriate installation process
for your platform. To find out which version of node you should use,
run meteor node -v in the development environment, or check the
.node_version.txt file within the bundle generated by meteor build.
Even if you don't use fibers explicitly it will be required to run your Meteor app on the server correctly.
So what to do?
In order to solve this, you need to
a) ensure that your local version of node exactly matches the version on the server
b) ensure that you build against the server's architecture (see build command)
To install a) the very specific node version on your server you have two options:
Option I. Use n, as described here. However this works only if your server environment uses node and not nodejs (which depends on how you installed nodejs on the server).
II. To install a specific nodejs version from the repositories, you may do the following:
$ cd /tmp
$ wget https://deb.nodesource.com/node_8.x/pool/main/n/nodejs/nodejs_8.9.4-1nodesource1_amd64.deb
$ apt install nodejs_8.9.4-1nodesource1_amd64.deb
If you are not sure, which of both are installed on your server, check node -v and nodejs -v. One of both will return a version. If your npm install still fails, check the error output and if it involves either node or nodejs and install the desired distribution using the options above.
To build b) against the architecture on your server, you should use the --architecture flag in your build command.
[react-pocketscholar (master)]$ meteor --version
/Users/ftrflyr/.meteor/packages/meteor-tool/.1.3.4_3.1v4v008++os.osx.x86_64+web.browser+web.cordova/mt-os.osx.x86_64/dev_bundle/lib/node_modules/meteor-promise/promise_server.js:165
throw error;
^
Error: EEXIST, symlink '/Users/ftrflyr/.meteor/packages/meteor-tool/.1.3.4_3.1v4v008++os.osx.x86_64+web.browser+web.cordova/mt-os.osx.x86_64/dev_bundle'
[react-pocketscholar (master)]$ meteor -v
/Users/ftrflyr/.meteor/packages/meteor-tool/.1.3.4_3.1v4v008++os.osx.x86_64+web.browser+web.cordova/mt-os.osx.x86_64/dev_bundle/lib/node_modules/meteor-promise/promise_server.js:165
throw error;
^
Error: EEXIST, symlink '/Users/ftrflyr/.meteor/packages/meteor-tool/.1.3.4_3.1v4v008++os.osx.x86_64+web.browser+web.cordova/mt-os.osx.x86_64/dev_bundle'
1. Global tool version of meteor command
Find version by:
meteor --version
2. Project version of meteor
A project stays at the meteor version which it was created with unless manually upgraded. Find this by running:
cat .meteor/release
Another way to do this is to open up your Javascript console in the browser and type:
console.log(Meteor);
This is very useful for me as I'm running Ubuntu on a Chromebook so I don't need to stop my local server to check which version I'm currently running.
Please note the server does need to be running (localhost:3000) for this command to work.
You have to be in a meteor project repository and type meteor --version