missing or wrong mingw_lib ?

[marco atzeri]

building from last cvs

make[3]: *** No rule to make target `/libkernel32.a', needed by
`cygwin0.dll'. Stop.
make[3]: Leaving directory
`/pub/cygwin/cvs/build/i686-pc-cygwin/winsup/cygwin'

$ grep libkernel32.a
/pub/cygwin/cvs/build/i686-pc-cygwin/winsup/cygwin/Makefile
DLL_IMPORTS:=$(mingw_lib)/libkernel32.a $(mingw_lib)/libntdll.a


but on source tree "$(mingw_lib)" is not reported on other files

$ grep -rH mingw_lib *
winsup/cygwin/Makefile.in:DLL_IMPORTS:=$(mingw_lib)/libkernel32.a
$(mingw_lib)/libntdll.a
winsup/mingw/Makefile.in: echo "static int __mingw_libm_dummy;" >
_libm_dummy.c

[Christopher Faylor]

Post by marco atzeri
building from last cvs
make[3]: *** No rule to make target `/libkernel32.a', needed by
`cygwin0.dll'. Stop.
make[3]: Leaving directory
`/pub/cygwin/cvs/build/i686-pc-cygwin/winsup/cygwin'
$ grep libkernel32.a
/pub/cygwin/cvs/build/i686-pc-cygwin/winsup/cygwin/Makefile
DLL_IMPORTS:=$(mingw_lib)/libkernel32.a $(mingw_lib)/libntdll.a
but on source tree "$(mingw_lib)" is not reported on other files
$ grep -rH mingw_lib *
winsup/cygwin/Makefile.in:DLL_IMPORTS:=$(mingw_lib)/libkernel32.a
$(mingw_lib)/libntdll.a
winsup/mingw/Makefile.in: echo "static int __mingw_libm_dummy;" >
_libm_dummy.c

I'm not sure what Corinna's intentions were in changing that line but
I've put it back the way it was, maybe temporarily.

I'm generating a snapshot to make sure that it works correctly.

Incidentally, I've revamped the configury for Cygwin in preparation for
moving it to a new stand-alone git repository. Since it will be
standalone (with the possible exception of newlib), it no longer will be
using the old, arcane top-level configure/Makefile.in which has
accommodations for building gdb, binutils, gcc, flex, bison, etc.

The git repository is not quite ready for prime time and it isn't yet
clear what we'll be doing with the old CVS repository. Right now, git
is pulling in changes from CVS but I guess we could eventually be moving
in the other direction. I can also set up a git cvs server for those
who prefer it.

cgf

[marco atzeri]

Post by Christopher Faylor
Incidentally, I've revamped the configury for Cygwin in preparation for
moving it to a new stand-alone git repository. Since it will be
standalone (with the possible exception of newlib), it no longer will be
using the old, arcane top-level configure/Makefile.in which has
accommodations for building gdb, binutils, gcc, flex, bison, etc.
The git repository is not quite ready for prime time and it isn't yet
clear what we'll be doing with the old CVS repository. Right now, git
is pulling in changes from CVS but I guess we could eventually be moving
in the other direction. I can also set up a git cvs server for those
who prefer it.
cgf

cygwin/newlib are the only projects I am working on still using CVS.
Personally I do not see a need for git cvs server.

Regards
Marco

[Earnie Boyd]

Post by Christopher Faylor
Incidentally, I've revamped the configury for Cygwin in preparation for
moving it to a new stand-alone git repository. Since it will be
standalone (with the possible exception of newlib), it no longer will be
using the old, arcane top-level configure/Makefile.in which has
accommodations for building gdb, binutils, gcc, flex, bison, etc.

How does this affect mingw and w32api? I've noticed Corinna's patches
to mingw-w64 as well, will Cygwin be going that direction and dropping
mingw and w32api?

[Christopher Faylor]

Post by Earnie Boyd

Post by Christopher Faylor
Incidentally, I've revamped the configury for Cygwin in preparation for
moving it to a new stand-alone git repository. Since it will be
standalone (with the possible exception of newlib), it no longer will be
using the old, arcane top-level configure/Makefile.in which has
accommodations for building gdb, binutils, gcc, flex, bison, etc.

How does this affect mingw and w32api? I've noticed Corinna's patches
to mingw-w64 as well, will Cygwin be going that direction and dropping
mingw and w32api?

Corinna's changes should allow building Cygwin with either w32api or a
mingw-w64 version of Windows headers files. Obviously, for now, things
work as is with w32api and mingw.

I don't know if my configuration changes will be final or not but, if
they are, you have to choose the location for the Windows header files
when you first configure.

[Corinna Vinschen]

Post by Earnie Boyd

Post by Christopher Faylor
Incidentally, I've revamped the configury for Cygwin in preparation for
moving it to a new stand-alone git repository. Since it will be
standalone (with the possible exception of newlib), it no longer will be
using the old, arcane top-level configure/Makefile.in which has
accommodations for building gdb, binutils, gcc, flex, bison, etc.

How does this affect mingw and w32api? I've noticed Corinna's patches
to mingw-w64 as well, will Cygwin be going that direction and dropping
mingw and w32api?

At one point, yes. I explained the reasoning behind it a couple of
months ago on the cygwin-apps list:
http://cygwin.com/ml/cygwin-apps/2012-03/msg00060.html

As cgf wrote, I'm just working on porting Cygwin to use Mingw64 headers
and libs while retaining the ability to build with mingw32/w32api
headers. However, at one point we will probably switch to mingw64
entirely for building the Cygwin DLL.


Corinna

[Corinna Vinschen]

Post by Christopher Faylor

Post by marco atzeri
building from last cvs
make[3]: *** No rule to make target `/libkernel32.a', needed by
`cygwin0.dll'. Stop.
make[3]: Leaving directory
`/pub/cygwin/cvs/build/i686-pc-cygwin/winsup/cygwin'
$ grep libkernel32.a
/pub/cygwin/cvs/build/i686-pc-cygwin/winsup/cygwin/Makefile
DLL_IMPORTS:=$(mingw_lib)/libkernel32.a $(mingw_lib)/libntdll.a
but on source tree "$(mingw_lib)" is not reported on other files
$ grep -rH mingw_lib *
winsup/cygwin/Makefile.in:DLL_IMPORTS:=$(mingw_lib)/libkernel32.a
$(mingw_lib)/libntdll.a
winsup/mingw/Makefile.in: echo "static int __mingw_libm_dummy;" >
_libm_dummy.c

I'm not sure what Corinna's intentions were in changing that line but
I've put it back the way it was, maybe temporarily.

Thanks. Actually it was an accidental checkin from my local sandbox
which I use to build aginst Mingw64 headers. The only intended change
was the one from winlean.h. I'm going to revert the rest since we're
going to change the build system anyway when moving to git.


Corinna