Compile with -fvisibility=hidden.

[teo-tsirpanis]

Fixes errors when spdlog is statically linked into two shared libraries, caused by the one copy calling a function of the other. This will not cause any problems for consumers because the exported APIs are already marked with SPDLOG_API.

[tt4g]

The user's project that is creating a custom sink must be using an API that is not publicly available with SPDLOG_API.
I do not think CMAKE_CXX_VISIBILITY_PRESET=hidden should be set in the spdlog project.

Instead, you should pass the -DCMAKE_CXX_VISIBILITY_PRESET=hidden option to the cmake command to achieve your goal.

[teo-tsirpanis]

Which API is this, and why not also mark it with SPDLOG_API?

[tt4g]

Some of the namespace details APIs are not publicly available.
However, we assume that some users are using them in custom sinks.

For example spdlog::details::circular_q: #2774 (comment)

[teo-tsirpanis]

curcular_q is generic and thus will not be imported from a compiled library, and will not be affected by -fvisibility=hidden.

I looked at all headers that have an -inl.h counterpart, and the only API declaration that is defined in the -inl.h file and has not SPDLOG_API is this one:

spdlog/include/spdlog/logger.h

Line 421 in 326f887

void swap(logger &a, logger &b);

[tt4g]

I'm concerned that some users may be using symbols that have not been exported in the constructors of custom sinks and function arguments and return values.
So it is my opinion that we should not set(CMAKE_CXX_VISIBILITY_PRESET hidden) in CMakeLists.txt of spdlog project.
And users who do not want to expose the spdlog symbols can hide them with cmake -DCMAKE_CXX_VISIBILITY_PRESET=hidden to hide the symbols, so your goal is achieved without any changes.

Finally, this is just my opinion.
@gabime is the one who makes the decision to merge.