[BUG] Compile error building on Cygwin/POSIX platform #1252
Labels
bug
Something isn't working
Comments
msatti-metrol
changed the title
|
Checked with the team, the POSIX port is not meant to run in Cygwin environment. The pthread_once_t is defined a struct in cygwin pthread.h, which is not what this port would consume. |
|
With the above workaround, it does appear to build at least1, although running doesn't seem to be behaving properly2. Is this something you would be interested in? Might be able to dedicate time and submit a PR. According to POSIX (I assume this says the same thing as the IEEE published version):
Therefore 1 Also required to build: 2 Tick behaviour either seems to not work or be incredibly slow, but I might have set something up wrong. |
|
Are you using the latest main branch? Asking because I see both the changes there: |
|
Sorry you're right - was using the version v11.1.0. I think I tried Without any workarounds, this is the build log on main (3fd7f17): Workarounds:
It builds ok after using these workarounds. |
|
Additionally, I think there is a race condition bug to do with signals, but need some guidance. Tested against main (3fd7f17), but was also happening on v11.1.0. Bug descriptionApplication code: The Bug analysisIt appears the Tmr Svc task/thread is being suspended while SIGALRM is pending, causing ticks to not occur (although I think this can happen for any task & signal). Note I have added some additional debugging code into
Does this appear to be a bug to you? |
These seem good. Thank you for sharing!
Can you test with a C application instead of C++? Just want to isolate the issue. |
Sure, same issue: StackType_t GaugeSimulator_Stack[configMINIMAL_STACK_SIZE];
StaticTask_t GaugeSimulator_Tcb;
void GaugeSimulator_Main(void* parameters)
{
for (size_t i = 0; i < 5; i++)
{
printf("Hello world enter %u\n", i);
vTaskDelay(configTICK_RATE_HZ);
printf("Hello world exit %u\n", i);
}
while (1)
vTaskEndScheduler();
}
int main(int argc, char* argv[])
{
printf("Starting\n");
xTaskCreateStatic(
GaugeSimulator_Main,
"GaugeSimulator",
configMINIMAL_STACK_SIZE,
NULL,
4,
GaugeSimulator_Stack,
&GaugeSimulator_Tcb);
vTaskStartScheduler();
printf("Exiting\n");
return 0;
} |
|
Additionally, a proper Linux environment (via Ubuntu 24.10 WSL) appears to behave differently. I think I can replicate the same bug conditions as Cygwin with these code changes: However, the bug manifests differently, and the program appears to behave ok:
|
|
In Cygwin, when the When In Linux, when a signal like This fundamental difference in signal delivery behavior between Cygwin and Linux is the root cause of the issue. Since this behavior is very Cygwin-specific, we would not suggest a change in the FreeRTOS Posix port. But to avoid hitting the This ensures every FreeRTOS thread starts with |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Describe the bug
Trying to build the POSIX port, targeting Cygwin (v3.5.7) on Windows 11, there is a build error related to pthreads:
Caused by
PTHREAD_ONCE_INITnot being a valid expression for assigning a value, which is defined as:Note: glibc defines it as the following instead, which is a valid expression:
Target
Host
To Reproduce
Expected behavior
Build succeeds
Workaround by defining the following in FreeRTOSConfig.h:
Which gets included by port.c via the CMake config interface library.
Potential fix by something like (?):
(Not familiar with usage of pthreads, is calling
pthread_once()applicable?)Thanks.
The text was updated successfully, but these errors were encountered: