How to remove unused libraries?

[jvasanthan]

Hi,
With the latest SDK my final application size increased by 1.5MB. How can I reduce my application size. I a dont need S3, device tunneling etc., Is there any option to not include them part of the build process.

Please share your suggestions.

Regards,
James

[jmklix]

This sdk doesn't come with S3. That is something that would be found in the non-IoT sdk (aws-sdk-cpp). We don't have any configurations for not building device tunneling, etc. You could try modifying the CMakeLists to remove the services that you don't need, but that is not something that is supported or tested by this sdk.

A few other questions to make sure I understand what you want from this sdk. What version of this sdk were you using before/after you saw the 1.5MB size increase? What size requirements do you want from this sdk?

[jvasanthan]

If I build aws-iot-device-sdk-cpp-v2 with the build options mentioned in the readme, it does build libaws-c-s3.a.
If libaws-c-s3.a is not linked in the application, I get the following linker errors:
Api.cpp:(.text+0x64): undefined reference to aws_s3_library_init' Api.cpp:(.text+0x68): undefined reference to aws_s3_library_init'
Api.cpp:(.text+0xd88): undefined reference to aws_s3_library_clean_up' Api.cpp:(.text+0xd8c): undefined reference to aws_s3_library_clean_up'

we dont need aws_s3_library, how can I remove it. Could you please point me where can I find all CMAKE flags.

I had used v1.10.9 in production few years back now planning to update with the latest SDK. After updating to the latest version, noticed the application size increased by 1.5MB. This sdk is used in memory constrained hardware platform, which runs on embedded linux, where 1.5MB is a sizeable change.

What I need from this SDK: Mqtt client(pub/sub),Shadow, Jobs.

[bretambrose]

Assuming static linkage, you're only going to pick up what the linker can't strip based on call-site analysis, regardless of how many extra libraries are linked against. That stripping isn't perfect though (the codebase has plenty of vtable-esque constructions and unified configuration structures that will degrade how much can be left out, unfortunately).

A few things to try if you're not already doing so:

• If your target has an OpenSSL libcrypto already present, you can build against it instead of interning aws-lc by default (https://github.com/awslabs/aws-crt-cpp/blob/c5f770b59e27fdf62b599f24bfbe6d135820a07f/CMakeLists.txt#L9).
• Symbol stripping (will compromise your ability to troubleshoot crashes though)
• Enable more aggressive link-time optimizations than what is done by default

In the long term, we are starting to think about modularity (given that the codebase isn't very modular at all), but any changes are likely to (1) be breaking, and (2) be a long way off.