On 11/23/2017 11:34 AM, JonY wrote:
> On 11/22/2017 11:14 AM, Boris Kolpackov wrote:
>> JonY <10wa...@gmail.com> writes:
>>
>>> Is there a problem with using .so for internal libraries instead of
>>> "dll"...
>>
>> I think not but I haven't tested it. The problem with using .so instead
>> of .dll i
On 11/23/2017 12:06 PM, Boris Kolpackov wrote:
> JonY <10wa...@gmail.com> writes:
>
>> Libtool shouldn't matter since it is not used to build those, [...]
>
> We don't know which build system the plugin author will use to build
> the plugin. We can, however, reasonably expect that it will be able
JonY <10wa...@gmail.com> writes:
> Libtool shouldn't matter since it is not used to build those, [...]
We don't know which build system the plugin author will use to build
the plugin. We can, however, reasonably expect that it will be able
to produce a shared library with the platform-standard ex
On 11/22/2017 11:14 AM, Boris Kolpackov wrote:
> JonY <10wa...@gmail.com> writes:
>
>> Is there a problem with using .so for internal libraries instead of
>> "dll"...
>
> I think not but I haven't tested it. The problem with using .so instead
> of .dll is that producing this non-standard extensio
JonY <10wa...@gmail.com> writes:
> Is there a problem with using .so for internal libraries instead of
> "dll"...
I think not but I haven't tested it. The problem with using .so instead
of .dll is that producing this non-standard extension may not be easy
or possible depending on the build system
On 11/21/2017 07:03 AM, Boris Kolpackov wrote:
> Hi,
>
> I would like to ping this patch:
>
> https://gcc.gnu.org/ml/gcc-patches/2017-11/msg01040.html
>
> The changes are fairly conservative: they do not touch much of the
> existing module implementation and plugin support on MinGW is disabled
>
