[WIP] mingw64 related changes to Cygwin configure and other assorted files with departed w32api/mingw
I decided over the weekend to port over configury changes that I made to
Cygwin's now-out-of-date GIT repository.
These changes basically just cleaned up some of the configure scripts
and made it easier to pinpoint where windows headers and libraries come
from by adding a --with-windows-headers and --with-windows-libs options.
However, some of the assumptions made for the git repository weren't
really valid for the CVS repository so there was a fair amount of work
involved.
I thought that I'd do this so I could easily get up-and-running with the
MinGW64 stuff but I ran into some problems building things with gentoo's
MinGW64 implementation. So, I switched to using the files from the
Cygwin release.
As I mentioned in cygwin-developers, getting the most recent version of
mingw64 stuff working required making some changes to some Cygwin source
files. Most of the changes just involved #undef'ing constants defined
in Windows headers. Still, I was surprised that these hadn't already
been handled since I thought I was behind the times by still using the
Mingw32 stuff.
Anyway, is a summary of the changes I've made to files is below. I'll
be doing appropriate ChangeLogs too, of course. I've also attached the
patch.
This is a heads up in case this conflicted materially with any of the
w64 development.
cgf
--- winsup/Makefile.common
Gutted. Revamped to just include common definitions and macros.
--- winsup/acinclude.m4
Gutted. Now defines:
AC_WINDOWS_HEADERS
AC_WINDOWS_LIBS
AC_CYGWIN_INCLUDES
--- winsup/configure.cygwin
New file. Does common stuff for cygwin configure files.
--- **/autogen.sh
New script. Regenerates configure and aclocal.m4.
--- winsup/ccwrap
New script. Used to run gcc/g++ using defined cygwin/newlib/windows
locations.
CCWRAP_VERBOSE=1 environment variable shows full expanded path to
compiler command line.
(I wish gcc had a way to say "Don't use this built-in header directory")
--- winsup/c++wrap
C++ front-end to ccwrap - because CVS doesn't like symlinks.
--- **/configure.in
Revamped to use new acinclude.m4 directives and to eliminate cruft.
--- **/Makefile.in
Add .E target to generate macro expanded version of source file.
Eliminate "VERBOSE=" option. Always print everything.
Revamp to use new configure framework and c*wrap.
Regenerate Makefile if Makefile.in, config.status change.
Use WINDOWS_LIBDIR and WINDOWS_HEADERS to find windows stuff.
Remove unneeded SHELL:= setting.
--- cygwin/Makefile.in
Add the very important datarootdir setting!
Revamp (slightly) CFLAGS/CXXFLAGS settings. These two things should
really be separate but I've gotten into the habit of saying:
make CFLAGS=-g
to cause things to not be built with optimization. Handle that case
but otherwise decouple CFLAGS from CXXFLAGS.
Generate tlsoffsets.h in the build directory.
--- cygwin/mkvers.sh
Fix version.h and winver.rc generation to not assume in-tree windows
files.
--- cygwin/winlean.h
#define _WIN32
cygwin/winsup.h
#define _WIN32
--- cygwin/include/netdb.h
#undef a bunch of windows-defined constants.
--- cygwin/include/cygwin/if.h
Use #pragma once
--- cygwin/include/cygwin/in.h
Use #pragma once
Use _IN_PORT_DECLARED to guard against define of in_port_t.
--- cygwin/include/cygwin/in6.h
Use #pragma once
Use _IN_PORT_DECLARED to guard against define of in_port_t.
--- cygwin/include/cygwin/socket.h
#undef a bunch of windows-defined constants.
--- cygwin/include/sys/socket.h
#pragma once
--- cygwin/include/sys/termios.h
#undef FIONBIO before defining it.
--- cygwin/minires-os-if.c
#define __INSIDE_CYGWIN__
#include
Delete some #undef's that are now in header files.
--- cygwin/libc/minires.h
#pragma once
#undef some windows-defined constants.
--- utils/Makefile.in
Lots of changes. Assume that we always have mingw libraries available for
cygcheck.
Set CCWRAP variables to control where to find header files for various
utilities.
--- utils/dump_setup.cc
Include zlib.h directly.
--- utils/path.cc
#define __CRT__NO_INLINE
to avoid an error from a windows header.
Index: Makefile.common
===
RCS file: /cvs/uberbaum/winsup/Makefile.common,v
retrieving revision 1.61
diff -u -p -r1.61 Makefile.common
--- Makefile.common 7 Nov 2012 16:32:07 - 1.61
+++ Makefile.common 12 Nov 2012 19:53:05 -
@@ -8,154 +8,23 @@
# Cygwin license. Please consult the file "CYGWIN_LICENSE" for
# details.
-# This makefile requires GNU make.
+define justdir
+$(patsubst %/,%,$(dir $1))
+endef
-CFLAGS_COMMON:=-Wall -Wstrict-aliasing -Wwrite-strings -fno-common -pipe
-fbuiltin -fmessage-length=0 -D_SDKDDKVER_H
-MALLOC_DEBUG:=#-DMALLOC_DEBUG -I/cygnus/src/uberbaum/winsup/cygwin/dlmalloc
-MALLOC_OBJ:=#/cygnus/src/uberbaum/winsup/cygwin/dlmalloc/malloc.o
-
-override srcdir:=${shell cd $(srcdir); pwd}
-ifneq (,${filter-out /%,$(srcdir)})
-updir:=$(srcdir)/..
-updir1:=$(updir)/..
-else
-updir:=${pat
Re: [WIP] mingw64 related changes to Cygwin configure and other assorted files with departed w32api/mingw
On Nov 12 15:02, Christopher Faylor wrote:
> I decided over the weekend to port over configury changes that I made to
> Cygwin's now-out-of-date GIT repository.
>
> These changes basically just cleaned up some of the configure scripts
> and made it easier to pinpoint where windows headers and libraries come
> from by adding a --with-windows-headers and --with-windows-libs options.
> However, some of the assumptions made for the git repository weren't
> really valid for the CVS repository so there was a fair amount of work
> involved.
>
> I thought that I'd do this so I could easily get up-and-running with the
> MinGW64 stuff but I ran into some problems building things with gentoo's
> MinGW64 implementation. So, I switched to using the files from the
> Cygwin release.
>
> As I mentioned in cygwin-developers, getting the most recent version of
> mingw64 stuff working required making some changes to some Cygwin source
> files. Most of the changes just involved #undef'ing constants defined
> in Windows headers. Still, I was surprised that these hadn't already
> been handled since I thought I was behind the times by still using the
> Mingw32 stuff.
>
> Anyway, is a summary of the changes I've made to files is below. I'll
> be doing appropriate ChangeLogs too, of course. I've also attached the
> patch.
>
> This is a heads up in case this conflicted materially with any of the
> w64 development.
Looks good at first sight. I see only one place which won't work for 64
bit, the ccwrap script. It uses i686-pc-cygwin-gcc/g++ hardcoded, but
it should use something like ${target_cpu}-pc-cygwin-gcc/g++ to make it
platform independent. With a matching change, I can give it a try on
64 bit tomorrow.
I'm a bit puzzled about the necessity of some of the changes to source
files. Yaakov's Fedora 17 version of the headers is supposedly cut from
the mingw64 trunk on 2012-10-16, while JonY's official headers have an
upload date of 2012-10-18. They should be practically identical. Why
do I not see any problems to build CVS HEAD?!?
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat
Re: [WIP] mingw64 related changes to Cygwin configure and other assorted files with departed w32api/mingw
On Mon, Nov 12, 2012 at 10:50:23PM +0100, Corinna Vinschen wrote:
>On Nov 12 15:02, Christopher Faylor wrote:
>> I decided over the weekend to port over configury changes that I made to
>> Cygwin's now-out-of-date GIT repository.
>>
>> These changes basically just cleaned up some of the configure scripts
>> and made it easier to pinpoint where windows headers and libraries come
>> from by adding a --with-windows-headers and --with-windows-libs options.
>> However, some of the assumptions made for the git repository weren't
>> really valid for the CVS repository so there was a fair amount of work
>> involved.
>>
>> I thought that I'd do this so I could easily get up-and-running with the
>> MinGW64 stuff but I ran into some problems building things with gentoo's
>> MinGW64 implementation. So, I switched to using the files from the
>> Cygwin release.
>>
>> As I mentioned in cygwin-developers, getting the most recent version of
>> mingw64 stuff working required making some changes to some Cygwin source
>> files. Most of the changes just involved #undef'ing constants defined
>> in Windows headers. Still, I was surprised that these hadn't already
>> been handled since I thought I was behind the times by still using the
>> Mingw32 stuff.
>>
>> Anyway, is a summary of the changes I've made to files is below. I'll
>> be doing appropriate ChangeLogs too, of course. I've also attached the
>> patch.
>>
>> This is a heads up in case this conflicted materially with any of the
>> w64 development.
>
>Looks good at first sight. I see only one place which won't work for 64
>bit, the ccwrap script. It uses i686-pc-cygwin-gcc/g++ hardcoded, but
>it should use something like ${target_cpu}-pc-cygwin-gcc/g++ to make it
>platform independent. With a matching change, I can give it a try on
>64 bit tomorrow.
That was really only for my own personal use. It isn't meant to be used
with CC not in the environment. That's only for when I was experimenting
with running the script outside of the build.
>I'm a bit puzzled about the necessity of some of the changes to source
>files. Yaakov's Fedora 17 version of the headers is supposedly cut from
>the mingw64 trunk on 2012-10-16, while JonY's official headers have an
>upload date of 2012-10-18. They should be practically identical. Why
>do I not see any problems to build CVS HEAD?!?
You can keep asking me this question but I don't really have an answer.
Since I don't run Fedora, I'm not going to install it to figure it out.
cgf
Re: [WIP] mingw64 related changes to Cygwin configure and other assorted files with departed w32api/mingw
On Mon, Nov 12, 2012 at 07:02:57PM -0500, Christopher Faylor wrote: >On Mon, Nov 12, 2012 at 10:50:23PM +0100, Corinna Vinschen wrote: >>I'm a bit puzzled about the necessity of some of the changes to source >>files. Yaakov's Fedora 17 version of the headers is supposedly cut from >>the mingw64 trunk on 2012-10-16, while JonY's official headers have an >>upload date of 2012-10-18. They should be practically identical. Why >>do I not see any problems to build CVS HEAD?!? > >You can keep asking me this question but I don't really have an answer. >Since I don't run Fedora, I'm not going to install it to figure it out. Actually, an idea came to me in the thinking room that this might be due to the fact that my windows headers may not be considered to be system headers since they aren't in a preinstalled location. I know that gcc can be more lax about redefine symbols in some situations when dealing with system headers. Maybe that's it. cgf
