-
-
Notifications
You must be signed in to change notification settings - Fork 784
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Cannot use assembly files in MCS51 platform due to core issue #3917
Comments
Addendum: This issue also applies to platform-ststm8 if someone tries to actually use the Addendum 2: The current behavior is okay for all GCC toolchains, it's just wrong for the SDCC toolchain. |
… files on case-sensitive OS such as Window OS // Resolve #3917
Thanks for the report! It is a very interesting issue, mainly related to the SCons. See https://github.com/SCons/scons/blob/master/SCons/Tool/asm.py#L44 Nevertheless, we found a historical bug in ALL dev-platforms where we overwrite |
My platformio just upgraded to 6.0.1 and for some reason, the build for STM32 started to fail with this message:
Apparently, my platformio.ini file has always contained line
and it has always worked fine on Windows. When I changed the line to uppercase ".S", the build started to work fine. Does the fixing of this issue mean that, from now on, all projects that referenced ".s" files and worked before need to be changed and files renamed to uppercase? |
Yes, it was a historical bug in SCons on Windows, and we decided to fix it on our side. See http://draskovblog.blogspot.com/2008/12/gcc-differences-between-s-and-s.html |
Ok, thanks for the link. Also, the compilation database shows |
Yes, .s and .S are assembly files and as.exe is used. The only flags are different. You can check this with |
Hmm, let me humbly disagree. I'm running here is one for .s:
here is one for .S: The first one fails since My point is, if people use .s extension erroneously, then they need to change the case and everything will work. However, if they use .s extension rightfully and really need to pass the file directly to |
@positron96 thanks, fixed in https://github.com/platformio/platform-ststm32 Could you try the latest version of ST STM32 dev-platform? [env:development]
platform = https://github.com/platformio/platform-ststm32.git Please navigate to the project folder and type Does it work now? |
Yes, the assembler doesn't complain about unknown arguments anymore. It is run with these arguments now:
Thank you for making very useful software! BTW, for some reason after I changed |
You can only update installed packages. If they have not been installed yet, you will not see any updates. Thanks for the kind words! 🙏🚀 |
What kind of issue is this?
If you’ve found a bug, please provide an information below.
You can erase any parts of this template not applicable to your Issue.
Configuration
Operating system: Windows 10 x64
PlatformIO Version (
platformio --version
):PlatformIO Core, version 5.2.0a3
Description of problem
Per https://community.platformio.org/t/mcs51-assembler-programming/20410.
When attempting to write an assembler program for a MCS51 device on Windows by creating a
src/blink.s
file, the following error occurrsSuddenly it wants to use
sdcc
, the C compiler, for the.s
file, but in the special case of SDCC, it does not know how to handle assembly files.The platform code
https://github.com/platformio/platform-intel_mcs51/blob/c52ea3a706e540df65bdc6a0caf64f1eefeb8ac9/builder/main.py#L56-L60
sets the correct
AS="sdas8051"
directive, however the code inplatformio-core/platformio/builder/tools/platformio.py
Lines 115 to 117 in 73d4f10
overwrites the assembler on non-case-sensitive operating systems to SDCC, thus causing the issue.
Steps to Reproduce
blink.s
file with empty contentActual Results
Expected Results
It uses
sdas8051
correctly, as it actually does on Llinux.(note: the assembler flags are still wrong per linked issue, but that's a different issue)
If problems with PlatformIO Build System:
The content of
platformio.ini
:Source file to reproduce issue:
Additional info
On Linux systems this issue does not occur
But final linking fails due to multiple other issues which will be filed separately in the MCS51 platform (missing
-l
assembler flag, etc.).The text was updated successfully, but these errors were encountered: