error: no template named 'remove_cv_t' in namespace 'std'; did you mean 'remove_cv'?

Question

My problem seems similar to this issue, except it happens when I run yarn install in a rails app.

When I run yarn install, it runs successfully for some time, then

../src/libsass/src/ast.hpp:1614:25: warning: loop variable 'numerator' of type 'const std::__1::basic_string<char>' creates a copy from type 'const std::__1::basic_string<char>' [-Wrange-loop-analysis]
        for (const auto numerator : numerators)
                        ^
../src/libsass/src/ast.hpp:1614:14: note: use reference type 'const std::__1::basic_string<char> &' to prevent copying
        for (const auto numerator : numerators)
             ^~~~~~~~~~~~~~~~~~~~~~
                        &
../src/libsass/src/ast.hpp:1616:25: warning: loop variable 'denominator' of type 'const std::__1::basic_string<char>' creates a copy from type 'const std::__1::basic_string<char>' [-Wrange-loop-analysis]
        for (const auto denominator : denominators)
                        ^
../src/libsass/src/ast.hpp:1616:14: note: use reference type 'const std::__1::basic_string<char> &' to prevent copying
        for (const auto denominator : denominators)
             ^~~~~~~~~~~~~~~~~~~~~~~~
                        &
2 warnings generated.
  rm -f Release/sass.a && ./gyp-mac-tool filter-libtool libtool  -static -o Release/sass.a Release/obj.target/libsass/src/libsass/src/ast.o Release/obj.target/libsass/src/libsass/src/ast_fwd_decl.o Release/obj.target/libsass/src/libsass/src/backtrace.o Release/obj.target/libsass/src/libsass/src/base64vlq.o Release/obj.target/libsass/src/libsass/src/bind.o Release/obj.target/libsass/src/libsass/src/cencode.o Release/obj.target/libsass/src/libsass/src/check_nesting.o Release/obj.target/libsass/src/libsass/src/color_maps.o Release/obj.target/libsass/src/libsass/src/constants.o Release/obj.target/libsass/src/libsass/src/context.o Release/obj.target/libsass/src/libsass/src/cssize.o Release/obj.target/libsass/src/libsass/src/emitter.o Release/obj.target/libsass/src/libsass/src/environment.o Release/obj.target/libsass/src/libsass/src/error_handling.o Release/obj.target/libsass/src/libsass/src/eval.o Release/obj.target/libsass/src/libsass/src/expand.o Release/obj.target/libsass/src/libsass/src/extend.o Release/obj.target/libsass/src/libsass/src/file.o Release/obj.target/libsass/src/libsass/src/functions.o Release/obj.target/libsass/src/libsass/src/inspect.o Release/obj.target/libsass/src/libsass/src/json.o Release/obj.target/libsass/src/libsass/src/lexer.o Release/obj.target/libsass/src/libsass/src/listize.o Release/obj.target/libsass/src/libsass/src/memory/SharedPtr.o Release/obj.target/libsass/src/libsass/src/node.o Release/obj.target/libsass/src/libsass/src/operators.o Release/obj.target/libsass/src/libsass/src/output.o Release/obj.target/libsass/src/libsass/src/parser.o Release/obj.target/libsass/src/libsass/src/plugins.o Release/obj.target/libsass/src/libsass/src/position.o Release/obj.target/libsass/src/libsass/src/prelexer.o Release/obj.target/libsass/src/libsass/src/remove_placeholders.o Release/obj.target/libsass/src/libsass/src/sass.o Release/obj.target/libsass/src/libsass/src/sass2scss.o Release/obj.target/libsass/src/libsass/src/sass_context.o Release/obj.target/libsass/src/libsass/src/sass_functions.o Release/obj.target/libsass/src/libsass/src/sass_util.o Release/obj.target/libsass/src/libsass/src/sass_values.o Release/obj.target/libsass/src/libsass/src/source_map.o Release/obj.target/libsass/src/libsass/src/subset_map.o Release/obj.target/libsass/src/libsass/src/to_c.o Release/obj.target/libsass/src/libsass/src/to_value.o Release/obj.target/libsass/src/libsass/src/units.o Release/obj.target/libsass/src/libsass/src/utf8_string.o Release/obj.target/libsass/src/libsass/src/util.o Release/obj.target/libsass/src/libsass/src/values.o
  c++ '-DNODE_GYP_MODULE_NAME=binding' '-DUSING_UV_SHARED=1' '-DUSING_V8_SHARED=1' '-DV8_DEPRECATION_WARNINGS=1' '-DV8_DEPRECATION_WARNINGS' '-DV8_IMMINENT_DEPRECATION_WARNINGS' '-D_GLIBCXX_USE_CXX11_ABI=1' '-D_DARWIN_USE_64_BIT_INODE=1' '-D_LARGEFILE_SOURCE' '-D_FILE_OFFSET_BITS=64' '-DBUILDING_NODE_EXTENSION' -I/Users/st/.node-gyp/16.0.0/include/node -I/Users/st/.node-gyp/16.0.0/src -I/Users/st/.node-gyp/16.0.0/deps/openssl/config -I/Users/st/.node-gyp/16.0.0/deps/openssl/openssl/include -I/Users/st/.node-gyp/16.0.0/deps/uv/include -I/Users/st/.node-gyp/16.0.0/deps/zlib -I/Users/st/.node-gyp/16.0.0/deps/v8/include -I../../nan -I../src/libsass/include  -O3 -gdwarf-2 -mmacosx-version-min=10.7 -arch x86_64 -Wall -Wendif-labels -W -Wno-unused-parameter -std=c++11 -stdlib=libc++ -fno-rtti -fno-exceptions -fno-strict-aliasing -MMD -MF ./Release/.deps/Release/obj.target/binding/src/binding.o.d.raw   -c -o Release/obj.target/binding/src/binding.o ../src/binding.cpp
