[PING] Plugin support on Windows/MinGW

[PING] Plugin support on Windows/MinGW

[Boris Kolpackov]

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
by default (there are also fixes for a couple of bugs as a bonus).
I would really liked to have this patch considered for GCC 8, if
possible.

Thanks,
Boris

Re: [PING] Plugin support on Windows/MinGW

[JonY]

[-- Attachment #1.1: Type: text/plain, Size: 636 bytes --]

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
> by default (there are also fixes for a couple of bugs as a bonus).
> I would really liked to have this patch considered for GCC 8, if
> possible.
> 
> Thanks,
> Boris
> 

Is there a problem with using .so for internal libraries instead of
"dll" if it simplifies the code?

I don't see any other problems with it.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 858 bytes --]

Re: [PING] Plugin support on Windows/MinGW

[Boris Kolpackov]

JonY <10walls@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/tool (e.g., libtool). Also,
you never know how other pieces of the system (like antivirus) will
react to a file that looks like a DLL but is called something else.


> ... if it simplifies the code?

I don't think it simplifies that much and the potential (and unknown)
downside is significant.

Thanks for the review,
Boris

Re: [PING] Plugin support on Windows/MinGW

[JonY]

[-- Attachment #1.1: Type: text/plain, Size: 956 bytes --]

On 11/22/2017 11:14 AM, Boris Kolpackov wrote:
> JonY <10walls@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/tool (e.g., libtool). Also,
> you never know how other pieces of the system (like antivirus) will
> react to a file that looks like a DLL but is called something else.
> 
> 

Libtool shouldn't matter since it is not used to build those, and I
doubt AVs would care what the filename is called. Apache on Windows uses
.so plugins too.

>> ... if it simplifies the code?
> 
> I don't think it simplifies that much and the potential (and unknown)
> downside is significant.
> 
> Thanks for the review,
> Boris
> 

I'll commit in a few days if there are no more inputs.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 858 bytes --]

Re: [PING] Plugin support on Windows/MinGW

[Boris Kolpackov]

JonY <10walls@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 extensions
(.dll, .dylib, etc).


> I'll commit in a few days if there are no more inputs.

Great, thanks!

Boris

Re: [PING] Plugin support on Windows/MinGW

[Pedro Alves]

On 11/23/2017 12:06 PM, Boris Kolpackov wrote:
> JonY <10walls@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 extensions
> (.dll, .dylib, etc).
> 
> 
>> I'll commit in a few days if there are no more inputs.
> 
> Great, thanks!

I would just like to say that I think this is a fantastic patch
that will help open GCC to many more use cases.  The fact that
plugins don't work on Windows has been a sore spot, IMO.

I for one am very happy that this make gdb's libcc1 plugin
a viable option for Windows.  Puts us one step closer to the
long term plan of making GDB always use GCC for C/C++
expression parsing/evaluation.  Yay.  :-)

Thanks,
Pedro Alves

Re: [PING] Plugin support on Windows/MinGW

[JonY]

[-- Attachment #1.1: Type: text/plain, Size: 1055 bytes --]

On 11/23/2017 11:34 AM, JonY wrote:
> On 11/22/2017 11:14 AM, Boris Kolpackov wrote:
>> JonY <10walls@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/tool (e.g., libtool). Also,
>> you never know how other pieces of the system (like antivirus) will
>> react to a file that looks like a DLL but is called something else.
>>
>>
> 
> Libtool shouldn't matter since it is not used to build those, and I
> doubt AVs would care what the filename is called. Apache on Windows uses
> .so plugins too.
> 
>>> ... if it simplifies the code?
>>
>> I don't think it simplifies that much and the potential (and unknown)
>> downside is significant.
>>
>> Thanks for the review,
>> Boris
>>
> 
> I'll commit in a few days if there are no more inputs.
> 

Applied to trunk r255154.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 858 bytes --]