Troubleshooting your Development Environment Setup

This document provides solutions to some common Rocket.Chat development problems, but remember, each issue is unique, and sometimes, you may need to dig deeper to find the root cause.

General troubleshooting

Resolving the missing babel-runtime npm package

If you encounter an error stating:

(STDERR) Error: The babel-runtime npm package could not be found in your node_modules
(STDERR) directory. Please run the following command to install it:
(STDERR)
(STDERR)   meteor npm install --save babel-runtime
(STDERR)
(...)
=> Exited with code: 1
=> Your application is crashing. Waiting for file change.

You can resolve this by installing the mentioned package with the command:

meteor npm install --save babel-runtime

Resolving the slower JavaScript implementation of bcrypt

If you see the following warning in the meteor logs:

(STDERR) Note: you are using a pure-JavaScript implementation of bcrypt.
(STDERR) While this implementation will work correctly, it is known to be
(STDERR) approximately three times slower than the native implementation.
(STDERR) In order to use the native implementation instead, run
(STDERR)
(STDERR)   meteor npm install --save bcrypt
(STDERR)

This simply means that the bcrypt library is not installed on your system, and Meteor will use a slower JavaScript alternative.

To install the missing library and make it faster, use the command:

meteor npm install --save bcrypt

If the version of the python interpreter on your system is greater than v2.5.0 or less than 3.0.0, it should work fine, but if you see a message like this:

gyp ERR! configure error
gyp ERR! stack Error: Python executable "/usr/local/bin/python3" is v3.5.2, which is not supported by gyp.
gyp ERR! stack You can pass the --python switch to point to Python >= v2.5.0 & < 3.0.0.

If you have a python interpreter that matches the above requirements, use the following command to fix the error:

meteor npm config set python python2.7

Build it again:

meteor npm install --save bcrypt

If everything works, you should see a message like this:

> node-gyp rebuild

  CXX(target) Release/obj.target/bcrypt_lib/src/blowfish.o
  CXX(target) Release/obj.target/bcrypt_lib/src/bcrypt.o
  CXX(target) Release/obj.target/bcrypt_lib/src/bcrypt_node.o
  SOLINK_MODULE(target) Release/bcrypt_lib.node
clang: warning: libstdc++ is deprecated; move to libc++ with a minimum deployment target of OS X 10.9
[email protected] /Users/douglas/work/github/Rocket.Chat
└─┬ [email protected]
  ├── [email protected]
  └── [email protected]

Fixing symbolic link issues with libcuda.so.1

Please follow these steps if you encounter the error message, “/sbin/ldconfig.real: /usr/lib/wsl/lib/libcuda.so.1 is not a symbolic link” while building your Rocket.Chat project.

  1. Open a terminal and check the status of the libcuda.so.1 file by running:

    ls -l /usr/lib/wsl/lib/libcuda.so.1

    If the output shows this:

    -r-xr-xr-x 1 root root 154088 Dec 19  2023 /usr/lib/wsl/lib/libcuda.so.1

    This means the libcuda.so.1 file exists but is not a symbolic link, as indicated by the file permissions and type (-r-xr-xr-x indicates a regular file, not a symbolic link). To resolve this issue, remove this file and create a symbolic link pointing to the correct libcuda.so file.

  2. Remove libcuda.so.1 file:

    sudo rm /usr/lib/wsl/lib/libcuda.so.1
  3. Check for the actual libcuda files in the directory to determine the correct target for the symbolic link:

    ls -l /usr/lib/wsl/lib/

    Look for the actual libcuda files, such as libcuda.so.1.1.

  4. Create a symbolic link, assuming libcuda.so.1.1 is the correct target file:

    sudo ln -s /usr/lib/wsl/lib/libcuda.so.1.1 /usr/lib/wsl/lib/libcuda.so.1
  5. Verify the symbolic link is set up correctly:

    ls -l /usr/lib/wsl/lib/libcuda.so.1

    The output should show that libcuda.so.1 is a symbolic link pointing to libcuda.so.1.1 (or another appropriate version):

    lrwxrwxrwx 1 root root 31 Jun 24 19:04 /usr/lib/wsl/lib/libcuda.so.1 -> /usr/lib/wsl/lib/libcuda.so.1.1
  6. Clean Yarn cache:

    yarn cache clean
  7. Install dependencies and build the project:

    yarn
    yarn dsv

Windows troubleshooting

Resolving error exit 139  from segmentation fault.

