Re: Try #3 for changes to Cygwin configure

2012-11-14 Thread Corinna Vinschen 
On Nov 13 22:39, Christopher Faylor wrote:
 Try #3.  This is a smaller patch with some bug fixes found after
 building from-scratch, cleanly on a Fedora system with Yaakov's cross
 tools (ok, so I lied and did end up setting up a Fedora system to test
 this).

Is that the point where I have to say na na na na naaa na?  Just kidding.

 Also fixed some long-standing Makefile bugs and misconceptions in
 cygwin and utils.
 
 I'm not entirely thrilled with the fact that configuring and building
 this from the level above winsup results in lots of compiler command
 line parameters passed in which are also discerned by macros in
 acinclude.m4.  If we do end up staying in the src CVS repository I'll
 have to fix that.

For a start I applied the patch to CVS HEAD and ran a stock `configure;
make' from toplevel on Fedora 17 with Yaakov's Cygwin packages.

I can't link the Cygwin DLL:

/usr/lib64/gcc/i686-pc-cygwin/4.5.3/../../../../i686-pc-cygwin/bin/ld: cannot 
find -luser32
/usr/lib64/gcc/i686-pc-cygwin/4.5.3/../../../../i686-pc-cygwin/bin/ld: cannot 
find -lkernel32
/usr/lib64/gcc/i686-pc-cygwin/4.5.3/../../../../i686-pc-cygwin/bin/ld: cannot 
find -ladvapi32
/usr/lib64/gcc/i686-pc-cygwin/4.5.3/../../../../i686-pc-cygwin/bin/ld: cannot 
find -lshell32
collect2: ld returned 1 exit status

I didn't look why it doesn't find these libs.  But this means the
-nostdlib flag is missing.  If I add it I get a lot of messages pointing
out missing symbols, though:

  .../cygtls.h:301: undefined reference to `__Unwind_Resume'
  .../bsdlib.o:bsdlib.cc:(.eh_frame+0x12): undefined reference to 
`___gxx_personality_v0'
  [...]

After a bit of digging I found that the -fno-rtti -fno-exceptions flags
are missing when building the C++ source files.

When building cygserver stuff, the flags -mno-use-libstdc-wrappers
-fno-rtti -fno-exceptions are missing, too.

In utils, I get an interesting error when building cygcheck:

  In file included from .../cygcheck.cc:13:0:
  .../newlib/libc/include/stdio.h:35:20: fatal error: stddef.h: No such file or 
directory

Newlib?  For a Mingw application?  The compiler instruction actually
contains the following paths:

  -I${srcdir}/winsup/cygwin \
  -isystem /usr/i686-pc-cygwin/sys-root/usr/include/w32api \
  -isystem ${srcdir}/winsup/cygwin/include \
  -isystem ${srcdir}-pc-cygwin/newlib/targ-include \
  -isystem ${srcdir}/newlib/libc/include

None of them should be used when building with the Mingw compiler.

Btw., why did you remove $(CFLAGS) from the definition of MINGW_CXX?
I added it just a couple of days ago explicitely to be able to build
the utils manually with different optimizing settings:

 2012-11-05  Corinna Vinschen ...

* Makefile.in (MINGW_CXX): Attach $(CFLAGS) to allow providing
build option tweaks to mingw compiler as well.


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader  cygwin AT cygwin DOT com
Red Hat

Re: Try #3 for changes to Cygwin configure

2012-11-14 Thread Christopher Faylor 
On Wed, Nov 14, 2012 at 12:57:07PM +0100, Corinna Vinschen wrote:
On Nov 13 22:39, Christopher Faylor wrote:
 Try #3.  This is a smaller patch with some bug fixes found after
 building from-scratch, cleanly on a Fedora system with Yaakov's cross
 tools (ok, so I lied and did end up setting up a Fedora system to test
 this).

Is that the point where I have to say na na na na naaa na?  Just kidding.

 Also fixed some long-standing Makefile bugs and misconceptions in
 cygwin and utils.
 
 I'm not entirely thrilled with the fact that configuring and building
 this from the level above winsup results in lots of compiler command
 line parameters passed in which are also discerned by macros in
 acinclude.m4.  If we do end up staying in the src CVS repository I'll
 have to fix that.

For a start I applied the patch to CVS HEAD and ran a stock `configure;
make' from toplevel on Fedora 17 with Yaakov's Cygwin packages.

I can't link the Cygwin DLL:

/usr/lib64/gcc/i686-pc-cygwin/4.5.3/../../../../i686-pc-cygwin/bin/ld: cannot 
find -luser32
/usr/lib64/gcc/i686-pc-cygwin/4.5.3/../../../../i686-pc-cygwin/bin/ld: cannot 
find -lkernel32
/usr/lib64/gcc/i686-pc-cygwin/4.5.3/../../../../i686-pc-cygwin/bin/ld: cannot 
find -ladvapi32
/usr/lib64/gcc/i686-pc-cygwin/4.5.3/../../../../i686-pc-cygwin/bin/ld: cannot 
find -lshell32
collect2: ld returned 1 exit status

I didn't look why it doesn't find these libs.  But this means the
-nostdlib flag is missing.

AFAIK, it means that the -nostdlib is used and the path to the libraries
isn't right.  It is when you specify the windows library path
explicitly.  This should be fixed now.  Finding the path to where the
linker locates libraries turned out to be harder than it first appeared.

If I add it I get a lot of messages pointing out missing symbols,
though:

.../cygtls.h:301: undefined reference to `__Unwind_Resume'
.../bsdlib.o:bsdlib.cc:(.eh_frame+0x12): undefined reference to
`___gxx_personality_v0' [...]

After a bit of digging I found that the -fno-rtti -fno-exceptions flags
are missing when building the C++ source files.

Thanks for tracking this down.  That was part of an overaggressive
purging of Makefile.common.  I don't know why I wouldn't be seeing this
when building with nonstandard library locations though.

When building cygserver stuff, the flags -mno-use-libstdc-wrappers
-fno-rtti -fno-exceptions are missing, too.

-fno-rtti and -fno-exceptions are expected given the above.  AFAICT,
cygserver hasn't ever set -mno-use-libstdc-wrappers.

In utils, I get an interesting error when building cygcheck:

  In file included from .../cygcheck.cc:13:0:
  .../newlib/libc/include/stdio.h:35:20: fatal error: stddef.h: No such file 
 or directory

Newlib?  For a Mingw application?  The compiler instruction actually
contains the following paths:

  -I${srcdir}/winsup/cygwin \
  -isystem /usr/i686-pc-cygwin/sys-root/usr/include/w32api \
  -isystem ${srcdir}/winsup/cygwin/include \
  -isystem ${srcdir}-pc-cygwin/newlib/targ-include \
  -isystem ${srcdir}/newlib/libc/include

None of them should be used when building with the Mingw compiler.

Actually, cygcheck.o and path.o need newlib since cygcheck includes
mntent.h and mntent.h uses paths.h which comes from newlib.  It
shouldn't be trying to get stdio.h from newlib though.  That's fixed.

Btw., why did you remove $(CFLAGS) from the definition of MINGW_CXX?
I added it just a couple of days ago explicitely to be able to build
the utils manually with different optimizing settings:

I didn't know it was a recent change but, as I mentioned in my initial
notes, I decoupled CFLAGS and CXXFLAGS when I got rid of our nonstandard
checks for the C compiler.  The change was inadvertent at first but then
I realized that everywhere else in the world those two flags mean two
different things and are meant to control c/c++ compilation.  The fact
that they don't in Cygwin is just because I was either too lazy or too
ignorant when I first set that up.

However, I did add code to Makefile.common so that if you say:

make CFLAGS=-g it will remove any optimization from CXXFLAGS as
well.

I have nearly everything working again but I'm surprised to find out
that I can't build dump_setup.o with FC16 installed mingw compilers due
to complaints about missing definitions for:

NT_SUCCESS
OBJ_CASE_INSENSITIVE
InitializeObjectAttributes

I can't build strace.o because of missing definitions for:
ProcessDebugFlags
NtSetInformationProcess

These are not pulled in by winternl.h in the
mingw32-headers-2.0.999-0.5.trunk.20120224.fc17.noarch package but
they do seem to be handled correctly in the versions I downloaded from
the Cygwin repo.

What version of mingw headers are you running that enables you to
compile these packages?  I can't get them to build even in an unpatched
sandbox.

Btw, I believe that these will probably compile correctly if I use the
w32api headers from Yaakov's cygwin cross gcc packages (which was why
things seemed to work for me before)

Re: Try #3 for changes to Cygwin configure

