Skip to content

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

Closed
ghost opened this issue Sep 27, 2015 · 6 comments
Closed

Sketch too big... #826

ghost opened this issue Sep 27, 2015 · 6 comments
Milestone

Comments

@ghost
Copy link

ghost commented Sep 27, 2015

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?

@igrr
Copy link
Member

igrr commented Sep 28, 2015

There was an increase in both flash and RAM usage due to SSL support. I'll reduce the footprint before releasing a stable version.

@ghost
Copy link
Author

ghost commented Sep 28, 2015

Thanks for your reply.

We don't need SSL support in our project anyway.
Is it possible to make SSL support dependent on something like:

And not load extra code or ram usage if we don't include it...

@igrr
Copy link
Member

igrr commented Sep 28, 2015

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.

@vicatcu
Copy link

vicatcu commented Sep 28, 2015

@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?

@igrr
Copy link
Member

igrr commented Sep 28, 2015

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.
My thought was to fix this at linker level by using -Wl,-gc-sections to remove unused stuff.

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?

@vicatcu
Copy link

vicatcu commented Sep 28, 2015

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants