0.12.0 can't build on Ubuntu16.04 LTS

[zhangew]

Hi,
I'v checked some posts, it might be caused by old gcc version. But I'm not sure about it, because 0727's nightly release built(of_v20230727_linuxaarch64_release.tar.gz), so I'll post my error messages here.

OF: 0.12.0 of_v0.12.0_linuxaarch64_release.tar.gz
Hardware: linux aarch64
OS: Ubuntu 16.04LTS
GCC: 5.4

Error message: (To save length, I drew one compiling command and part of output here, rather than put all ouput of make):

Command:

g++ -g3 -DDEBUG -Wall -Werror=return-type -DGCC_HAS_REGEX -std=c++17 -march=armv8-a -mcpu=cortex-a72 -mtune=cortex-a72 -fPIC -ftree-vectorize -Wno-psabi -pipe -DOF_USING_GTK -DOF_USING_GTK -DOF_USING_MPG123 -D_REENTRANT -pthread -I/usr/include/gstreamer-1.0 -I/usr/lib/aarch64-linux-gnu/gstreamer-1.0/include -I/usr/include/AL -I/usr/include/alsa -I/usr/include/gtk-3.0 -I/usr/include/at-spi2-atk/2.0 -I/usr/include/at-spi-2.0 -I/usr/include/dbus-1.0 -I/usr/lib/aarch64-linux-gnu/dbus-1.0/include -I/usr/include/gtk-3.0 -I/usr/include/gio-unix-2.0/ -I/usr/include/mirclient -I/usr/include/mircore -I/usr/include/mircookie -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/harfbuzz -I/usr/include/pango-1.0 -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libpng12 -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/libpng12 -I/usr/include/glib-2.0 -I/usr/lib/aarch64-linux-gnu/glib-2.0/include -I/usr/include/libdrm -I/home/zew/OF/libs/glm/include -I/home/zew/OF/libs/glm/include/glm -I/home/zew/OF/libs/glm/include/glm/simd -I/home/zew/OF/libs/glm/include/glm/gtx -I/home/zew/OF/libs/glm/include/glm/gtc -I/home/zew/OF/libs/glm/include/glm/ext -I/home/zew/OF/libs/glm/include/glm/detail -I/home/zew/OF/libs/json/include -I/home/zew/OF/libs/kiss/include -I/home/zew/OF/libs/tess2/include -I/home/zew/OF/libs/utf8/include -I/home/zew/OF/libs/utf8/include/utf8 -I/home/zew/OF/libs/openFrameworks -I/home/zew/OF/libs/openFrameworks/gl -I/home/zew/OF/libs/openFrameworks/events -I/home/zew/OF/libs/openFrameworks/communication -I/home/zew/OF/libs/openFrameworks/types -I/home/zew/OF/libs/openFrameworks/graphics -I/home/zew/OF/libs/openFrameworks/video -I/home/zew/OF/libs/openFrameworks/3d -I/home/zew/OF/libs/openFrameworks/math -I/home/zew/OF/libs/openFrameworks/app -I/home/zew/OF/libs/openFrameworks/utils -I/home/zew/OF/libs/openFrameworks/sound -Wall -Werror=return-type -DGCC_HAS_REGEX -std=c++17 -MMD -MP -MF /home/zew/OF/libs/openFrameworksCompiled/lib/linuxaarch64/obj/Debug/libs/openFrameworks/gl/ofBufferObject.d -MT/home/zew/OF/libs/openFrameworksCompiled/lib/linuxaarch64/obj/Debug/libs/openFrameworks/gl/ofBufferObject.o -o /home/zew/OF/libs/openFrameworksCompiled/lib/linuxaarch64/obj/Debug/libs/openFrameworks/gl/ofBufferObject.o -c /home/zew/OF/libs/openFrameworks/gl/ofBufferObject.cpp

Ouput: (very lot like below)

/home/zew/OF/libs/openFrameworks/utils/ofRandomDistributions.h: In function ‘T of::of::of::{anonymous}::ofRandomExponential(Args&& ...)’:
/home/zew/OF/libs/openFrameworks/utils/ofRandomDistributions.h:620:52: error: ‘of::of::of::random’ has not been declared
T ofRandomExponential(Args&&... args) { return of::random::exponential(std::forward(args)...); }
^
/home/zew/OF/libs/openFrameworks/utils/ofRandomDistributions.h:620:73: error: expected primary-expression before ‘>’ token
T ofRandomExponential(Args&&... args) { return of::random::exponential(std::forward(args)...); }
^
/home/zew/OF/libs/openFrameworks/utils/ofRandomDistributions.h:620:99: error: expected ‘)’ before ‘...’ token
T ofRandomExponential(Args&&... args) { return of::random::exponential(std::forward(args)...); }
^
/home/zew/OF/libs/openFrameworks/utils/ofRandomDistributions.h:620:102: error: parameter packs not expanded with ‘...’:
T ofRandomExponential(Args&&... args) { return of::random::exponential(std::forward(args)...); }
^
/home/zew/OF/libs/openFrameworks/utils/ofRandomDistributions.h:620:102: note: ‘args’
/home/zew/OF/libs/openFrameworks/utils/ofRandomDistributions.h:620:102: note: ‘Args’
/home/zew/OF/libs/openFrameworks/utils/ofRandomDistributions.h: In function ‘T of::of::of::{anonymous}::ofRandomExponential(T)’:
/home/zew/OF/libs/openFrameworks/utils/ofRandomDistributions.h:623:46: error: ‘of::of::of::random’ has not been declared
T ofRandomExponential(T lambda) { return of::random::exponential(lambda); }
^
/home/zew/OF/libs/openFrameworks/utils/ofRandomDistributions.h:623:67: error: expected primary-expression before ‘>’ token
T ofRandomExponential(T lambda) { return of::random::exponential(lambda); }
^
/home/zew/OF/libs/openFrameworks/utils/ofRandomDistributions.h: In function ‘T of::of::of::{anonymous}::ofRandomChiSquared(Args&& ...)’:
/home/zew/OF/libs/openFrameworks/utils/ofRandomDistributions.h:626:51: error: ‘of::of::of::random’ has not been declared
T ofRandomChiSquared(Args&&... args) { return of::random::chi_squared(std::forward(args)...); }

If the message is not enough, I can post more output infomation.

Thanks a lot!

[ofTheo]

Hi, thanks for this!!

I'll add @artificiel but I think the issue here is that the gcc version is too old and is missing some of the requirements from ofRandomDistributions.h

A 'simple' fix could be to #ifdef the file based on gcc version or C++17 availability.
Or for your case, simply to comment out the file. 🙂

However we are also trying to transition to C++17 minimum requirement for the next release and that would probably require Ubuntu 18.04 or 20.04 as a minimum.

[zhangew]

Hi ofTheo,
Thank you for your kind reply.
I'll try to update my GCC first, and if there is any progress, I'll post it here.
And thank you for telling me the plan about minimum Linux version requirement! Thus I can prepare for the new situation.

[artificiel]

@ofTheo random per se is C++11, but the DCLP thread-safe locking in the Singleton implementation is C++17 (I now realize that's probably where my question about 0.12 C++ version was coming from...). There is a C++11 implementation with a slower lock, perhaps it would make sense to use it for now (the only built-in thing actually making use of it is ofRandomShuffle, of which the use does probably not suffer from a few extra cycles) and reintroduce the better C++17 next? I think that DCLP would be required for the general ofRandom upgrade to non-srand, as those calls (engine access) can happen often (my semi-scientific benchmark shows a similar performance between plain calls and DCLP on i7 and M1).

@zhangew but to be sure, can you post the complete error log? because the explicit complains are about templates/namespaces maybe there is something else going on.

[artificiel]

spoke too soon: the thread-safe singleton is only available in C++17; previous it's a classic static, which in itself is not worse than srand (which is not thread-safe either).

but using the static singleton is not a direct swap as it does not support ::construct() and ::destruct() — we're back to an old-school pointer management, which cannot be as cleanly exposed.

thinking outloud, it seems a bit "sad" to backtrack this safety (threads and pointer) in order to support a 2016 platform? a similar discussion happened vs macOS versions — where is the line drawn? for example if we want to support ubuntu LTS it's no C++17 until 2026 which is limiting to say the least...

[ofTheo]

Ahh, well I think if it is remotely tricky we shouldn't try and back port it. I think you can install newer GCC on 16.04 and I think 18.04 supports gcc 8.3 which has full C++17 support.

So maybe will close for now but will make a note on the Setup Guide that we should add minimum OS version / GCC version for each platform. #7625

[artificiel]

OK but that "sort of means" 0.12 is C++17...

[ofTheo]

Ha! that's fine I think 😆

[dimitre]

I vote for one more release compatible with c++14 / 11,
so we can have the go to release if compiling for older machines is needed.
Not dealing with 0.11.2 release
Motivation: upcycling machines for installations.
I've used the same machine and software for more than 10 years in a club, running an OF project.
So soon after a new functional release we can explicitely turn c++17 or newer. what do you think?

[ofTheo]

@dimitre I think the problem is that would require reverting the ofRandomize fix ( #7598 ).

If there is an elegant backwards compatible solution that allows for C++11/14 fallback but preserves #7598 I'm happy to bring that in but I think GitHub main/master will quickly switch to C++17 only ( as we drop boost ), so it would have to be a patch release based 0.12.0.

I'm sure we'll have a 0.12.1 but it def shouldn't revert new features.

Not sure if that makes sense? But happy if it's an easy fix.

[artificiel]

the only easy fix is see would be to remove #7598 altogether and apply #7572 -- which is local and inefficient, as the engine is constantly rebuilt, but I suspect there is very little ofRandomShuffle action going at high rate).

then we reapply and do in 1 update the real upgrade:

• make random seedable and threadsafe ofRandom #7598
• expose as much as possible of std::random* including ofRandomWrappers() ofRandom #7598
• remove srand from ofRandom etc #TBD

the intermediate would be to have a non-thread-safe random engine wrapper (much like srand is currently) but because of the way I made use of the explicit ::construct()/::destruct() of the instance it requires a bit more thought.

[zhangew]

Hi @artificiel,
Sorry for late. Please see the attached, thanks!
of12builderror.txt

[artificiel]

ah... this chokes on "nested namespaces" which is a C++17 feature gcc since 9.0: https://gcc.gnu.org/projects/cxx-status.html

as this only syntactic sugar it could easily be converted to normal nesting (multiple { { } } ) but it will then choke on std::shared_mutex, which requires gcc 6.1 and inline static variables with require 7.0

can you update gcc at least to 7.0 within 16.04LTS? if so, we could try changing the namespace syntax — or even maybe 9?

otherwise as stated above making a "clean" switch between C++11 and C++17 without simply rolling back and patching ofRandomShuffle() (the trigger of this overhaul) would require more than a simple #ifdef because of the manner the unique (thread safe) engine is currently instantiated.

[zhangew]

ah... this chokes on "nested namespaces" which is a C++17 feature gcc since 9.0: https://gcc.gnu.org/projects/cxx-status.html

as this only syntactic sugar it could easily be converted to normal nesting (multiple { { } } ) but it will then choke on std::shared_mutex, which requires gcc 6.1 and inline static variables with require 7.0

can you update gcc at least to 7.0 within 16.04LTS? if so, we could try changing the namespace syntax — or even maybe 9?

otherwise as stated above making a "clean" switch between C++11 and C++17 without simply rolling back and patching ofRandomShuffle() (the trigger of this overhaul) would require more than a simple #ifdef because of the manner the unique (thread safe) engine is currently instantiated.

Hi artificiel,
Sorry for late. Thanks for your help.
I understand. Maybe I have to make a choice between current and newer gcc.