Skip to content

Conversation

RAOF
Copy link

@RAOF RAOF commented Nov 23, 2018

Mark classes tagged with YAML_CPP_API with visibility("default"), to explicitly export them, and then hide everything else via -fvisibility=hidden.

This reduces the number of exported symbols by more than 50%, which has a small application start-up time and memory useage benefit. It also makes it more feasible to audit the set of exported symbols in automated ABI compatibility systems.

This marks classes tagged with YAML_CPP_API with visibility("default"), to
explicitly export them, and then makes the defalt visibility "hidden" via
-fvisibility=hidden.

This reduces the number of exported symbols by more than 50%, which has
a small application start-up time and memory useage benefit. It also
makes it more feasible to audit the set of exported symbols in automated
ABI compatibility systems.
@RAOF
Copy link
Author

RAOF commented Nov 23, 2018

In addition to running the unit-tests I've also built all of the packages in Ubuntu which depend on yaml-cpp against the it. All of them (at least the ones which don't fail for other reasons, like not using C++11) build fine against this, so those symbols are really unused.

@Zingam
Copy link

Zingam commented Feb 13, 2019

@RAOF For Windows the classes shouldn't be tagged with YAML_CPP_API but the public methods. Will that conflict with Linux in any way?
Which is something I intend to submit soon.

@vmiheer
Copy link

vmiheer commented Jan 13, 2021

#958 seems related and especially I think letting cmake handle this is good idea. #958 (comment)

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

Successfully merging this pull request may close these issues.

3 participants