Replies: 5 comments 22 replies
-
|
If the problem occurs with the xPack binaries and does not occur with the original Arm binaries, you are in the right place. If the problem also occurs with the Arm binaries, you should report it to Arm. FYI, the xPack binaries are compiled from exactly the same source files as the Arm binaries, with (hopefully!) the same configuration options, expecting them to behave the same (good or bad). When reporting compiler issues, in order for the compiler maintainers to reproduce the issue, you have to identify the shortest possible source file which, when compiled by hand in a terminal, exhibits the issue. |
Beta Was this translation helpful? Give feedback.
-
|
I don't really know where the binaries came from, never heard of xpack until now! Its all managed through arduino-cli. Given the error message is referring to Unfortunately I wouldn't have a clue on how to test this on the "original" binaries :/ Minimal reproducible source is anything (even empty) but i've been using the below: On the working version the first few lines of output are: So it looks like its failing on the first "Detecting libraries used..." command. Unfortunatly I cant run that command with -v as when I copy/paste it I get: |
Beta Was this translation helpful? Give feedback.
-
That's correct. stm32duino packs the xPack Arm Embedded GCC binaries.
The original Arm binaries are available from https://developer.arm.com/downloads/-/arm-gnu-toolchain-downloads, the 12.2.Rel1 release. Download them at a place of your choice, add the folder where the binaries are to your PATH and temporarily rename the folder where the xPack binaries are, so that it is no longer in the PATH, and rerun your build.
I don't know about Or you can simply copy/paste the commands invoking
Then the problem occurs when processing the headers. |
Beta Was this translation helpful? Give feedback.
-
|
Hi @ilg-ul, @bobemoe @bobemoe as suggested by @ilg-ul, you should try to use official arm and see if it's reproducible. |
Beta Was this translation helpful? Give feedback.
-
Yes, that's what I meant, add
It is not clear how you tested, but if you used a toolchain installed via the package manager, there are good chances it was built with a different configuration than the official Arm distribution, thus my strong suggestion remains to use exactly the 12.2.Rel1 binaries from Arm, to be sure we can compare things. |
Beta Was this translation helpful? Give feedback.
-
I've simply machines with those distributions. And even if another toolchain is installed on the host, Arduino uses the one specified explicitly. So, yes it works within Ubuntu and the xpack v12.2.1-1.2 |
Beta Was this translation helpful? Give feedback.
-
|
Hi, thanks for investigating and your advice so far.. so I have confirmed that replacing the folder at Guess that means it is an xpack issue and I shall create a bug report here? To keep things more standardised I did this testing on a Docker container created from ubuntu:22.04, confirmed the issue still existed, and that the test above solved it. |
Beta Was this translation helpful? Give feedback.
-
|
first draft.. will post as issue later IssueUpdated from STMicroelectronics:stm32 2.4.0 to 2.5.0 and now I can't compile my project with It seems the issue is the change in bundled version of xpack-arm-none-eabi-gcc from 10.3.1-2.3 to 12.2.1-1.2 Steps to reproduceDockerfileon you local host build the docker container: now connect to container, create a empty test project: now compile: See we get Segmentation fault. Steps to test the original arm binariesDownload, extract and replace the xpack-arm-none-eabi-gcc and compile again: Working! Confirms the issue it with the xpack binaries bundled with STM32duino core. |
Beta Was this translation helpful? Give feedback.
-
If on the docker host it was ok (and I expect to be ok on any Linux), the problem might be specific to running with root permission on Ubuntu 22? |
Beta Was this translation helpful? Give feedback.
-
|
sorry missed the error message above, but still getting the error on the docker host, also tried in docker as a non-root, same issue. |
Beta Was this translation helpful? Give feedback.
-
What OS? |
Beta Was this translation helpful? Give feedback.
-
|
OK, works fine on my laptop, and also another server! Fails on the original server both inside and outside of docker. Failing on the Docker host I guess explains why it fails on ALL containers! Biggest difference is the OS version. Working on Chimaera but failing on Beowulf, based on different Debian versions:
I may upgrade the server, see if that fixes it, unless you want me to try anything else first? |
Beta Was this translation helpful? Give feedback.
-
The common point between the host and the container is the kernel.
From my point of view, I'd be curious to know why it fails, to document the issue in case someone else has the same problem. I have no experience with Chimaera/Beowulf, but it looks like these distributions are not fully compatible with GNU systems, which might explain the problems, since the xPack binaries depend on GLIBC 2.27 or later, which might depend on some kernel features. What version is the Beowulf kernel? Was it custom build? I guess there is some incompatibility that crashes the compiler. |
Beta Was this translation helpful? Give feedback.
-
|
Upgrading the server now... Beowulf kernel in use is: 4.19.0-14-amd64 #1 SMP Debian 4.19.171-2 (2021-01-30) x86_64 GNU/Linux |
Beta Was this translation helpful? Give feedback.
-
|
Server updated. Kernel now at 5.10.0-21-amd64 #1 SMP Debian 5.10.162-1 (2023-01-21) x86_64 GNU/Linux xpack now working! Thanks and sorry to bother you ;) |
Beta Was this translation helpful? Give feedback.
-
|
No problem, I'm glad you have a functional configuration now. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks @ilg-ul and @bobemoe four your support. |
Beta Was this translation helpful? Give feedback.
-
|
Thank you for using the xPack tools! |
Beta Was this translation helpful? Give feedback.
-
|
I installed a VM with Beowulf and did some further tests. I confirm that cc1plus crashes, even when started without any arguments. cc1 runs fine, so the toolchain can compile C programs. Since the cc1plus binary has no debug info, I can not run a debug session. My current theory is that the kernel or one of the system libraries has a small difference compared to regular systems. Since the xPack toolchain is by design intended to be standalone, it includes most of the required libraries, including libstdc++, in the package. This later is required since the toolchain is compiled with a newer GCC than available in the Ubuntu 18 where the build is performed, and the resulting binary needs the newer library. The Arm toolchain expects that all libraries are available in the system, and so its dependencies are in sync with the kernel or whatever small difference exists. Given that after upgrading the server to a newer kernel the problem no longer occurs, I'll probably not investigate further, and revisit it only in case other similar issues are reported. |
Beta Was this translation helpful? Give feedback.
-
I'm building a project using arduino-cli and STM32 core. After a recent update I get segfault. I have been directed here. Issue tracker was very insistent I post to forums first if unsure so here I am...
Full details can be found here: stm32duino/Arduino_Core_STM32#2008
Am I in the fight place? Should I post this as an issue on this repo?
Beta Was this translation helpful? Give feedback.
All reactions