Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

lock_guard mutex code fails to build under GCC 12 #6678

Closed
djnotes opened this issue Mar 18, 2023 · 2 comments
Closed

lock_guard mutex code fails to build under GCC 12 #6678

djnotes opened this issue Mar 18, 2023 · 2 comments
Labels

Comments

@djnotes
Copy link
Contributor

djnotes commented Mar 18, 2023

Bug Summary

There are many usages of lock_guard in LMMS (specifically in ZynAddSubFx plugin AFAIK), that fail to compile under GCC 12 (C++ 12).
The current usage is like this:

const auto lock = std::lock_guard{m_master->mutex};

which can be resolved (maybe stupidly) by changing it to:

const auto lock(m_master->mutex);

but, it should probably be like:

const std::lock_guard<std::mutex> lock(m_master->mutex);

according to lock_guard, which raises syntax error "no instance of constructor "std::lock_guard<_Mutex>::lock_guard [with _Mutex=std::mutex]" matches the argument listC/C++(289)".

Looks like the correct way is:

const std::lock_guard<pthread_mutex_t> lock{m_master->mutex};

Which, after making the change, gives the same error you see in the logs (std::lock_guard<pthread_mutex_t>::mutex_type’ {aka ‘union pthread_mutex_t’} has no member named ‘lock’).

Sorry for my rusty C++ and I have no idea what the curly braces after lock do, but it seems to be OK with the linter.

Is LMMS supposed to be built with an old compiler or does the mutex code need to be re-written?

Steps to reproduce

Make folder build and move to it. Then run cmake .. followed by cmake -j $(nproc)

Expected behavior

Successful build

Actual behavior

Fails at around 95% of build around building the plugin ZynAddSubFx. Error is the following:

Screenshot

Screenshot from VSCode 1.76.1 on Fedora 37.

image

Affected LMMS versions

Latest master branch

Logs

Click to expand
#Here's the build log. The error part with some pre-error build log is included only
[ 92%] Built target pitch_scale_1194
[ 92%] Built target sc1_1425
[ 92%] Built target pitch_scale_1193
[ 92%] Built target sc2_1426
[ 93%] Built target sc4_1882
[ 93%] Built target sc3_1427
[ 93%] Built target sc4m_1916
[ 93%] Built target se4_1883
[ 94%] Built target vstbase
[ 94%] Built target lmms
[ 94%] Built target vsteffect
[ 94%] Built target vestige
In file included from /usr/include/c++/12/mutex:43,
                 from /home/mehdi/src/lmms/plugins/ZynAddSubFx/zynaddsubfx/src/Misc/Util.h:27,
                 from /home/mehdi/src/lmms/plugins/ZynAddSubFx/LocalZynAddSubFx.cpp:43:
/usr/include/c++/12/bits/std_mutex.h: In instantiation of ‘std::lock_guard<_Mutex>::lock_guard(mutex_type&) [with _Mutex = pthread_mutex_t; mutex_type = pthread_mutex_t]’:
/home/mehdi/src/lmms/plugins/ZynAddSubFx/LocalZynAddSubFx.cpp:145:52:   required from here
/usr/include/c++/12/bits/std_mutex.h:229:19: error: ‘std::lock_guard::mutex_type’ {aka ‘union pthread_mutex_t’} has no member named ‘lock’
  229 |       { _M_device.lock(); }
      |         ~~~~~~~~~~^~~~
/usr/include/c++/12/bits/std_mutex.h: In instantiation of ‘std::lock_guard<_Mutex>::~lock_guard() [with _Mutex = pthread_mutex_t]’:
/home/mehdi/src/lmms/plugins/ZynAddSubFx/LocalZynAddSubFx.cpp:145:52:   required from here
/usr/include/c++/12/bits/std_mutex.h:235:19: error: ‘std::lock_guard::mutex_type’ {aka ‘union pthread_mutex_t’} has no member named ‘unlock’
  235 |       { _M_device.unlock(); }
      |         ~~~~~~~~~~^~~~~~
make[2]: *** [plugins/ZynAddSubFx/CMakeFiles/ZynAddSubFxCoreObjs.dir/build.make:76: plugins/ZynAddSubFx/CMakeFiles/ZynAddSubFxCoreObjs.dir/LocalZynAddSubFx.cpp.o] Error 1
make[1]: *** [CMakeFiles/Makefile2:6873: plugins/ZynAddSubFx/CMakeFiles/ZynAddSubFxCoreObjs.dir/all] Error 2
make: *** [Makefile:156: all] Error 2
@djnotes djnotes added the bug label Mar 18, 2023
@PhysSong
Copy link
Member

PhysSong commented May 18, 2023

Have you updated submodules by git submodule update --init --recursive? Sounds similar like #6704.

@djnotes
Copy link
Contributor Author

djnotes commented May 18, 2023

Done. Fixed. Thanks

@djnotes djnotes closed this as completed May 18, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants