Загадочная «error: 'mutex' in namespace 'std' does not name a type»

Засада может быть в версии компилятора и gch

А если подсунуть компилятору такой файл?

#include <mutex>

void foo()
{
    std::mutex m;
}

Где может быть засада?

Ну начни с простого. Как например:

Может быть какой-то дефайн, который внутри mutex/mutex.h что-то выключает.

Попробуй дополнительно

#error "<mutex> included"
#include <mutex>

Гм.

> g++ -std=c++17 -o test test.cpp
test.cpp: В функции <<void foo()>>:
test.cpp:5:5: ошибка: <<mutex>> не является элементом <<std>>
     std::mutex m;
     ^~~
> g++ -std=c++11 -o test test.cpp
test.cpp: В функции <<void foo()>>:
test.cpp:5:5: ошибка: <<mutex>> не является элементом <<std>>
     std::mutex m;
     ^~~
> g++ -std=c++98 -o test test.cpp
In file included from /usr/include/c++/6.2.0/mutex:35:0,
                 from test.cpp:1:
/usr/include/c++/6.2.0/bits/c++0x_warning.h:32:2: ошибка: #error This file requires compiler and library support for the ISO C++ 2011 standard. This support must be enabled with the -std=c++11 or -std=gnu++11 compiler options.
 #error This file requires compiler and library support \
  ^~~~~
test.cpp: В функции <<void foo()>>:
test.cpp:5:5: ошибка: <<mutex>> не является элементом <<std>>
     std::mutex m;
     ^~~
> cat test.cpp
#include <mutex>

void foo()
{
    std::mutex m;
}

> g++ -std=c++11 -o test test.cpp
> cat test.cpp
#define _GLIBCXX_HAS_GTHREADS 1
#include <mutex>

void foo()
{
    std::mutex m;
}

int main(){
        return 0;
}

Попробуй собрать в однопоточном режиме, под strace. Получи командную строку сборки. Попробуй воспроизвести на одном модуле.

Если не выйдет - значит дело в переменных окружения выставляемых в процессе сборки.

О! Ты воспроизвёл.

А флаг -pthread тоже добавил?

А версия стандартной библиотеки какая? Подозреваю что он хеадеры тащит из какой-то устаревшей libstdc++... А когда ты ему включаешь c++11 - то тут ему подходит. Проверь откуда он подключает заголовки (тот же mutex).

> g++ -std=c++17 test test.cpp -pthread
test.cpp: В функции <<void foo()>>:
test.cpp:5:5: ошибка: <<mutex>> не является элементом <<std>>
     std::mutex m;
     ^~~

Там проблема не в "-pthread". _GLIBCXX_HAS_GTHREADS, по ходу, определяется в «bits/c++config.h». Однако прописывание строчки туда совсем не помогает. А вот прописывание строчки в исходник перед включением <mutex> помогает.

Помогает/непомогает, это не гомеопатия:)

_GLIBCXX_HAS_GTHREADS это костыль, его работа свидетельствует либо о баге в компиляторе либо в окружении.

На вскидку - хидер файлы pthreads у тебя в системе установлены?

Что кстати за дистрибутив? Был ли установлен pthreads-devel при сборке gcc?

glibc 2.24.

> ls -l /usr/lib/libstdc++.so
lrwxrwxrwx 1 root root 19 сен 17 18:49 /usr/lib/libstdc++.so -> libstdc++.so.6.0.22

/* Define if gthreads library is available. */
/* #undef _GLIBCXX_HAS_GTHREADS */

> find /usr/lib/ -iname 'libgthreads*'
> find /lib/ -iname 'libgthreads*'
>

если добавить в системный «bits/c++config.h», то не помогает.
вот прописывание строчки в исходник перед включением

Эм, я на всякий случай - у компиля есть опция -D.

Так можно и в исходник прописать. Но, это не меняет того, что эта опция должна читаться из файла «bits/c++config.h». И там оно таки выключено.

впиши ошибку в этот (тот который ты думаешь что включается) файл.

А ещё лучше, посмотри на сорец после препроцессора.

Это не костыль, а опция. При сборке GCC и libstdc++ опции пишутся в «bits/c++config.h». Дистрибутив - LFS. Всё собрано как положено.

> ls -i /lib/libpthread*
804251 /lib/libpthread-2.24.so  809250 /lib/libpthread.so.0
> ls -l /usr/include/pthread.h
-rw-r--r-- 1 root root 41225 окт  3 23:09 /usr/include/pthread.h

Это не костыль, а опция.

