On 6/7/20 4:03 PM, Nicolas Bértolo wrote:
> Hi,
> 
> Sorry for the super late reply.
> 
>> 1. Using .so on Windows for DLLs is fine.
> 
> I know, but using the standard suffix for the platform seems better, IMHO.
> 

It doesn't prevent applications from actually loading it.

>> 2. The DLL name on Windows should use LIBGCCJIT_SONAME rather than
>> LIBGCCJIT_LINKER_NAME, so applications would load libgccjit.so.0 instead
>> of libgccjit.so directly. The linker command output needs to be
>> LIBGCCJIT_SONAME.
> 
> Do you think the library should be called libgccjit.so.0 instead of the more
> Windows-like libgccjit.dll? That seems weird. Could you explain why?

Ideally, libtool is used so we get libgccjit-0.dll, unfortunately it is
not. So the only way to ABI version the dll would be to use Unix style
soname to mark when an ABI has changed.

Applications loading libgccjit.so.0 should be recompiled if a new
incompatible ABI libgccjit.so.1 is introduced. If a recompile is not
possible, the older library can still be installed side by side.

Applications should still link against the file generated import library
for transparency.