i'm trying to compile a Linux image with sysroot and cross-compiler by buildroot for ATSAMA5D27-WLSOM1 evaluation kit by Microchip.
I'm on a virtual machine (VBox) with Ubuntu 18.04.5 LTS.
I'm following this guide: https://microchip.wikidot.com/32mpu:egt-prepare#prepHost
I arrived at point 6, but there are some errors in compilation, the one I can't solve is the following one:
In file included from /home/ubuntu4sam/buildroot/output/host/lib/gcc/arm-buildroot-linux-gnueabihf/10.3.0/include-fixed/pthread.h:42,
from work_thread.c:13:
work_thread.c:45:58: error: missing binary operator before token "("
45 | #if defined (PTHREAD_STACK_MIN) && THREAD_MINSTACKSIZE < PTHREAD_STACK_MIN
| ^~~~~~~~~~~~~~~~~
I tried to comment the second condition (THREAD_MINSTACKSIZE < PTHREAD_STACK_MIN) and the error becomes:
work_thread.c:45:58: error: missing binary operator before token "("
45 | #if defined (PTHREAD_STACK_MIN)
so the problem must be PTHREAD_STACK_MIN. I hope someone else has worked on Microchip boards.
Thanks for reading.
Related
I'm trying to compile Cobalt and getting errors building cpu_features_get.cc. The specific version I'm building is here: https://github.com/Metrological/cobalt/blob/master/src/starboard/shared/linux/cpu_features_get.cc and it appears to be based on Cobalt 22. I'm building using stbgcc-6.3.18, only Ubuntu 20.04. Sysroot is set to the cross compiler. And I'm building the starboard port at https://github.com/Metrological/cobalt/tree/master/src/third_party/starboard/wpe/brcm/arm, for ARM64.
An example of the error:
cpu_features_get.cc:381:12: error: 'HWCAP_SET_FOR_ARMV8' was not declared in this scope
There follow others, all related to HWCAP #defines.
As far as I can tell, the file defines these values if:
53: #if SB_IS(32_BIT) || defined(ANDROID)
Neither of these is true - I am compiling for ARM64 on Linux.
The code using HWCAP_SET_FOR_ARMV8 and the other missing defines is conditionally compiled as well:
340: #if SB_IS(ARCH_ARM) || SB_IS(ARCH_ARM64)
...
// Construct hwcap bitmask by the feature flags in /proc/cpuinfo
uint32_t ConstructHwcapFromCPUInfo(ProcCpuInfo* cpu_info,
int16_t architecture_generation,
uint32_t hwcap_type) {
if (hwcap_type == AT_HWCAP && architecture_generation >= 8) {
// This is a 32-bit ARM binary running on a 64-bit ARM64 kernel.
// The 'Features' line only lists the optional features that the
// device's CPU supports, compared to its reference architecture
// which are of no use for this process.
SB_LOG(INFO) << "Faking 32-bit ARM HWCaps on ARMv"
<< architecture_generation;
return HWCAP_SET_FOR_ARMV8;
}
...
...
So ARCH_ARM64 is true, and this code is compiled. But the defines are missing because it's not 32-bit. This seems contradictory and to my eyes could never have worked. How is it possible to compile Cobalt for ARM64?
I am using the latest Mac M1 pro (ARM) machine and was trying to install mediapipe as per this tutorial - https://google.github.io/mediapipe/getting_started/install.html#installing-on-macos.
I was consistently getting the following error during this command:
$ bazel run --define MEDIAPIPE_DISABLE_GPU=1 \
mediapipe/examples/desktop/hello_world:hello_world
Error:
mediapipe/framework/scheduler_queue.cc:212:3: error: expected expression
AUTORELEASEPOOL {
^
mediapipe/framework/scheduler_queue.cc:29:25: note: expanded from macro 'AUTORELEASEPOOL'
It looks like M1 Mac is not detected properly by Bazel as an apple build and a change in mediapipe/framework/BUILD needs to be done
cc_library(
name = "scheduler_queue",
srcs = ["scheduler_queue.cc"],
hdrs = [
"scheduler_queue.h",
"scheduler_shared.h",
],
copts = select({
--- "//conditions:default": [],
+++ "//conditions:default": ["-ObjC++"],
"//mediapipe:apple": [
"-ObjC++",
],
}),
This will allow Objective C++ directive #autoreleasepool to be available which is used here for memory management. It is not a good idea to get rid of it in code (as in the answer from hemant kshirsagar).
While looking into the error carefully and tracing back to the mediapipe framework file scheduler_queue.cc I found there is some issue in AUTORELEASEPOOL define.
I've updated this line
''' #define AUTORELEASEPOOL #autoreleasepool '''
to
''' #define AUTORELEASEPOOL '''
and it works for me, as I'm able to build mediapipe hello_world as expected.
Seems like, scheduler_queue.cc has not been written carefully considering this type of issues or maybe needs to be tested more.
Hopefully, this will help you all.
Thanks
I am trying to compile a Fortran (.f95) code in a Mac using gcc.
The code is an open source code. When I contacted the developers, they do not have the budget to provide a compiled application so they provide the files and let the user do the compiling.
Nevertheless I have failed at several attempts.
The code does come with a disclaimer of which files to compile and in which order. Nevertheless, just the first files encounters an error at a first pass.
This is the first section of the code that calls an error
TYPE(GasParV), PARAMETER :: Methane = GasParV
& ("CH4 ", 2.514d1, ! Name, AtomDV
The error is
HRS_RealGasEOS.f95:85:54:
TYPE(GasParV), PARAMETER :: Methane = GasParV
1
Error: Function 'gasparv' requires an argument list at (1)
I'm trying to run current Cobalt trunk (12.81256) on Ubuntu 16.04. but it fails:
[0814/100203:FATAL:graphics_system.cc(130)] Check failed: 1 == num_configs (1 vs. 0)
base::debug::StackTrace::StackTrace() [0x1f6202d]
logging::LogMessage::~LogMessage() [0x1f5fe99]
cobalt::renderer::backend::GraphicsSystemEGL::GraphicsSystemEGL() [0x67e5bdd]
cobalt::renderer::backend::CreateDefaultGraphicsSystem() [0x67e549e]
cobalt::renderer::RendererModule::Resume() [0x67dbe65]
cobalt::renderer::RendererModule::RendererModule() [0x67db776]
cobalt::browser::BrowserModule::BrowserModule() [0x1ce38c3]
cobalt::browser::Application::Application() [0x1cb71a5]
cobalt::browser::ApplicationStarboard::ApplicationStarboard() [0x1cb09c7]
cobalt::browser::CreateApplication() [0x1cb072e]
(anonymous namespace)::StartApplication() [0x1caef05]
cobalt::wrap_main::BaseEventHandler<>() [0x1cae9af]
SbEventHandle [0x1cae225]
starboard::shared::starboard::Application::DispatchAndDelete() [0x214dc7e]
starboard::shared::starboard::Application::DispatchStart() [0x214c07e]
starboard::shared::starboard::Application::Run() [0x214b8b7]
main [0x2120f95]
<unknown> [0x7f864632f830]
_start [0x1bd6029]
_start [0x1bd6029]
I found that issue with EGL configuration comes from using:
EGL_BIND_TO_TEXTURE_RGBA, EGL_TRUE
Without it eglChooseConfig will return 1 configuration.
But then it will fail again, after call to
eglCreateWindowSurface()
in cobalt/renderer/backend/egl/display.cc
[0814/111151:FATAL:display.cc(53)] Check failed: 0x3000 == eglGetError() (12288 vs. 12297)
Since this is EGL_BAD_MATCH error, chosen EGL config is not good, but neither was the original one.
I tried with setting
'gl_type%': 'system_gles2',
in starboard/linux/shared/gyp_configuration.gypi, but results were the same.
Am I missing something?
Steps for reproduction of crash:
Build:
cobalt/build/gyp_cobalt -C debug linux-x64x11
ninja -C out/linux-x64x11_debug cobalt
Run:
./out/linux-x64x11_debug/cobalt
Is there maybe some dependency on EGL or GLES libraries?
Issue is related to which libEGL and libGLES libraries are used.
Following libraries were used on my system:
libEGL.so.1 => /usr/lib/nvidia-375/libEGL.so.1 (0x00007f66bbebc000)
libGLESv2.so.2 => /usr/lib/nvidia-375/libGLESv2.so.2 (0x00007f66bbcad000)
When using libraries from mesa:
LD_LIBRARY_PATH=/usr/lib/x86_64-linux-gnu/mesa-egl ./cobalt
Cobalt will start and work.
Thanks Daniel and Andrew for help.
This is kind of a specific question, but, I am unable to get cmake and make to compile Yet Another Prolog in Fedora 23. Cloned the latest repo on Github, YAP 6.3.4. My friend ran cmake and make successfully on the identical clone on his Funtoo Linux. When I run them on Fedora 23, I get weird errors that would only make sense if CUDD headers were missing, but CUDD is installed with the header files.
I hope anyone has enough experience to offer a reason why a cmake-generated Makefile would fail to compile in one Linux system while compiling on another.
Here is a sample of the make errors (Makefile made with cmake with no errors). The "unknown" type name is in CUDD headers which are installed on my system. The source file cplint is supposed to be built using CUDD
% YAP 6.3.4-76638bb7 (compiled 2016-09-01T01:01:57#dhcp-129-8-62-64)
In file included from /home/safulop/yap-6.3/packages/cplint/cplint_yap.c:15:0:
/home/safulop/yap-6.3/packages/cplint/cplint.h:41:3: error: unknown type name ‘DdNode’
DdNode * * booleanVars;
^
/home/safulop/yap-6.3/packages/cplint/cplint.h:54:3: error: unknown type name ‘DdNode’
DdNode *key;
^
/home/safulop/yap-6.3/packages/cplint/cplint.h:64:33: error: unknown type name ‘DdManager’
variables createVars(YAP_Term t,DdManager * mgr, int create_dot,
^
/home/safulop/yap-6.3/packages/cplint/cplint.h:69:1: error: unknown type name ‘DdNode’
DdNode * retFunction(DdManager * mgr, expr expression,variables v);
^
/home/safulop/yap-6.3/packages/cplint/cplint.h:69:22: error: unknown type name ‘DdManager’
DdNode * retFunction(DdManager * mgr, expr expression,variables v);
^
/home/safulop/yap-6.3/packages/cplint/cplint.h:70:1: error: unknown type name ‘DdNode’
DdNode * retTerm(DdManager * mgr,term t,variables v);
^
As you said, the problem cames from the CUDD library. You need to fix the include directory folders of CUDD in the Makefile...