In file included from ../src/binding.cpp:1:
In file included from ../../nan/nan.h:56:
In file included from /Users/st/.node-gyp/16.0.0/include/node/node.h:63:
In file included from /Users/st/.node-gyp/16.0.0/include/node/v8.h:30:
/Users/st/.node-gyp/16.0.0/include/node/v8-internal.h:452:38: error: no template named 'remove_cv_t' in namespace 'std'; did you mean 'remove_cv'?
            !std::is_same<Data, std::remove_cv_t<T>>::value>::Perform(data);
                                ~~~~~^~~~~~~~~~~
                                     remove_cv
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/type_traits:697:50: note: 'remove_cv' declared here
template <class _Tp> struct _LIBCPP_TEMPLATE_VIS remove_cv
                                                 ^
1 error generated.
make: *** [Release/obj.target/binding/src/binding.o] Error 1
gyp ERR! build error 
gyp ERR! stack Error: `make` failed with exit code: 2
gyp ERR! stack     at ChildProcess.onExit (/Users/st/rails/myapp/node_modules/node-gyp/lib/build.js:262:23)
gyp ERR! stack     at ChildProcess.emit (node:events:365:28)
gyp ERR! stack     at Process.ChildProcess._handle.onexit (node:internal/child_process:290:12)
gyp ERR! System Darwin 20.3.0
gyp ERR! command "/usr/local/Cellar/node/16.0.0/bin/node" "/Users/st/rails/myapp/node_modules/node-gyp/bin/node-gyp.js" "rebuild" "--verbose" "--libsass_ext=" "--libsass_cflags=" "--libsass_ldflags=" "--libsass_library="
gyp ERR! cwd /Users/st/rails/myapp/node_modules/node-sass
gyp ERR! node -v v16.0.0
gyp ERR! node-gyp -v v3.8.0
gyp ERR! not ok 

Any ideas how to solve this? (I'm not even sure if it's a problem with xcode/node/rails/c++)

Other notes

• /usr/bin/xcodebuild -version returns

Xcode 12.4
Build version 12D4e

• cpp --version returns

Apple clang version 12.0.0 (clang-1200.0.32.29)
Target: x86_64-apple-darwin20.3.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin

Please note: I don't code in cpp, so I have very little contextual knowledge of how to solve.

Answer 1

