Static builds and exported symbols

[pictview]

I think there is no need to export all symbols when building a static lib with clang. Hence I suggest to change the following
#elif defined(_GNUC_)
#  define LIBDEFLATE_EXPORT_SYM _attribute_((visibility("default")))
#else
#  define LIBDEFLATE_EXPORT_SYM
#endif
to something like
#elif defined(_GNUC_) || defined(_clang_)
#  if defined(LIBDEFLATE_DLL)
#    define LIBDEFLATE_EXPORT_SYM _attribute_((visibility("default")))
#  else
#    define LIBDEFLATE_EXPORT_SYM _attribute_((visibility("hidden")))
#  endif
#else
#  define LIBDEFLATE_EXPORT_SYM
#endif

maybe then LIBDEFLATE_DLL should be renamed to something like LIBDEFLATE_SHARED.

[ebiggers]

So you'd like __attribute__((visibility("hidden"))) to be used when building a static library. Why? I didn't think it made a difference for static libraries.

[pictview]

It makes two differences:

1. hidden symbols make the binary somewhat smaller
2. more importantly, there can be clashes on some systems when multiple binaries export symbols of the same name. This can lead to crashes if the two symbols come from different library versions and expect different arguments. For example, on Windows, each module .EXE/.DLL strictly defines the name of the .DLL from which the imported symbol should come. If the symbols actually resides in the same .EXE/.DLL, then it is not imported, but the symbol in the same .EXE/.DLL is called.. However, it is very different for example on macOS. If two dylibs export a symbol of the same name, it is undefined which is used at runtime. Even when module A.dylib exports a symbol S and wants to use it, it may actually happen that the OS decides to pair the import of S from A.dylib with the export of the symbol S from B.dylib, i.e. A.dylib will actually call the implementation of S in B.dylib. Under which circumstances can a single process contain 2 dylibs exporting the same symbol but from different versions of the same static library? Think of plugins for e.g. Adobe products coming from different vendors.

[ebiggers]

A disadvantage of this proposal is that it makes -DLIBDEFLATE_DLL mandatory when building the shared library on non-Windows platforms. That was not previously a requirement. It could break people who aren't using the provided CMake-based build system.

Perhaps users who want this should add -fvisibility=hidden to the compiler flags? Then it would apply to all global symbols, not just the ones in the public API. That's probably what you wanted.

[ebiggers]

Perhaps users who want this should add -fvisibility=hidden to the compiler flags? Then it would apply to all global symbols, not just the ones in the public API. That's probably what you wanted.

I realized that won't work as-is, due to the use of _attribute_((visibility("default"))) which overrides that. It would work if no attribute was added.

Either way, I'm not sure this proposal is worth making -DLIBDEFLATE_DLL mandatory when building the shared library on non-Windows platforms.