LINUX.ORG.RU
Форум — Development  

Pragma once не работает

 ,


0

2

Есть заголовок:

https://github.com/fireice-uk/xmr-stak-cpu/blob/master/thdq.hpp

Есть измененные мьютексы для mingw:

https://github.com/meganz/mingw-std-threads

Я в файле thdq.hpp меняю заголовок на:

#pragma once
#undef _GLIBCXX_HAS_GTHREADS
#include <queue>
#include "mingw.thread.h"
#include "mingw.mutex.h"
#include "mingw.condition_variable.h"

В заголовок mingw.mutex.h также добавляю #pragma once

Дальше делаю:

cmake -DCMAKE_TOOLCHAIN_FILE=/home/blablabla/distfiles/cmake-toolchains/Toolchain-Ubuntu-mingw64.cmake -DMICROHTTPD_REQUIRED=OFF -DOpenSSL_REQUIRED=OFF ..
make

Выходят ошибки:

In file included from /usr/lib/gcc/x86_64-w64-mingw32/6.2-win32/include/c++/condition_variable:39:0,
                 from /home/user/xmr-stak-cpu/thdq.hpp:6,
                 from /home/user/xmr-stak-cpu/executor.h:2,
                 from /home/user/xmr-stak-cpu/cli-miner.cpp:24:
/usr/lib/gcc/x86_64-w64-mingw32/6.2-win32/include/c++/bits/std_mutex.h:132:10: error: redefinition of ‘struct std::defer_lock_t’
   struct defer_lock_t { explicit defer_lock_t() = default; };

Как правильно избавляться от этой циркулярной пилы?

★★★★★

Последнее исправление: steemandlinux (всего исправлений: 2)
← Рабочий процесс по Docker
PAM apache php →

Ты точно знаешь, что такое pragma once? Она не дает несколько раз заинклудить один и тот же файл, а не оберегает от всех возможных переопределений.

Правильно — использовать макросы. Что тоже не панацея, к слову.

buddhist ★★★★★
()
Последнее исправление: buddhist (всего исправлений: 1)
Ответ на: комментарий от steemandlinux

В https://github.com/meganz/mingw-std-threads#switching-from-the-win32-pthread-... ясно написано что с новым mingw надо выключить родные mutex через «comment out the definition of _GLIBCXX_HAS_GTHREADS»

А если успешно докопать в сторону макросов, дающих эффект pragma once - может получиться ситуация, что всё скопимлируется, но в некоторых единицах компиляции (.cpp-файлах) заиспользуется одна реализация mutex, а в некоторых другая. И тогда будет кро^Hашащийся винегрет, фу)

GPFault ★★
()
Ответ на: комментарий от Softwayer

Я переименовал mingw.mutex.h в std_mutex.h, добавил туда:

#ifndef STD_MUTEX_H
#define STD_MUTEX_H
code
#endif

Оно мне выдало тоже самое.

steemandlinux ★★★★★
() автор топика
Последнее исправление: steemandlinux (всего исправлений: 1)
Ответ на: комментарий от steemandlinux

_GLIBCXX_HAS_GTHREADS

Я undef сделал в конфиге mingw32 конечно.

Тогда по логике вещей - в используемой версии mingw что-то изменилось, и отключать встроенные мьютексы и сопровождающие структуры надо как-то иначе.

То что вы пытаетесь сделать - получится если имя оставить mingw.mutex.h, а макрос назвать также как в /usr/lib/gcc/x86_64-w64-mingw32/6.2-win32/include/c++/bits/std_mutex.h то есть _GLIBCXX_MUTEX_H

иначе получаются разные include guards, и прероцессор не пропустит один из них.

Ещё проще - вообще ни переименовывать, ни редактировать mingw.mutex.h, а просто задать ключ -D_GLIBCXX_MUTEX_H при компиляции.

Но увы: в любом случае по идее должны полезть ошибки другого типа: отсутствие какого-то объявления, поскольку ранее отключалось только то, что было под _GLIBCXX_HAS_GTHREADS, а с _GLIBCXX_MUTEX_H отключится целый заголовок.

GPFault ★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
← Рабочий процесс по Docker
Development
PAM apache php →