Update: Since node-sass version 6.0.1, Node 16 is supported. Updating node-sass to a version in the 6.x range solves this issue for Node 16. For other Node versions, the node-sass readme has a compatibility table for which versions of Node SASS are compatible with which versions of Node.

---

What you're seeing is an error during compilation of node-sass. That's a package processing your Sass/SCSS styles, which is written in C++ and only re-packaged as a JavaScript library. The fact it's written in C++ means it needs to be compiled on your device during installation (this is internally done by a tool called node-gyp, which you can spot in your error output, too).

The problem is node-sass doesn't support Node 16 as of writing this answer, see tracking issue: https://github.com/sass/node-sass/issues/3077 There's no estimate on when it's gonna support it (and that's fair, as it's a volunteer-driven project). Even if you manage to install node-sass on Node 16, I'd advice against it, as the behavior might be undefined.

The correct solution is to downgrade your Node installation to a supported version (I can see both 14 and 15 tested in their CI). If you git cloned a project and it won't install on your machine, but works for your colleagues or on the production server, it's likely the project has a different version of Node in mind too, and isn't tested on Node 16, so I'd advice against developing it on Node 16 anyway. If the project worked for you just a few days ago, but it doesn't work now, it's very likely you recently upgraded your system setup (e.g. Homebrew), which upgraded you to Node 16 (this is what happened to me and how I found this question).

You should check with the authors of the project what's the production server version of Node it runs on and install that version locally, too. As a best practice, in the future, keep the production version and your local version of Node (and yarn or npm) in sync. For managing multiple Node versions, you can use this tool https://github.com/nvm-sh/nvm

Answer 2

Update - simple fix!

Here's an easy way to solve this that lets you keep using node 16.

