You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In terms of being compatible with LGPL using DLLs makes sense for commercial games. Mixing shared and static libs is a bit chaotic on Windows so it would make sense to also distribute liblcf as a DLL in this case.
Currently liblcf can be only used as a static library on Windows because the way how DLLs work is special:
All functions and static fields must be dllexported.
CMake has "magic" to do this but it will only work for functions:
set(CMAKE_SUPPORT_WINDOWS_EXPORT_ALL_SYMBOLS ON)
After this there is exactly one linker error left which is about:
staticconst size_type _empty_buf[2];
This is a static data field (and the only one we have in liblcf it seems :).
For data fields the process is even more ugly: You must determine whether you are currently compiling the DLL or using the DLL. In case of compiling you must dllexport it in case of using you must import the field.
This is quite disgusting imo. A solution would be to move the field into the cpp file. This has the disadvantage that inlining of the empty buf field will not work anymore (at least not without link time codegen):
@fmatthew5876 As you wrote this code: Do you see a problem with the shown solution:
In terms of being compatible with LGPL using DLLs makes sense for commercial games. Mixing shared and static libs is a bit chaotic on Windows so it would make sense to also distribute liblcf as a DLL in this case.
Currently liblcf can be only used as a static library on Windows because the way how DLLs work is special:
All functions and static fields must be dllexported.
CMake has "magic" to do this but it will only work for functions:
After this there is exactly one linker error left which is about:
This is a static data field (and the only one we have in liblcf it seems :).
For data fields the process is even more ugly: You must determine whether you are currently compiling the DLL or using the DLL. In case of compiling you must dllexport it in case of using you must import the field.
This is quite disgusting imo. A solution would be to move the field into the cpp file. This has the disadvantage that inlining of the empty buf field will not work anymore (at least not without link time codegen):
@fmatthew5876 As you wrote this code: Do you see a problem with the shown solution:
The text was updated successfully, but these errors were encountered: