ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange
Ask Your Question
0

Building workspace: error: '_GLIBCXX_NUM_CATEGORIES' was not declared in this scope

asked 2021-08-08 18:26:15 -0600

high12noon gravatar image

updated 2021-08-09 02:23:11 -0600

gvdhoorn gravatar image

Following the tutorial "Creating a workspace" described here:

https://docs.ros.org/en/galactic/Tuto...

'colcon build' fails with lots of C++ errors.

My locale:

$ locale
LANG=en_US.UTF-8
LANGUAGE=
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_PAPER="en_US.UTF-8"
LC_NAME="en_US.UTF-8"
LC_ADDRESS="en_US.UTF-8"
LC_TELEPHONE="en_US.UTF-8"
LC_MEASUREMENT="en_US.UTF-8"
LC_IDENTIFICATION="en_US.UTF-8"
LC_ALL=

$ printenv | grep ROS
ROS_VERSION=2
ROS_PYTHON_VERSION=3
ROS_LOCALHOST_ONLY=0
ROS_DISTRO=galactic

My installation type: ROS2 Galactic via Debian packages (sudo apt install).

My OS: Ubuntu 20.04

What goes wrong:

colcon build fails to build turtlesim with lots and lots of errors like this:

In file included from /usr/include/c++/9/locale:39,
                 from /usr/local/include/locale.h:11,
                 from /usr/include/c++/9/clocale:42,
                 from /usr/include/x86_64-linux-gnu/c++/9/bits/c++locale.h:41,
                 from /usr/include/c++/9/bits/localefwd.h:40,
                 from /usr/include/c++/9/string:43,
                 from /usr/include/c++/9/stdexcept:39,
                 from /usr/include/c++/9/array:39,
                 from /usr/include/c++/9/tuple:39,
                 from /usr/include/c++/9/bits/unique_ptr.h:37,
                 from /usr/include/c++/9/memory:80,
                 from /opt/ros/galactic/include/rosidl_runtime_cpp/bounded_vector.hpp:19,
                 from /home/me/dev_ws/build/turtlesim/rosidl_generator_cpp/turtlesim/action/detail/rotate_absolute__struct.hpp:8,
                 from /home/me/dev_ws/build/turtlesim/rosidl_typesupport_cpp/turtlesim/action/rotate_absolute__type_support.cpp:7:
/usr/include/c++/9/bits/locale_classes.h:333:37: error: ‘_GLIBCXX_NUM_CATEGORIES’ was not declared in this scope
  333 |     enum { _S_categories_size = 6 + _GLIBCXX_NUM_CATEGORIES };
      |                                     ^~~~~~~~~~~~~~~~~~~~~~~
/usr/include/c++/9/bits/locale_classes.h: In constructor ‘std::locale::locale(const string&)’:
/usr/include/c++/9/bits/locale_classes.h:163:45: error: invalid use of incomplete type ‘const string’ {aka ‘const class std::__cxx11::basic_string<char>’}
  163 |     locale(const std::string& __s) : locale(__s.c_str()) { }
      |                                             ^~~
In file included from /usr/include/c++/9/iosfwd:39,
                 from /usr/include/c++/9/memory:72,
                 from /opt/ros/galactic/include/rosidl_runtime_cpp/bounded_vector.hpp:19,
                 from /home/me/dev_ws/build/turtlesim/rosidl_generator_cpp/turtlesim/action/detail/rotate_absolute__struct.hpp:8,
                 from /home/me/dev_ws/build/turtlesim/rosidl_typesupport_cpp/turtlesim/action/rotate_absolute__type_support.cpp:7:
/usr/include/c++/9/bits/stringfwd.h:74:11: note: declaration of ‘std::string’ {aka ‘class std::__cxx11::basic_string<char>’}
   74 |     class basic_string;
      |           ^~~~~~~~~~~~
