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 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 Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

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