This error is usually related to memory access issues and environmental setup conflicts. You can resolve it by following these steps:

  1. Increase memory and CPUs in WSL. You can do this by editing the ~/.wslconfig file in Notepad or VS Code. To do this:

    1. Open the Windows Run dialog (press Win + R)

    2. Type notepad %UserProfile%\.wslconfig for Notepad and code %UserProfile%\.wslconfig for VS Code

    3. If the file doesn't exist, Notepad will prompt you to create one

    4. If the file is empty, add the content below:

      [wsl2]
      memory=4GB #allocates 4GB of RAM to WSL. Increase if needed (e.g., 8GB or 16GB
      processors=2 #allocates 2CPU cores to WSL. Adjust as needed
    5. Stop WSL instances by running wsl —shutdown from Windows Powershell

    6. Restart WSL by launching your WSL terminal again (e.g., Ubuntu)

  2. Clear Meteor’s cache:

    cd Rocket.Chat/apps/meteor
    rm -rf .meteor/local
  3. Clean up and reinstall dependencies:

    cd Rocket.Chat  # navigate into the Rocket.Chat root directory
    rm -rf node_modules # remove installed dependencies
    yarn cache clean # clean cached files
    yarn # re-install dependencies
    yarn dsv # rebuild the Rocket.Chat project

MacOS troubleshooting

Resolving yarn permission error

If you encounter a "permission denied" error when running Yarn in your project, it may be due to incorrect permissions on either your home directory or the Yarn cache directory.

To fix this, run the command below:

sudo chown -R $(whoami) ~/.yarn
sudo chmod -R u+w ~/.yarn

These commands change the ownership of the ~/.yarn directory to the current user and grants write permissions, thus resolving the permission error.

Failure linking "fibers" (Apple Silicon)

If yarn is failing on the link step for fibers with a log similar to:

➤ YN0007: │ fibers@npm:5.0.3 must be built because it never has been before or the last one failed
➤ YN0009: │ fibers@npm:5.0.3 couldn't be built successfully (exit code 1, logs can be found here: /private/var/folders/…/build.log)
➤ YN0009: │ fibers@npm:5.0.3 couldn't be built successfully (exit code 1, logs can be found here: /private/var/folders/…/build.log)
➤ YN0009: │ fibers@npm:5.0.3 couldn't be built successfully (exit code 1, logs can be found here: /private/var/folders/…/build.log)

You can resolve the error by following the steps below:

  1. Install node-gyp globally:

    npm install node-gyp --global
    `node-gyp` introduced breaking changes in Oct 2023 for v10.0.0+ and supports node `^16.14.0 || >=18.0.0`.
    If you are experiencing incompatible node version issues because of this, install `[email protected]` or older.
    See [recent releases](https://github.com/nodejs/node-gyp/releases) for more information. 
  2. Rebuild fibers for the system architecture manually:

    cd node_modules/fibers
    node-gyp rebuild --arch=arm64
    Depending on your `node-gyp` version, it may utilize the `distutils` package, which is deprecated in Python version `3.12`+. If you are
    experiencing issues at this step set your Python environment to an older version.
  3. Copy binary to the correct location

    mkdir bin/darwin-arm64-83
    cp build/Release/fibers.node bin/darwin-arm64-83/fibers.node
  4. Copy the rebuilt module into meteor

    cd ../..
    rm -rf apps/meteor/node_modules/fibers/
    cp -r node_modules/fibers apps/meteor/node_modules/
  5. Follow the instructions below for fixing a Bcrypt problem, even though its error message has not yet appeared.

Bcrypt requires arm64 binary but has amd64 one instead (Apple Silicon)

The error specifically looks like the following:

(mach-o file, but is an incompatible architecture (have 'x86_64', need 'arm64e')), '/usr/local/lib/bcrypt_lib.node' (no such file), '/usr/lib/bcrypt_lib.node' (no such file)

Resolve by taking these steps:

  1. Move to the bcrypt directory and rebuild everything:

    cd node_modules/bcrypt
    make
  2. Copy the rebuilt module into meteor

    cd ../..
    rm -rf apps/meteor/node_modules/bcrypt
    cp -r node_modules/bcrypt apps/meteor/node_modules/

yarn dsv failing and shows “something went wrong installing the ‘sharp’ module.”

An Apple silicon processor incompatibility causes this error. It means the Sharp module used for image processing in the Rocket.Chat project cannot find the required native add-on file sharp-darwin-arm64v8.node.

To resolve this problem, follow the steps below:

  1. Install Rosetta 2 by running softwareupdate --install-rosetta.

  2. Uninstall Meteor by running:

    sudo rm /usr/local/bin/meteor 
    rm -rf ~/.meteor 
  3. Reinstall meteor with flags by running arch -x86_64 npm install -g meteor.

  4. Now run yarn && yarn build && yarn dsv.

Now, the application should be successfully built and be available to access via http://localhost:3000.

Apple Silicon: Bcrypt on ARM architecture fails with “incompatible architecture error” after running yarn dsv

The error may contain error that looks like this:

(mach-o file, but is an incompatible architecture (have 'arm64', need 'x86_64'))

The error message states, "have 'arm64', need 'x86_64'", indicating that Meteor requests a different architecture than the one it's running on.

This issue is specific to Mac systems running Apple Silicon chips. Meteor supports the arm64 architecture, but if it defaults to x86_64, it’s likely because your Meteor installation was set up before arm64 support was added.

To fix this, remove Meteor and reinstall it using the following commands:

rm -rf ~/.meteor
npx meteor

Troubleshooting is a vital part of the development process, and understanding how to navigate and resolve common issues can significantly enhance your productivity.