Re: [PATCH] Port libgccjit to Windows.

["Nicolas Bértolo" <nicolasbertolo@gmail.com>]

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.

> 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?

Thanks, Nicolas.

El mar., 2 jun. 2020 a las 13:27, JonY (<10walls@gmail.com>) escribió:
>
> On 5/28/20 8:46 PM, David Malcolm via Gcc-patches wrote:
> > On Thu, 2020-05-28 at 16:51 -0300, Nicolas Bértolo wrote:
> >>> I'm going to have to trust your Windows expertise here; the tempdir
> >>> code looks convoluted to me, but perhaps that's the only way to do
> >> it.
> >>> (Microsoft's docs for "SECURITY_ATTRIBUTES" suggest to me that if
> >>> lpSecurityDescriptor is NULL, then the directory gets a default
> >>> security descriptor, and that this may mean it's only readable by
> >> the
> >>> user represented by the access token of the process [1], which
> >> might
> >>> suggest a simplification - but I'm very hazy on how the security
> >> model
> >>> in Windows works)
> >>
> >> I tested this and it gives write access to the "Authenticated Users"
> >> group.
> >
> > Aha - sounds like that would be a problem.  Thanks for clarifying.
> >
> >> The
> >> way I did it gives access only to the user that owns the libgccjit
> >> process. I
> >> have to admit that it is a lot of code and it is hard to understand
> >> unless you
> >> know the security model of Windows well. I don't know it well, I
> >> wrote this
> >> keeping the documentation close and experimenting.
> >
> > Thanks.
> >
> >>> I was able to successfully bootstrap and regression test with your
> >>> patch on x86_64-pc-linux-gnu.  I also verified that the result of
> >> "make
> >>> install" was not affected for my configuration.
> >>
> >> Great.
> >>
> >>> I've pushed your patch to master as
> >>> c83027f32d9cca84959c7d6a1e519a0129731501.
> >>>
> >>> Thanks again for the patch
> >>> Dave
> >>
> >> Thanks to you for all the good feedback.
> >>
> >> Nico.
> >
>
> Hello,
>
> A bit of a late review, some minor points:
>
> 1. Using .so on Windows for DLLs is fine.
> 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.
> 3. Ideally I would prefer to .cc too, though I see other C++ files also
> written as .c.
>
> Resend in case reply to list did not work,
>