2012-11-14 Thread Corinna Vinschen 
On Nov 14 14:08, Christopher Faylor wrote:
 On Wed, Nov 14, 2012 at 12:57:07PM +0100, Corinna Vinschen wrote:
 For a start I applied the patch to CVS HEAD and ran a stock `configure;
 make' from toplevel on Fedora 17 with Yaakov's Cygwin packages.
 
 I can't link the Cygwin DLL:
 
 /usr/lib64/gcc/i686-pc-cygwin/4.5.3/../../../../i686-pc-cygwin/bin/ld: 
 cannot find -luser32
 /usr/lib64/gcc/i686-pc-cygwin/4.5.3/../../../../i686-pc-cygwin/bin/ld: 
 cannot find -lkernel32
 /usr/lib64/gcc/i686-pc-cygwin/4.5.3/../../../../i686-pc-cygwin/bin/ld: 
 cannot find -ladvapi32
 /usr/lib64/gcc/i686-pc-cygwin/4.5.3/../../../../i686-pc-cygwin/bin/ld: 
 cannot find -lshell32
 collect2: ld returned 1 exit status
 
 I didn't look why it doesn't find these libs.  But this means the
 -nostdlib flag is missing.
 
 AFAIK, it means that the -nostdlib is used and the path to the libraries
 isn't right.

Weird.  The above libs are pulled in via the *lib: directive in the
gcc specs file.  They are in the default lib search path and they
definitely exist.  And no, when it fails there is no -nostdlib in
the compiler directive:

  i686-pc-cygwin-c++ \
-L${builddir}/i686-pc-cygwin/winsup/cygwin \
-isystem ${srcdir}/winsup/cygwin/include \
-B${builddir}/i686-pc-cygwin/newlib/ \
-isystem ${builddir}/i686-pc-cygwin/newlib/targ-include \
-isystem ${srcdir}/newlib/libc/include\
-g -O2 \
-L${builddir}/i686-pc-cygwin/winsup/cygwin \
-Wl,--gc-sections  \
-Wl,-T${srcdir}/winsup/cygwin/cygwin.sc \
-static \
-Wl,--heap=0 -Wl,--out-implib,cygdll.a -shared -o cygwin0.dll \
-e _dll_entry@12 cygwin.def
...lots of .o files
${builddir}/i686-pc-cygwin/winsup/cygserver/libcygserver.a \
${builddir}/i686-pc-cygwin/newlib/libm/libm.a \
${builddir}/i686-pc-cygwin/newlib/libc/libc.a \
-lgcc \
/usr/i686-pc-cygwin/sys-root/usr/lib/w32api/libkernel32.a \
/usr/i686-pc-cygwin/sys-root/usr/lib/w32api/libntdll.a \
-Wl,-Map,cygwin.map

I don't see anything in there which would explain why the default lib
search path isn't searched.

 When building cygserver stuff, the flags -mno-use-libstdc-wrappers
 -fno-rtti -fno-exceptions are missing, too.
 
 -fno-rtti and -fno-exceptions are expected given the above.  AFAICT,
 cygserver hasn't ever set -mno-use-libstdc-wrappers.

You're right.  Wrong conclusion without testing, sorry.

 In utils, I get an interesting error when building cygcheck:
 
   In file included from .../cygcheck.cc:13:0:
   .../newlib/libc/include/stdio.h:35:20: fatal error: stddef.h: No such file 
  or directory
 
 Newlib?  For a Mingw application?  The compiler instruction actually
 contains the following paths:
 
   -I${srcdir}/winsup/cygwin \
   -isystem /usr/i686-pc-cygwin/sys-root/usr/include/w32api \
   -isystem ${srcdir}/winsup/cygwin/include \
   -isystem ${srcdir}-pc-cygwin/newlib/targ-include \
   -isystem ${srcdir}/newlib/libc/include
 
 None of them should be used when building with the Mingw compiler.
 
 Actually, cygcheck.o and path.o need newlib since cygcheck includes
 mntent.h and mntent.h uses paths.h which comes from newlib.  It
 shouldn't be trying to get stdio.h from newlib though.  That's fixed.

Ouch!  That's a bug.  Building the native utils with the Mingw compiler
should not need any of the above paths, and quite certainly not access
any newlib headers.  I'd rather like to propose the following patch to
mntent.h and get rid of all of the above paths:

Index: include/mntent.h
===
RCS file: /cvs/src/src/winsup/cygwin/include/mntent.h,v
retrieving revision 1.7
diff -u -p -r1.7 mntent.h
--- include/mntent.h18 Jul 2012 11:17:25 -  1.7
+++ include/mntent.h14 Nov 2012 19:52:28 -
@@ -15,8 +15,6 @@ details. */
 extern C {
 #endif
 
-#include paths.h
-
 struct mntent
 {
   char *mnt_fsname;
@@ -35,6 +33,10 @@ struct mntent *getmntent_r (FILE *, stru
 int endmntent (FILE *__filep);
 #endif
 
+#ifdef __CYGWIN__
+
+#include paths.h
+
 /* The following two defines are deprecated.  Use the equivalent
names from paths.h instead. */
 #ifndef MNTTAB
@@ -48,6 +50,8 @@ int endmntent (FILE *__filep);
 #define MOUNTED _PATH_MOUNTED
 #endif
 
+#endif /* __CYGWIN__ */
+
 #ifdef __cplusplus
 };
 #endif

 However, I did add code to Makefile.common so that if you say:
 
 make CFLAGS=-g it will remove any optimization from CXXFLAGS as
 well.

Thanks.  It's just that... I usually use this the other way around.
The dir is built with CFLAGS/CXXFLAGS=-g and then I call make like
this for some optimization testing:

  make CFLAGS='-g -O2'   :}

 I have nearly everything working again but I'm surprised to find out
 that I can't build dump_setup.o with FC16 installed mingw compilers due

Do you mean F17?  F16 only came with the old mingw32 stuff.

 to complaints about missing definitions for:
 
 NT_SUCCESS
 OBJ_CASE_INSENSITIVE
 InitializeObjectAttributes
 
 I can't build strace.o because of