Это опция не для end user'ов. А использование её в явном виде это костыль.

Хз насчёт как положенно - у меня g++ на патч версию старше - и умвр :)

Попробуй gcc 6.2.1 собрать, может действительно бага была. Но, я почти уверен, что где то у тебя окружение сломанно. Может конфиг какой при сборке gcc был пропущен.

Почитай всё таки выхлоп препроцессора, может что-то сразу станет ясно.

В первую очередь я бы попробовал 6.2.1 т.к. это тупая, механическая работа которую довольно быстро провернуть.

Что толку на всё это смотреть? После препроцессора тонны разных «struct __pthread_mutex_s», «extern int pthread_mutex_init (pthread_mutex_t *__mutex,»,... и т.д., но сути это не меняет - в namespace std никакие mutex'ы не приходят. Потому, что так написано в «bits/c++config.h».

ls -l /usr/lib/libstdc++.so

Я про хеадеры спрашивал. На данном этапе сборки шаред либы не используются вообще.

Например у меня в системе есть:

% ls /usr/include/c++/5/mutex 
/usr/include/c++/5/mutex
% ls /usr/include/c++/4.8/mutex
/usr/include/c++/4.8/mutex

Ну, там ещё в комментах пишутся файлы откуда это всё берётся, как минимум.

Ты чукча не умничай, ты команду дай :D

for d in $(sudo find /usr/ -path '*include/c++' -exec echo {} \;);\
 do find $d -name 'mutex' -exec echo {} \; | \
sed "s|.*c++/\([^/]*\).*|\1|g"; \
done | sort | uniq

Ведь:

Дистрибутив - LFS

# for d in $(find /usr/ -path '*include/c++' -exec echo {} \;); do find $d -name 'mutex' -exec echo {} \; | sed "s|.*c++/\([^/]*\).*|\1|g"; done | sort | uniq
6.2.0
# ls /usr/include/c++/
6.2.0
#

Всё устанавливалось и обновлялось правильно.

Тут надо понять о какой «gthreads library» идёт речь в комментариях. Может, действительно, либо надо собирать со специфическими опциями, либо должна быть задействована ещё какая-то дополнительная библиотека. По названию оно похоже на «libgthread-2.0.so» (из glib), но это как-то подозрительно. А больше нагуглить с одного захода не так-то и просто...

По названию оно похоже на «libgthread-2.0.so» (из glib), но это как-то подозрительно.

Так дело до линкера не доходит. Попробуйте 6.2.1 собрать.

gthreads (не путать с gthread) - это библиотека абстракции от потоков из состава libgcc, используется реализацией std::mutex из libstdc++.

Если символ _GLIBCXX_HAS_GTHREADS в bits-ах libstdc++ не определен, то libgcc была собрана без поддержки потоков. Определять ее в приложении бессмысленно - слинкуется с пустой реализацией в libgcc, в которой lock/unlock ничего не делают, и мьютексы не будут ничего мьютексить.

Скорее всего, GCC был собран неправильно: наличие потоков определяется опцией --enable-threads. --enable-threads=single или no выбирают однопоточную модель (которая выбрана у вас), --enable-threads=posix выбирает pthreads. Отсутствие опции выбирает автоопределение. Автоопределение выберет posix, если сможет найти pthreads.h, или молча выберет single, если не найдет.

Рекомендую попробовать пересобрать GCC с явной опцией --enable-threads=posix. Он выдаст ошибку в процессе сборки, если не найдет pthreads, и тогда уже можно будет разбираться.

Как правило, такое бывает, когда перед сборкой GCC в sysroot (или корень, если это не кросс) были установлены не все заголовки от libc. Вполне может быть, что сейчас все заголовки на месте, сборка пройдет с ключом и с новым компилятором все заработает.

Всё собрано как положено.

LFS по книжке

Не знаю, не знаю...

наличие потоков определяется опцией --enable-threads.
Не знаю, не знаю...

По книжке положено так:

SED=sed                               \
../configure --prefix=/usr            \
             --enable-languages=c,c++ \
             --disable-multilib       \
             --disable-bootstrap      \
             --with-system-zlib

--enable-threads=posix

OK, попробую.

Не знаю где люди берут 6.2.1, на официальном сайте и зеркалах только 6.2.0. Добавил патчей gcc-6.2.0-patches-1.1.tar.bz2 из репозитория Генты. Собирается как 6.2.0.

Пересобрал с "--enable-threads=posix". Всё собралось без ошибок, и GCC, и libstdc++. Ситуация осталась прежней.

> gcc -help -v 2>&1 | grep многопоточн
Модель многопоточности: posix
> gcc -o test test.cpp
test.cpp: В функции <<void foo()>>:
test.cpp:5:5: ошибка: <<mutex>> не является элементом <<std>>
     std::mutex m;
     ^~~

Я конечно не уверен, т.к. мой gcc собран не мной, но смею предположить что делается это примерно так:

svn checkout svn://gcc.gnu.org/svn/gcc/trunk

Лучше просто посмотреть результат препроцессинга, откуда что берется, заодно и ошибка может найтись

http://saahriktu.org/tmp/test.lzma . Если не знать что именно нужно там искать, то выглядит всё вполне нормально.

development версии всегда бажные. Если уж так, то можно собрать сразу gcc-7-20161002, чего уж мелочиться.

Ну trunk это не совсем development версия. Хотя это зависит от процесса разработки, с коим в случае gcc я не знаком.

Посмотри в сорцах системы сборки на основе чего выставляется _GLIBCXX_HAS_GTHREADS.

Ибо диф с компилирующейся версией показывает что включения мьютекса контролируется только этим флагом.

Гм. Разбирая исходники вперемешку с уже собранными бинарниками и другими файлами GCC нашёл файл «build/x86_64-pc-linux-gnu/libstdc++-v3/include/x86_64-pc-linux-gnu/bits/c++config.h», где всё было включено. Скопировал его руками:

# cp build/x86_64-pc-linux-gnu/libstdc++-v3/include/x86_64-pc-linux-gnu/bits/c++config.h /usr/include/c++/6.2.0/bits/

> gcc -std=c++11 -o test test.cpp
> cat test.cpp
#include <mutex>

void foo()
{
    std::mutex m;
}

int main(){
        return 0;
}
>

В сборке pilfs, кстати, такой проблемы не было и нет. В т.ч. и с GCC 6.2.

Заработало прямо так что и мьютексы лочатся? Или просто скомпилировалось?

А на каком примере можно проверить?

Пришлось ещё добавить

cp build/x86_64-pc-linux-gnu/libstdc++-v3/src/.libs/libstdc++.so* /usr/lib/

> g++ -o test3 test3.cpp -pthread
> ./test3
thread #2
thread #1
thread #8
thread #4
thread #5
thread #7
thread #6
thread #3
thread #9
thread #10
> cat test3.cpp
// mutex::lock/unlock
#include <iostream>       // std::cout
#include <thread>         // std::thread
#include <mutex>          // std::mutex

std::mutex mtx;           // mutex for critical section

void print_thread_id (int id) {
  // critical section (exclusive access to std::cout signaled by locking mtx):
  mtx.lock();
  std::cout << "thread #" << id << '\n';
  mtx.unlock();
}

int main ()
{
  std::thread threads[10];
  // spawn 10 threads:
  for (int i=0; i<10; ++i)
    threads[i] = std::thread(print_thread_id,i+1);

  for (auto& th : threads) th.join();

  return 0;
}

А как этот пример подтверждает, что мьютекс работает?

std::mutex mtx; // mutex for critical section
mtx.lock();
mtx.unlock();

Или это не оно?

Или это не оно?

Оно, только что поменяется в поведении приложения, если вы закомментируете lock/unlock?

Вот что:

> ./test3
thread #1
thread #3
thread #7
thread #2
thread #thread #6
thread #4
thread #9
thread #10
thread #8
5

Значит мьютекс работал.

или просто звёзды удачно сложились

Сделай deadlock или посмотри на вывод под strace.

Ну, похоже что оно работает, хм. А либу ты тоже ведь руками копировал.

Очень странно. Можно, видимо, даже багу завести. Только по хорошему для этого нужен «чистый» lfs, что довольно таки невероятно.

Да, но теперь через всё работает и через «make install». И я, кажется, понял как всё было. Ошибкой было думать, что libstdc++ не собирается и не устанавливается вместе с GCC (а в начале книги отдельным пунктом описана сборка и установка конкретно libstdc++ во временную систему (а в прежние времена она ещё и существовала отдельно от GCC)). Получается, я дополнительными лишними шагами некорректно пересобирал её поверх правильной сборки, устанавливал эту версию вообще без std::mutex и std::thread в систему, а основные скрипты поверх этого спотыкались. Но, стоило только опять правильно собрать поверх, как всё работает и через скрипты.

В общем, по ходу, в этом и заключается «local issue» ошибки.

Пометь как решёную что ли напиши сий вывод в хэдпосте?

Пометил. Но, время редактирования стартового поста, по ходу, истекло.