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 (<10wa...@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, >
