Closed JL2210 closed 6 years ago
Ok, I'm on gcc-7.3.0, but other than the version and machine component of paths, everything else should be the same. On my machine the c++config header is found under:
$ find /usr/local/ -name "c++config.h"
/usr/local/include/c++/7.3.0/armv7l-cros-linux-gnueabihf/bits/c++config.h
In your case, step-by-step normalisation of the include paths yields:
/usr/local/bin/../lib/gcc/x86_64-pc-linux-gnu/8.2.0/../../../../include/c++/8.2.0/stdlib.h
/usr/local/lib/gcc/x86_64-pc-linux-gnu/8.2.0/../../../../include/c++/8.2.0/stdlib.h
/usr/local/include/c++/8.2.0/stdlib.h
That should be normally the g++-provided component of stdlib.h. The latter, on its turn, should try to load the cstdlib from
/usr/local/include/c++/8.2.0/cstdlib
To this step both our setups are in agreement. Let me think what might be happening next -- I'll get back to you later.
@JL2210: Let's do the following test. Make a minimal c++ TU that includes stdlib.h, like this:
$ echo "#include <stdlib.h>" > test.cpp
Now, build that via your g++-8.2.0 with high verbosity, and take note of the include paths. Here's what it looks like for my g++-7.3.0:
$ g++ test.cpp -v -c
...
#include "..." search starts here:
#include <...> search starts here:
/usr/local/lib/gcc/armv7l-cros-linux-gnueabihf/7.3.0/../../../../include/c++/7.3.0
/usr/local/lib/gcc/armv7l-cros-linux-gnueabihf/7.3.0/../../../../include/c++/7.3.0/armv7l-cros-linux-gnueabihf
/usr/local/lib/gcc/armv7l-cros-linux-gnueabihf/7.3.0/../../../../include/c++/7.3.0/backward
/usr/local/lib/gcc/armv7l-cros-linux-gnueabihf/7.3.0/include
/usr/local/include
/usr/local/lib/gcc/armv7l-cros-linux-gnueabihf/7.3.0/include-fixed
/usr/include
End of search list.
...
Repeat the same but with the clang++.sh wrapper:
$ ./clang++.sh test.cpp -v -c
...
#include "..." search starts here:
#include <...> search starts here:
/usr/local/include/c++/7.3.0/armv7l-cros-linux-gnueabihf
/usr/local/include/c++/7.3.0
/usr/local/include
/usr/local/lib/clang/6.0.0/include
/usr/include
End of search list.
How does that look like in your case?
Sorry. GCC broke just a minute ago. I am recompiling now. I'll get back to you when I'm done.
It works now; but this error shows up:
unspecified framebuffer bitness; bailing out
Here's the full log:
chronos@localhost ~/Downloads/misc/hello-chromeos-gles2 $ ./build_chromeos_skinning.sh && ./build_chromeos_sphere.sh && ./build_chromeos_sphere_multi.sh
./clang++.sh -o test_egl_skinning -std=c++11 -pipe -fno-exceptions -fno-rtti -fstrict-aliasing -Wreturn-type -Wunused-variable -Wunused-value -DPLATFORM_GLES -DPLATFORM_GL_OES_vertex_array_object -I./khronos -march=native -mtune=native -ffast-math -funroll-loops -O3 -DNDEBUG main_chromeos.cpp app_skinning.cpp rendSkeleton.cpp util_tex.cpp util_file.cpp util_misc.cpp gles_ext.cpp -fuse-ld=lld -lwayland-client -lrt -ldl -lEGL -lGLESv2 -lpng16
main_chromeos.cpp:1406:14: warning: unused variable 'grab_filename' [-Wunused-variable]
const char* grab_filename = param.grab_filename;
^
main_chromeos.cpp:1405:17: warning: unused variable 'grab_frame' [-Wunused-variable]
const unsigned grab_frame = param.grab_frame;
^
2 warnings generated.
./clang++.sh -o test_egl_sphere -std=c++11 -pipe -fno-exceptions -fno-rtti -fstrict-aliasing -Wreturn-type -Wunused-variable -Wunused-value -DPLATFORM_GLES -DPLATFORM_GL_OES_vertex_array_object -I./khronos -march=native -mtune=native -ffast-math -funroll-loops -O3 -DNDEBUG main_chromeos.cpp app_sphere.cpp util_tex.cpp util_file.cpp util_misc.cpp gles_ext.cpp -fuse-ld=lld -lwayland-client -lrt -ldl -lEGL -lGLESv2 -lpng16
main_chromeos.cpp:1406:14: warning: unused variable 'grab_filename' [-Wunused-variable]
const char* grab_filename = param.grab_filename;
^
main_chromeos.cpp:1405:17: warning: unused variable 'grab_frame' [-Wunused-variable]
const unsigned grab_frame = param.grab_frame;
^
2 warnings generated.
./clang++.sh -o test_egl_sphere_multi -std=c++11 -pipe -fno-exceptions -fno-rtti -fstrict-aliasing -Wreturn-type -Wunused-variable -Wunused-value -DPLATFORM_GLES -DPLATFORM_GL_OES_vertex_array_object -I./khronos -march=native -mtune=native -ffast-math -funroll-loops -O3 -DNDEBUG main_chromeos.cpp app_sphere_multi.cpp util_tex.cpp util_file.cpp util_misc.cpp gles_ext.cpp -fuse-ld=lld -lwayland-client -lrt -ldl -lEGL -lGLESv2 -lpng16
main_chromeos.cpp:1406:14: warning: unused variable 'grab_filename' [-Wunused-variable]
const char* grab_filename = param.grab_filename;
^
main_chromeos.cpp:1405:17: warning: unused variable 'grab_frame' [-Wunused-variable]
const unsigned grab_frame = param.grab_frame;
^
2 warnings generated.
chronos@localhost ~/Downloads/misc/hello-chromeos-gles2 $ ./test_egl_skinning ; ./test_egl_sphere ; ./test_egl_sphere_multi
unspecified framebuffer bitness; bailing out
unspecified framebuffer bitness; bailing out
unspecified framebuffer bitness; bailing out
chronos@localhost ~/Downloads/misc/hello-chromeos-gles2 $
This is with sommelierd running.
You need to specify a pixel format via the -bitness
CLI -- it's mandatory for now, and it effectively needs to be "8 8 8 8" -- i.e. RGBA8888, as otherwise you'd get a serious performance hit (due to a shortcut in the presentation pipeline; I'm working on a proper EGL->wayland transfer ATM). RE sommelierd -- I don't think it matters as the code uses wayland and EGL throughout.
So, I run, for example, ./test_egl_skinning -bitness 8 8 8 8
?
Wow!
@JL2210: it's just a unittest of a skeletal system. Once I'm done with the frameloop (not the current hack) there will be a tad more complex things to show ; )
Not sure if this is just me, but the header file
<bits/c++config.h>
is missing. Help?