You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jun 5, 2019. It is now read-only.
I could build and install Llilum (LLVM, Zelig project, Board Configuration, Llilum SDK MSI and application template VSIX). In VS2015 (community version) I can create a new Llilum Application. After some bugfixes with the board confuguration and the wrong folder for storing managed_opt.o my build goes up to the end...
I used the default values predefined for using LPC1768 - I just created and build the solution, but I get linker failure with the following message:
##############################################################################
c:/program files (x86)/gnu tools arm embedded/5.4 2016q3/bin/../lib/gcc/arm-none-eabi/5.4.1/../../../../arm-none-eabi/bin/ld.exe: region RAM overflowed with stack
1>collect2.exe : error : ld returned 1 exit status
##############################################################################
Thus, it seems that the build image needs more RAM than available!? Where can I find the RAM usage of the build? I just wondering that the default project uses LPC1768 but I cannot build it? Does any other person had the same issue? Maybe by Zelig SDK is wrong in some way?
Thank you for any hints.
The text was updated successfully, but these errors were encountered:
to say it more precisly... its the workaround another user initcated this here under issues. I simply copied the file after first failed build into the parent folder folder. Thank you for notify me, it is not a bug fix, it's a workaround.
I build today a small Windows Desktop App (first quick and easy for testing) acting as File System Watcher. This app will watch the target subfolder in ARM/Debug and looking for 'llilum.Managed_opt.o' file creations or changes. Once detected, I auto copy this file to the ARM\Debug folder. Because this is so fast, the Llilum application build runs without failure and can create the application image to deploy or debug. It works fine for me.
I used a K64F project due to LPC1768 failed to build due to RAM issues...
What I discovered during Debug session, that - and I do not know why - certain breakpoints never get triggered even the code has to run through... but application seems to run...
And every time I initiate a debug or build the whole native project will be rebuild which needs some time. Normally all the native code coming from the Llilum SDK (except m own interop code normally will not be changed once tested... why the Llilum SDK rebuild everthing again? What I do not understand?
Many Thanks
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
I could build and install Llilum (LLVM, Zelig project, Board Configuration, Llilum SDK MSI and application template VSIX). In VS2015 (community version) I can create a new Llilum Application. After some bugfixes with the board confuguration and the wrong folder for storing managed_opt.o my build goes up to the end...
I used the default values predefined for using LPC1768 - I just created and build the solution, but I get linker failure with the following message:
##############################################################################
c:/program files (x86)/gnu tools arm embedded/5.4 2016q3/bin/../lib/gcc/arm-none-eabi/5.4.1/../../../../arm-none-eabi/bin/ld.exe: region RAM overflowed with stack
1>collect2.exe : error : ld returned 1 exit status
##############################################################################
Thus, it seems that the build image needs more RAM than available!? Where can I find the RAM usage of the build? I just wondering that the default project uses LPC1768 but I cannot build it? Does any other person had the same issue? Maybe by Zelig SDK is wrong in some way?
Thank you for any hints.
The text was updated successfully, but these errors were encountered: