* [PING] Plugin support on Windows/MinGW
@ 2017-11-21 7:44 Boris Kolpackov
2017-11-22 10:37 ` JonY
0 siblings, 1 reply; 7+ messages in thread
From: Boris Kolpackov @ 2017-11-21 7:44 UTC (permalink / raw)
To: gcc-patches; +Cc: Jonathan Yong
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PING] Plugin support on Windows/MinGW
2017-11-21 7:44 [PING] Plugin support on Windows/MinGW Boris Kolpackov
@ 2017-11-22 10:37 ` JonY
2017-11-22 11:25 ` Boris Kolpackov
0 siblings, 1 reply; 7+ messages in thread
From: JonY @ 2017-11-22 10:37 UTC (permalink / raw)
To: Boris Kolpackov, gcc-patches
[-- 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 --]
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PING] Plugin support on Windows/MinGW
2017-11-22 10:37 ` JonY
@ 2017-11-22 11:25 ` Boris Kolpackov
2017-11-23 11:48 ` JonY
0 siblings, 1 reply; 7+ messages in thread
From: Boris Kolpackov @ 2017-11-22 11:25 UTC (permalink / raw)
To: JonY; +Cc: gcc-patches
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PING] Plugin support on Windows/MinGW
2017-11-22 11:25 ` Boris Kolpackov
@ 2017-11-23 11:48 ` JonY
2017-11-23 12:20 ` Boris Kolpackov
2017-11-26 20:01 ` JonY
0 siblings, 2 replies; 7+ messages in thread
From: JonY @ 2017-11-23 11:48 UTC (permalink / raw)
To: Boris Kolpackov; +Cc: gcc-patches
[-- 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 --]
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PING] Plugin support on Windows/MinGW
2017-11-23 11:48 ` JonY
@ 2017-11-23 12:20 ` Boris Kolpackov
2017-11-23 12:49 ` Pedro Alves
2017-11-26 20:01 ` JonY
1 sibling, 1 reply; 7+ messages in thread
From: Boris Kolpackov @ 2017-11-23 12:20 UTC (permalink / raw)
To: JonY; +Cc: gcc-patches
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PING] Plugin support on Windows/MinGW
2017-11-23 12:20 ` Boris Kolpackov
@ 2017-11-23 12:49 ` Pedro Alves
0 siblings, 0 replies; 7+ messages in thread
From: Pedro Alves @ 2017-11-23 12:49 UTC (permalink / raw)
To: Boris Kolpackov, JonY; +Cc: gcc-patches
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PING] Plugin support on Windows/MinGW
2017-11-23 11:48 ` JonY
2017-11-23 12:20 ` Boris Kolpackov
@ 2017-11-26 20:01 ` JonY
1 sibling, 0 replies; 7+ messages in thread
From: JonY @ 2017-11-26 20:01 UTC (permalink / raw)
To: Boris Kolpackov; +Cc: gcc-patches
[-- 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 --]
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2017-11-26 13:05 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-11-21 7:44 [PING] Plugin support on Windows/MinGW Boris Kolpackov
2017-11-22 10:37 ` JonY
2017-11-22 11:25 ` Boris Kolpackov
2017-11-23 11:48 ` JonY
2017-11-23 12:20 ` Boris Kolpackov
2017-11-23 12:49 ` Pedro Alves
2017-11-26 20:01 ` JonY
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).