In file included from /usr/include/c++/9/locale:39,
                 from /usr/local/include/locale.h:11,
                 from /usr/include/c++/9/clocale:42,
                 from /usr/include/x86_64-linux-gnu/c++/9/bits/c++locale.h:41,
                 from /usr/include/c++/9/bits/localefwd.h:40,
                 from /usr/include/c++/9/string:43,
                 from /usr/include/c++/9/stdexcept:39,
                 from /usr/include/c++/9/array:39,
                 from /usr/include/c++/9/tuple:39,
                 from /usr/include/c++/9/bits/unique_ptr.h:37,
                 from /usr/include/c++/9/memory:80,
                 from /opt/ros/galactic/include/rosidl_runtime_cpp/bounded_vector.hpp:19,
                 from /home/me/dev_ws/build/turtlesim/rosidl_generator_cpp/turtlesim/action/detail/rotate_absolute__struct.hpp:8,
                 from /home/me/dev_ws/build/turtlesim/rosidl_typesupport_cpp/turtlesim/action/rotate_absolute__type_support.cpp:7:

<snip lots of errors> ...
(more)
edit retag flag offensive close merge delete

Comments

error: ‘_GLIBCXX_NUM_CATEGORIES’ was not declared in this scope

seems to suggest this is a problem with your locale / language settings and/or configuration somewhere.

Searching for this error message (using Google) turns up quite some results.

This is not really a Colcon or ROS 2 problem I believe.

gvdhoorn gravatar image gvdhoorn  ( 2021-08-09 02:20:18 -0600 )edit

@gvdhoorn thanks for your answer but I showed my locale above: en_US.UTF-8. It seems to me that something is choosing the wrong C++ standard and/or headers, but this is a stock Ubuntu 20.04 install and ROS2 Galactic from Debian packages, so it should work out of the box. How can I debug this problem?

high12noon gravatar image high12noon  ( 2021-08-09 09:48:35 -0600 )edit

I showed my locale above: en_US.UTF-8.

setting an env var and properly configuring locales are two different things.

_GLIBCXX_NUM_CATEGORIES is #defined in /usr/include/x86_64-linux-gnu/c++/9/bits/c++locale.h or thereabouts. That would seem to point to a locale related issue.

You don't include all error messages, so it could be the _GLIBCXX_NUM_CATEGORIES problem is a red herring and is due to an earlier parsing error. You'll have to check that yourself, as we can't determine that with what you've shown.

It seems to me that something is choosing the wrong C++ standard and/or headers

what makes you conclude that? _GLIBCXX_NUM_CATEGORIES is "used" by std::string's headers, so if that fails, the rest of std::string will also not parse correctly.

gvdhoorn gravatar image gvdhoorn  ( 2021-08-09 09:55:35 -0600 )edit

2 Answers

Sort by » oldest newest most voted
0

answered 2021-08-09 09:57:57 -0600

gvdhoorn gravatar image

updated 2021-08-09 11:00:52 -0600

Just noticed this:

/usr/local/include/locale.h:11

it seems odd to me you have a locale.h in /usr/local/include. That's most likely not a system-standard file.

Have you built anything (compilers, libstdc++, etc) from source?


Edit: see my comment about having to build libfmt from source if you're installing ROS 2 using apt. Summarising: I would not recommend doing that, as it suggests there are deeper/other problems with your install.

Additionally: fmtlib/fmt#1803 seems like it discusses the same issue as you encountered.

Note: I'm not suggesting you rebuild libfmt using the CMake options mentioned in that issue. I'm mentioning that issue as it seems to mention similar problems with locale.h from libfmt as you are experiencing.

edit flag offensive delete link more

Comments

No. I did not build compilers from source. How do I eliminate that, and/or how do I cause the correct headers to be used?

high12noon gravatar image high12noon  ( 2021-08-09 10:48:38 -0600 )edit

What's the contents of that file? That could give a clue.

gvdhoorn gravatar image gvdhoorn  ( 2021-08-09 10:49:53 -0600 )edit

There is only one thing I built from source: ROS depends on a libfmt shared object, but the Ubuntu libfmt package does not install a shared object; therefore I built that from source as follows:

