This is the mail archive of the
cygwin-apps
mailing list for the Cygwin project.
Re: Restart discussion: Where to put the SDK headers and libs when switching to Mingw64 SDK?
- From: Corinna Vinschen <corinna-cygwin at cygwin dot com>
- To: cygwin-apps at cygwin dot com
- Date: Tue, 10 Jul 2012 10:10:11 +0200
- Subject: Re: Restart discussion: Where to put the SDK headers and libs when switching to Mingw64 SDK?
- References: <20120709153914.GC20472@calimero.vinschen.de>
- Reply-to: cygwin-apps at cygwin dot com
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.
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat