-
Notifications
You must be signed in to change notification settings - Fork 13.3k
Sketch too big... #826
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
Comments
There was an increase in both flash and RAM usage due to SSL support. I'll reduce the footprint before releasing a stable version. |
Thanks for your reply. We don't need SSL support in our project anyway. And not load extra code or ram usage if we don't include it... |
Right now it's not possible because linker arguments are defined on a per-core basis, not per-library basis. I will look into possible ways to solve this issue. |
@igrr are you sure it's not on a per-variant basis? If it is, then we could maybe make secure variants that link the SSL stuff. If it's not per-variant, perhaps that would probably be of interest to the broader Arduino community for adoption/inclusion in 1.6.6 and we could start a discussion on the airduino-developers mailing list? |
You're right, we can modify linker flags on a per-variant basis, or simply by adding an option submenu to existing variants (e.g. Use SSL > Yes/No). However I find this option less than ideal: one would have to add such option to all board variants, and boards.txt is quite complex as it is. Making changes to compiler flags on a per-library basis would also be cool. I wonder if there are other use cases for this feature? |
I can think of a couple of interesting uses for that - like making statically allocated buffer sizes compile time dynamic without modifying the library source (i.e. through compiler command line symbol definitions). Certainly worth discussion, I don't think it's come up before on the dev list and others might have insights as to the merits. The unused sections trick would be elegant if it can be made to work as well, but sometimes that's hard for the compiler to infer, e.g. when function pointers are in play. |
Have been using staging release 1084 for some time and everything was ok. Started to use SPIFFS and it brought us some really nice features like storing configuration files and css.
But just today I've tried out the latest staging release (1106) and now I get this message:
Sketch too big; see http://www.arduino.cc/en/Guide/Troubleshooting#size for tips on reducing it.
Compile size on two different staging releases with the same sketch:
1084 - 408372
1106 - 445480
That's a large increase (37k). Same sketch, no extra includes. It runs fine on our dev boards with ESP12E modules on it, but it would kill our project for all those 512kB ESP users.
Can anyone explain the sudden 37k gain? Is there some workaround?
The text was updated successfully, but these errors were encountered: