This is the mail archive of the cygwin-apps mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Restart discussion: Where to put the SDK headers and libs when switching to Mingw64 SDK?


On 7/10/2012 16:10, Corinna Vinschen wrote:
> On Jul  9 17:39, Corinna Vinschen wrote:
>> [...]
>> The question I'd like to discuss now is, how do we organize the access
>> to the Platform SDK headers and libs from the Mingw64 project, so that a
>> native Cygwin compiler has access to them?
>>
>> Please note that I'm only talking about the PSDK stuff.  We don't need
>> access to the Mingw CRT headers and libs (with a minor number of
>> exceptions), so the Mingw CRT stuff should continue to be isolated in
>> the /usr/${cpu}-w64-mingw32/sys-root/mingw/{include,lib} paths.
>>
>> There are two obvious choices:
>>
>> - The Platform SDK headers and libs are directly installed into
>>   /usr/include/w32api, /usr/lib/w32api, and /usr/lib64/w32api, just
>>   as today.
>>
>> - Alternatively, the PSDK stuff is installed into a shared directory
>>   which can be used not only by a Cygwin compiler, but also by the
>>   Mingw64 cross compilers.  Potential paths are
>>
>>   - /usr/share/w32api/{include,lib/lib64}
>>   - /usr/share/psdk/{include,lib/lib64}
>>   - Some other path which I can't think of right now
>>
>>   The package containing these files creates symlinks /usr/include/w32api,
>>   /usr/lib/w32api, and /usr/lib64/w32api in a postinstall script which
>>   point to the real locations.  Analog for the mingw64 cross compiler
>>   packages.
> 
> Here's another idea which requires to change GCC and the configury of all
> packages accessing Windows functionality, but adds cleanliness:
> 
> - As I said in my previous mail, the only reason we must have access to
>   libkernel32.a is the fact that the crtbegin.o file calls GetModuleHandle
>   and GetProcAddress.
> 
>   So we can store the PSDK files whereever we want, but *drop* the
>   /usr/include/w32api and /usr/lib/w32api paths from the default search
>   paths of GCC.
> 
>   We change GCC's __gcc_register_frame and __gcc_deregister_frame
>   functions to call a function within the Cygwin DLL instead, which
>   provides the combined functionality of GetModuleHandle and
>   GetProcAddress for the sole purpose to support GCC:
> 
>     cygwin_internal (CW_FETCH_GCC_FUNC, libname, funcname);
> 
>   Yes, this looks like dlopen Mark 2, but dlopen in Cygwin is a bit
>   heavyweight and we want the crtbegin.o functionality to be fast in
>   the first place.  Just a call to GetModuleHandle and a call to
>   GetProcAddress, nothing else.
> 
>   Additionally we change the spec file to drop the default linking of
>   -ladvapi32 -lshell32 -luser32 -lkernel32.
> 
>   The result of this operation is that we don't have to link against
>   libkernel32.a.  This in turn means when compiling Cygwin executables,
>   no access to the PSDK is required anymore, unless the application
>   itself calls Windows functionality.  This in turn means we can drop
>   the default w32api paths from the GCC default spec file, too.
> 
>   Applications using Windows functions would just have to add the new
>   PSDK paths to their configury.
> 
> Anyway, that's just a side idea.  I'm curious what you think.
> 
> Obviously, even with this change we still have to agree on a path where
> to store the PSDK headers.
> 

Not sure about the technical details, Kai will have to answer that. Kai
did mention about using interrupt call gates to get around kernel32.dll,
not sure if it is even practical.

As for the install path, I think sharing headers will be a problem,
since the mingw-w64 cross compiler will need the all CRT headers.
Sharing libs between the cross compilers and Cygwin w32api/libxx should
be fine though, with clever use of symlinks.


Attachment: signature.asc
Description: OpenPGP digital signature


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]