$ git clone https://github.com/fmtlib/fmt.git
$ cd fmt
$ git checkout 6.2.1
$ cmake -DBUILD_SHARED_LIBS=TRUE CMakeLists.txt
$ make
$ sudo make install
$ sudo ldconfig

That is the only thing I built from source; I don't think it should have put headers in /usr/local.

high12noon gravatar image high12noon  ( 2021-08-09 10:50:45 -0600 )edit

libfmt does include a include/fmt/locale.h. Could be that file.

There is only one thing I built from source: ROS depends on a libfmt shared object, but the Ubuntu libfmt package does not install a shared object

so ROS 2 is daily (hourly) built on CI servers for Ubuntu. I would find it very odd if that wouldn't already have discovered the problem you describe.

I would also find it very odd if you'd need to build something from source which is such a low-level dependency, especially when you're installing ROS 2 using apt. Having to execute sudo make install to fix something which was installed using apt is a huge red flag. Personally I would never do that. It would suggest something went wrong with packaging.

I'd suggest reporting this somewhere (perhaps the ros2/ros2 issue tracker) as it seems suspicious.

gvdhoorn gravatar image gvdhoorn  ( 2021-08-09 10:55:39 -0600 )edit

@gvthoorn thank you for your input. I can confirm that the suspicious locale.h is in fact the one that is built and installed from libfmt's sources. For your information, this isn't the only problem I ran into: I first tried to install ROS2 Galactic from the binary tarball following the instructions at https://docs.ros.org/en/galactic/Inst... and it was setup to work with Python3.6 (actually contains a Python3.6 subdirectory somewhere) whereas Ubuntu has Python3.8; this prevented all Python-based ROS2 stuff from working. After mucking around with that for a while I found that someone already reported that in the ros2 GitHub issue tracker. Then I deleted that ros installation and installed the apt package instead. So there are issues with that binary distribution as well.

high12noon gravatar image high12noon  ( 2021-08-09 11:11:16 -0600 )edit

I'm not dismissing your experience, but seeing as there are thousands of installs daily of these packages, personally I always assume something is wrong locally, on my own machine, when running into problems.

The tarballs are slightly 'special', as they don't see such high numbers of installs. I guess that was ros2/ros2/issues/1167? That's now fixed. Galactic for Ubuntu was not built for Python 3.6, apparently the archive link pointed to the CentOS archive.

(as a side-note: I'm not really sure why you'd want to use those anyway on an apt managed system)

As to your other issue: report, report, report. And never assume building something from source to get a packaged version of anything working is a correct / desirable work-around.

I can confirm that the suspicious locale.h is in fact the one that is built and installed from libfmt's ...

(more)
gvdhoorn gravatar image gvdhoorn  ( 2021-08-09 11:17:38 -0600 )edit

Oh wow so that means I installed a CentOS binary on my Ubuntu system. That explains why my system ended up being so messed up! It's a wonder anything worked at all, though that explains why the Python was wrong, building didn't work, and libfmt was missing.

Anyway before I saw your newest message I decided to start with a clean slate since there were obviously deeper problems in my system, so I wiped and re-installed Ubuntu and ROS2 from apt this time, and so far everything seems to be working as advertised out of the box. Phew! That's a relief.

Oh to answer your question, the reason I used the tarball distribution rather than apt packages was that I clicked on "Installing ROS 2 on Ubuntu Linux" in the docs (this page: https://docs.ros.org/en/galactic/Inst...). I thought "Installing ROS 2 via Debian ...(more)

high12noon gravatar image high12noon  ( 2021-08-09 15:58:29 -0600 )edit
0

answered 2021-08-09 16:00:54 -0600

high12noon gravatar image

Answer: There was a mixup and the tarball labeled for Ubuntu was actually for CentOS. This sort of worked on my Ubuntu system but various parts were messed up. The tarballs have since been fixed (renamed to the correct names) and installing on Ubuntu via apt is the better way to go anyway.

edit flag offensive delete link more

Question Tools

1 follower

Stats

Asked: 2021-08-08 18:26:15 -0600

Seen: 781 times

Last updated: Aug 09 '21