1. Delete yarn.lock
2. Open package.json and make sure you use webpacker version 5.4.3 (which is the latest version - it won't pull in the old version of node-sass that causes this problem)
3. Run yarn install
4. Start your rails server and everything should be back to normal!

---

Here is the previous, much longer answer (in case it's still useful):

node-sass is not yet compatible with node v16

To get around this, downgrade node (e.g. to version 14) until node-sass is compatible with v16. To downgrade node using nvm, simply run:

nvm install 14

Set version 14 globally (so each new terminal windows defaults to node version 14) by running:

nvm alias default 14

Now you have node 14 installed and set as default! ..now you just need to make your app use v14.

---

How to make your rails app use node 14

Install node 14 (see above). Open terminal and head to your app's root directory, then:

1. Stop your rails server if it's running
2. Open a fresh new terminal window (so that node --version returns 14.x (not 16)
3. Run spring stop
4. Delete yarn.lock
5. Remove existing node modules with rm -rf node_modules
6. Check that node --version returns 14. If it doesn't run nvm install 14 again.
7. Now reinstall modules with yarn install (if you don't have yarn for node 14, install it with npm install --global yarn)
8. It should succeed!
9. Restart your rails server, and it will work!

---

If you have this problem specifically on heroku, try also ensuring your webpacker is up to date:

yarn upgrade @rails/webpacker --latest

Answer 3

Try this:

export CXXFLAGS="--std=c++17" && npm install

Answer 4

Same issue, this fixes it for me:

CXXFLAGS="--std=c++17" yarn install

Answer 5

I had the same issue with Node 16. Downgrading to Node 14 worked fine for me. Here's simple steps on how you can do the same (Using Homebrew):

• Check your current node version

  node -v 
  

• Check for available node versions

  brew search node
  

• To unlink from current version

  brew unlink node
  

• Install the version you want using the following command (e.g. for version 14)

  brew install node@14
  

• Link it to the installed version

  brew link node@14
  

At the end just make sure you have the right version install using the command from the first step.

Answer 6

I was getting this error while building node-sass.

/Users/shahwarkhalid/.node-gyp/16.6.1/include/node/v8-internal.h:488:38: error: no template named 'remove_cv_t' in namespace 'std'; did you mean 'remove_cv'?

This hack solved my issue:

cd /Users/shahwarkhalid/.node-gyp/16.6.1/include/node/

open v8-internal.h file in an editor.

change remove_cv_t to remove_cv on line 488.

yarn install again and the issue was resolved.

Answer 7

In my case I just switched node from 12 to 10:

nvm use 10

Answer 8

For Apple M1 chips, working way is:

sudo xcode-select --install
curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.37.2/install.sh | bash
nvm install v15
nvm cache clear

Answer 9

I do not know about the const auto numerator.

But when I edited the ~/Library/Caches/node-gyp/16.4.0/include/node/v8-internal.h (yours has a different directory) as shown in my terminal error, it proceeds to compilation without error.

My solution:

I renamed remove_cv_t to remove_cv as directed on the error message.

then proceed to compilation.

---

What I plan next after this temporary fix is to update ng xcode. Maybe it has the updated template definition as hinted in error message

template <class _Tp> struct _LIBCPP_TEMPLATE_VIS remove_cv

Answer 10

Since some of the answers to this question, a new version of node-sass (v6) has been released that fixes the issue by adding support for node 16.

In my case, Rails was depending on an older version of node-sass because of the version of @rails/webpacker I had in my package.json (4.3.0). Updating this to a version after the current release at the time of this answer, 5.4.0, resolved the problem.

Answer 11

Revert to the latest Node v14 LTS for using node-sass:

brew install node@14
brew unlink node
brew link node@14
node -v
spring stop

Run in your Rails project:

yarn install

PS: Node 16 has an errors with node-sass https://github.com/nodejs/node/issues/38367#issuecomment-825461899

Answer 12

Upgrade to node-sass@6 which added support for Node 16, recently released

Answer 13

Similar to @murb, I had run a brew update the other day on my build box and noticed node 16 was installed. Dropping it back down to node 12 fixed the problem for me until I can update my entire build system to work properly with a newer version of node.

Answer 14

Perhaps not directly an answer to this problem, but I came across this question while debugging failed builds in TravisCI and caused me to push quite a few commits to fix. For me it was caused by the fact that Node 16 was released a few days ago. I noticed that I was using nvm install node in the before_script, which always defaults to the latest, instead of nvm install which actually adheres to the version specified in .nvmrc. While using an older version of something is not a long term solution; yarn install -std=c++14 already failed for me on that very line.

Answer 15

I tried to see my current version with cpp --version which gives

cpp --version Apple clang version 12.0.0 (clang-1200.0.32.29)
Target: x86_64-apple-darwin20.3.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin

The compiler version is not the C++ standard version.

The former is the version of the tool, the latter is the version of the C++ standard.

All the major recent C++ compilers (I know) meanwhile do support multiple C++ standards.

The C++ standard is important if portable (standard conforming) code shall be developed – agnostic to a specific compiler. This allows to develop code for multiple platforms, compiled by different compilers. It also helps to develop with better quality – a weakness in code which may slip through (i.e. be tolerated) in the compiler of one vendor, might be complained in another.

The explicit choice of the C++ standard in a compiler is important as well:

• The newest supported standard of the compiler might still be in an experimental state.
• The developer may develop against a certain (older) standard (to stay compatible to other platforms where the newest C++ standard is not yet supported by the available compilers) and wants to be sure that no newer stuff may slip in.

A compiler with a certain compiler version defaults usually to a certain C++ standard. (Which one it is might be found in the doc. or online.) Nevertheless, this is not necessarily the newest supported C++ standard.

The explicit choice of the C++ standard can be done with a command line argument:

• g++ and clang: -std= (and probably compilers of other vendors as well)
• MSVC: /std:.

E.g. g++ -std=c++14 calls G++ forced to the C++14 standard.

It's a bit sad that this command line argument is not literally identical for all compilers / vendors. Hence, it's more convenient to define the required C++ standard in the built tool which is used. (The built tool will take care to choose the appropriate command line argument depending on the found / used compiler.)

For CMake (which I use in daily work), this is

set(CMAKE_CXX_STANDARD 17)
set(CMAKE_CXX_STANDARD_REQUIRED ON)
set(CMAKE_CXX_EXTENSIONS OFF)

(For corner cases, additional settings may be required as I once painfully found out: SO: Pointer to member variable as static member.)

OP uses yarn, I've admittedly never heard about before.

He reported that yarn install -std=c++17 solved his issue. (I tried to find some kind of doc. for this online but I failed.)