Add missing export to vsg::Exception struct

[rms7326]

Add missing export to vsg::Exception

Description

If VulkanSceneGraph is compiled as a .dylib and used by another .dylib on the Mac where VulkanSceneGraph throws a vsg::Exception the client requesting the service from VulkanSceneGraph is not able to catch the vsg::Exception because the RTTI information is different. This is a known issue with clang. If the symbol is not exported from a shared library the RTTI information will not match that generated by dependent libraries for the same symbol.

Type of change

Source change

Please delete options that are not relevant.

• [ X ] Bug fix (non-breaking change which fixes an issue)

How Has This Been Tested?

Locally on our MacOS with arm64 architecture.

Test Configuration:

• Hardware: arm64
• Toolchain: clang (AppleClang)

Checklist:

• [ X ] My code follows the style guidelines of this project
• [ X ] I have performed a self-review of my own code
• [ X ] My changes generate no new warnings
• [ X ] New and existing unit tests pass locally with my changes

[robertosfield]

Could there be issues under Windows with exporting a struct that is entirely defined in the header?

[AnyOldName3]

It should be perfectly fine.

[AnyOldName3]

This PR won't fix the bug, though, as Export.h only sets up __declspec(dllexport) and __declspec(dllimport) for MSVC/Clang-CL/GCC targeting Windows, not the visibility attributes that plain Clang, Apple Clang and GCC targeting not-Windows use. The preprocessed code for non-Windows will be identical.

I've run into (effectively) the same problem as this is trying to fix in the past, and it needs to be fixed by ensuring that the thing catching the exception and throwing it both export the symbol (whereas on Windows, you want the DLL to dllexport and the application to dllimport). It's pretty normal to compile applications with flags that make them not export symbols by default. That means that this PR should start working if the definition for VSG_DECLSPEC is changed to __attribute__ ((visibility ("default"))) in the #else branch.

If that change is made, then as a follow-up task, we could add -fvisibility=hidden to the build flags for non-MSVC compilers and end up with smaller libraries with potentially better codegen, and also discover missing VSG_DECLSPECs without having to build things on Windows.

[rms7326]

@AnyOldName3 this pull request isn't to fix a Windows issue but a AppleClang issue. An to be clear, by adding the VSG_DECLSPEC to the vsg::Exception struct it does indeed fix the RTTI disparity between the two shared libraries. This isn't strictly an export issue as much as it is an oddity with AppleClang not generating the same RTTI information unless the visibility export is specified. I can't explain why.

@robertosfield, with regard to working with Windows, I believe your concern is address according to this MS compiler doc:
https://learn.microsoft.com/en-us/cpp/cpp/using-dllimport-and-dllexport-in-cpp-classes?view=msvc-170
The very first example in the document is a class, class DllExport C, with the implementation inline with the definition.

[AnyOldName3]

I am aware that this isn't a problem with MSVC. However, this PR definitely can't do anything as the preprocessed code is identical on non-Windows platforms with and without this patch applied. The definition of VSG_DECLSPEC looks like:

#if defined(WIN32)
#    if defined(vsg_EXPORTS)
#        define VSG_DECLSPEC __declspec(dllexport)
#    elif defined(VSG_SHARED_LIBRARY)
#        define VSG_DECLSPEC __declspec(dllimport)
#    else
#        define VSG_DECLSPEC
#    endif
#else
#    define VSG_DECLSPEC
#endif

so it's expanded to an empty value unless WIN32 is defined, which won't be the case on a Mac.

The problem isn't specific to Apple Clang, as it's exactly the same one as is discussed in GCC's visibility documentation here in the Problems with C++ exceptions (please read!) section. Symbols that are hidden aren't guaranteed to be given the same RTTI by the dynamic linker, so if anything's compiled with -fvisibility=hidden and the visibility isn't explicitly set to default for a specific symbol, or if the symbol's visibility is explicitly set to hidden, it won't reliably work. You likely have -fvisibility=hidden set when compiling your app's executable - CMake does so by default for executables if your cmake_minimum_required is at least 3.4 - so you'd fall into the first case.

If this PR fixes the problem on your machine, then it's because you've done something else in your project that isn't included here, e.g. providing an alternative definition of VSG_DECLSPEC. Obviously, adding a macro that doesn't expand to anything to a struct declaration can't change behaviour.