Re: odd 'configure' problems

Re: odd 'configure' problems

[Phil Edwards]

> You say Cygwin, but I also see things pointing to Mingw includes. I'm
> a bit confused.

Earnie Boyd also mentioned this to me.  Mea culpa; I did not realize
that the split between the two systems was that significant.  Let me
try again:  :-)

    - I installed Cygwin B20.1 (the "full.exe" with the compiler)
    - Then I installed Mingw32 over that, as documented on the web
    - Then I made Mingw32 the default, as documented

I guess I should say that all the tools are Cygwin, with their required
cygwin1.dll, but the compiler produces -mno-cygwin stuff by default.


> A typical problem when using Cygwin gcc to produce Mingw code (ie.,
> the now-famous -mno-cygwin mode) happens when your testcase includes
> a file that DOES NOT exist in the Mingw includes, but DOES exist in
> the Cygwin includes. What happens is that you get wrong, or at best
> confused, results. See my -mno-cygwin-howto for more info
> ( http://www.xraylith.wisc.edu/~khan/software/gnu-win32/ ).

Been there, done that.  :-)

> Either way, test for mmap should do the right thing. Can you please
> send me the autoconf test script that checks for mmap? Autoconf is
> not infallible of course. Feel free to email it to me directly.

Done.  I don't know where caddr_t is supposed to be typedef'd, but
my guess would be sys/types.h.  I'll assume that I'm getting the
"wrong" sys/types.h for now.

> > The second problem is looking for malloc.h.  This file is present but 
> > is incorrectly reported as missing, because one of its sub-includes is
> > not being found:
>
> This is a bug in the mingw32 headers distributed with Cygwin b20.1. You
> can replace those headers with the one I distribute with egcs-1.1.2 for
> mingw32. See:
>   
>   ftp://ftp.xraylith.wisc.edu/pub/khan/gnu-win32/mingw32/runtime/
>
> Here's a patch for the malloc.h problem:

This is ironic.  I had replaced (or thought I had) those headers a few
months ago, but then ran into a problem caused by malloc.h including
alloc.h!  The posted solution at the time was to remove alloc.h and allow
the compiler to find the Cygwin version.

So when I went to apply your patch, I tunneled way down into the Cygwin
directory structure, and found that mingw32/include/alloc.h was there,
but had been renamed into "Mumit_Khan_says_to_rm_alloc.h" just in case
I needed it.  :-)

After this patch, HAVE_MALLOC_H is correctly diagnosed.  Thanks!


Phil


--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: odd 'configure' problems

[Mumit Khan]

On Tue, 15 Jun 1999, Phil Edwards wrote:

> I guess I should say that all the tools are Cygwin, with their required
> cygwin1.dll, but the compiler produces -mno-cygwin stuff by default.

A good way to think of this is in terms of cross-compiling -- whenever
you specify -mno-cygwin, you're cross-compiling from Cygwin host to
Mingw target. Cross-compilation unfortunately has some pitfalls which
you have to look out for.

> Done.  I don't know where caddr_t is supposed to be typedef'd, but
> my guess would be sys/types.h.  I'll assume that I'm getting the
> "wrong" sys/types.h for now.

There *is* no caddr_t in neither ANSI nor POSIX. It's something that 
lots of the Unix headers define, but it doesn't have to be there. 

Hey, just be happy that you're getting the right result in this case, 
even if for the wrong reasons ;-) 

> configure:1337: checking for working mmap
> configure:1485: gcc -o conftest -g -O2   conftest.c  1>&5
> In file included from configure:1370:
> D:/cygnus/cygwin-b20/H-i586-cygwin32/bin/../lib/gcc-lib/i586-cygwin32/egcs-2.91.
> 66/../../../../i586-cygwin32/include/sys/mman.h:31: parse error before `mmap'
> D:/cygnus/cygwin-b20/H-i586-cygwin32/bin/../lib/gcc-lib/i586-cygwin32/egcs-2.91.
> 66/../../../../i586-cygwin32/include/sys/mman.h:31: parse error before `__addr'
> D:/cygnus/cygwin-b20/H-i586-cygwin32/bin/../lib/gcc-lib/i586-cygwin32/egcs-2.91.
> 66/../../../../i586-cygwin32/include/sys/mman.h:31: warning: data definition has no type or storage class

Here's your problem right there! Cygwin hsa sys/mman.h, but Mingw doesn't.
Cygwin compiler in -mno-cygwin mode first searches the Mingw headers, and
then continues on with the default headers, which happens to be Cygwin
specific. In this case, it finds the it finds sys/mman.h, which has 
nothing to do with Cygwin and complains.

It all has to do with -mno-cygwin mode, which is not as well tested or
used, and that's why folks continue to get "surprised" at the weird
little problems like this. I use a cross compiler on Unix to build Mingw 
binaries, and never have to deal with this "damn! accidentally picked up 
the wrong includes again" problem.

One solution is to create a "real" cross-compiler from Cygwin to Mingw
and then use that instead. The same instructions that I've posted on
creating x-compilers will apply there as well. Disk space is much much
cheaper than time and headache.

Considering the number of messages I've responded to over the past year
or so (lots sent directly to me), I'm beginning to consider -mno-cygwin
evil ...

Regards,
Mumit



--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: odd 'configure' problems

[Phil Edwards]

> You say Cygwin, but I also see things pointing to Mingw includes. I'm
> a bit confused.

Earnie Boyd also mentioned this to me.  Mea culpa; I did not realize
that the split between the two systems was that significant.  Let me
try again:  :-)

    - I installed Cygwin B20.1 (the "full.exe" with the compiler)
    - Then I installed Mingw32 over that, as documented on the web
    - Then I made Mingw32 the default, as documented

I guess I should say that all the tools are Cygwin, with their required
cygwin1.dll, but the compiler produces -mno-cygwin stuff by default.


> A typical problem when using Cygwin gcc to produce Mingw code (ie.,
> the now-famous -mno-cygwin mode) happens when your testcase includes
> a file that DOES NOT exist in the Mingw includes, but DOES exist in
> the Cygwin includes. What happens is that you get wrong, or at best
> confused, results. See my -mno-cygwin-howto for more info
> ( http://www.xraylith.wisc.edu/~khan/software/gnu-win32/ ).

Been there, done that.  :-)

> Either way, test for mmap should do the right thing. Can you please
> send me the autoconf test script that checks for mmap? Autoconf is
> not infallible of course. Feel free to email it to me directly.

Done.  I don't know where caddr_t is supposed to be typedef'd, but
my guess would be sys/types.h.  I'll assume that I'm getting the
"wrong" sys/types.h for now.

> > The second problem is looking for malloc.h.  This file is present but 
> > is incorrectly reported as missing, because one of its sub-includes is
> > not being found:
>
> This is a bug in the mingw32 headers distributed with Cygwin b20.1. You
> can replace those headers with the one I distribute with egcs-1.1.2 for
> mingw32. See:
>   
>   ftp://ftp.xraylith.wisc.edu/pub/khan/gnu-win32/mingw32/runtime/
>
> Here's a patch for the malloc.h problem:

This is ironic.  I had replaced (or thought I had) those headers a few
months ago, but then ran into a problem caused by malloc.h including
alloc.h!  The posted solution at the time was to remove alloc.h and allow
the compiler to find the Cygwin version.

So when I went to apply your patch, I tunneled way down into the Cygwin
directory structure, and found that mingw32/include/alloc.h was there,
but had been renamed into "Mumit_Khan_says_to_rm_alloc.h" just in case
I needed it.  :-)

After this patch, HAVE_MALLOC_H is correctly diagnosed.  Thanks!


Phil


--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: odd 'configure' problems

[Mumit Khan]

On Tue, 15 Jun 1999, Phil Edwards wrote:

> I guess I should say that all the tools are Cygwin, with their required
> cygwin1.dll, but the compiler produces -mno-cygwin stuff by default.

A good way to think of this is in terms of cross-compiling -- whenever
you specify -mno-cygwin, you're cross-compiling from Cygwin host to
Mingw target. Cross-compilation unfortunately has some pitfalls which
you have to look out for.

> Done.  I don't know where caddr_t is supposed to be typedef'd, but
> my guess would be sys/types.h.  I'll assume that I'm getting the
> "wrong" sys/types.h for now.

There *is* no caddr_t in neither ANSI nor POSIX. It's something that 
lots of the Unix headers define, but it doesn't have to be there. 

Hey, just be happy that you're getting the right result in this case, 
even if for the wrong reasons ;-) 

> configure:1337: checking for working mmap
> configure:1485: gcc -o conftest -g -O2   conftest.c  1>&5
> In file included from configure:1370:
> D:/cygnus/cygwin-b20/H-i586-cygwin32/bin/../lib/gcc-lib/i586-cygwin32/egcs-2.91.
> 66/../../../../i586-cygwin32/include/sys/mman.h:31: parse error before `mmap'
> D:/cygnus/cygwin-b20/H-i586-cygwin32/bin/../lib/gcc-lib/i586-cygwin32/egcs-2.91.
> 66/../../../../i586-cygwin32/include/sys/mman.h:31: parse error before `__addr'
> D:/cygnus/cygwin-b20/H-i586-cygwin32/bin/../lib/gcc-lib/i586-cygwin32/egcs-2.91.
> 66/../../../../i586-cygwin32/include/sys/mman.h:31: warning: data definition has no type or storage class

Here's your problem right there! Cygwin hsa sys/mman.h, but Mingw doesn't.
Cygwin compiler in -mno-cygwin mode first searches the Mingw headers, and
then continues on with the default headers, which happens to be Cygwin
specific. In this case, it finds the it finds sys/mman.h, which has 
nothing to do with Cygwin and complains.

It all has to do with -mno-cygwin mode, which is not as well tested or
used, and that's why folks continue to get "surprised" at the weird
little problems like this. I use a cross compiler on Unix to build Mingw 
binaries, and never have to deal with this "damn! accidentally picked up 
the wrong includes again" problem.

One solution is to create a "real" cross-compiler from Cygwin to Mingw
and then use that instead. The same instructions that I've posted on
creating x-compilers will apply there as well. Disk space is much much
cheaper than time and headache.

Considering the number of messages I've responded to over the past year
or so (lots sent directly to me), I'm beginning to consider -mno-cygwin
evil ...

Regards,
Mumit



--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: odd 'configure' problems

[Phil Edwards]

> On Tue, Jun 15, 1999 at 06:25:47PM -0400, Phil Edwards wrote:
> >I thought that this was going to become the default, so that the
> >cygwin1.dll wouldn't be required?
>
> Nope.  There are no plans to make -mno-cygwin the default.  It would
> require massive (and pointless) rewriting of either a lot of configure
> scripts or a lot of utilities.


You may wish to rewrite the Mingw32 paragraph of /cygwin/links.html
on sourceware to remove this possibility, then.  That's where I got 
the idea from, and I assumed it was canonical.

Phil


--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

odd 'configure' problems

[Phil Edwards]

I am trying to get a 'configure' script to give me valid answers under
a variety of systems.  The last one on the list is Cygwin (because VC++
is just useless).  The configure runs fine, but two of its answers look
to be questionable.

First, it stores that mmap() is unavailable, even though the Cygwin web
site claims it is.  The conftest is failing, not because mmap() isn't
there, but because using the Mingw32 setup seems to have broken something.
This is the section out of the config.log (more stuff below):

======================================================================
configure:1337: checking for working mmap
configure:1485: gcc -o conftest -g -O2   conftest.c  1>&5
In file included from configure:1370:
D:/cygnus/cygwin-b20/H-i586-cygwin32/bin/../lib/gcc-lib/i586-cygwin32/egcs-2.91.66/../../../../i586-cygwin32/include/sys/mman.h:31: parse error before `mmap'
D:/cygnus/cygwin-b20/H-i586-cygwin32/bin/../lib/gcc-lib/i586-cygwin32/egcs-2.91.66/../../../../i586-cygwin32/include/sys/mman.h:31: parse error before `__addr'
D:/cygnus/cygwin-b20/H-i586-cygwin32/bin/../lib/gcc-lib/i586-cygwin32/egcs-2.91.66/../../../../i586-cygwin32/include/sys/mman.h:31: warning: data definition has no type or storage class
D:/cygnus/cygwin-b20/H-i586-cygwin32/bin/../lib/gcc-lib/i586-cygwin32/egcs-2.91.66/../../../../i586-cygwin32/include/sys/mman.h:32: parse error before `__addr'
D:/cygnus/cygwin-b20/H-i586-cygwin32/bin/../lib/gcc-lib/i586-cygwin32/egcs-2.91.66/../../../../i586-cygwin32/include/sys/mman.h:33: parse error before `__addr'
D:/cygnus/cygwin-b20/H-i586-cygwin32/bin/../lib/gcc-lib/i586-cygwin32/egcs-2.91.66/../../../../i586-cygwin32/include/sys/mman.h:34: parse error before `__addr'
configure: In function `main':
configure:1457: warning: comparison between pointer and integer
configure: failed program was:
#line 1345 "configure"
#include "confdefs.h"

/* Thanks to Mike Haertel and Jim Avera for this test.
   Here is a matrix of mmap possibilities:
	mmap private not fixed
	mmap private fixed at somewhere currently unmapped
	mmap private fixed at somewhere already mapped
	mmap shared not fixed
	mmap shared fixed at somewhere currently unmapped
	mmap shared fixed at somewhere already mapped
   For private mappings, we should verify that changes cannot be read()
   back from the file, nor mmap's back from the file at a different
   address.  (There have been systems where private was not correctly
   implemented like the infamous i386 svr4.0, and systems where the
   VM page cache was not coherent with the filesystem buffer cache
   like early versions of FreeBSD and possibly contemporary NetBSD.)
   For shared mappings, we should conversely verify that changes get
   propogated back to all the places they're supposed to be.

   Grep wants private fixed already mapped.
   The main things grep needs to know about mmap are:
   * does it exist and is it safe to write into the mmap'd area
   * how to use it (BSD variants)  */
#include <sys/types.h>
#include <fcntl.h>
#include <sys/mman.h>

/* This mess was copied from the GNU getpagesize.h.  */
#ifndef HAVE_GETPAGESIZE
# ifdef HAVE_UNISTD_H
#  include <unistd.h>
# endif

/* Assume that all systems that can run configure have sys/param.h.  */
# ifndef HAVE_SYS_PARAM_H
#  define HAVE_SYS_PARAM_H 1
# endif
======================================================================

The rest of that code is irrelevent and has been snipped.  For what it's
worth, the word that gcc is complaining about on sys/mman.h:31 is the
"caddr_t" type, which doesn't seem to have been declared even though
sys/types.h is #included earlier in sys/mman.h.

The second problem is looking for malloc.h.  This file is present but 
is incorrectly reported as missing, because one of its sub-includes is
not being found:

======================================================================
configure:1855: checking for malloc.h
configure:1865: gcc -E  conftest.c >/dev/null 2>conftest.out
In file included from configure:1861:
D:/cygnus/cygwin-b20/H-i586-cygwin32/bin/../lib/gcc-lib/i586-cygwin32/egcs-2.91.66/../../../../i586-cygwin32/include/mingw32/malloc.h:35: alloc.h: No such file or directory
configure: failed program was:
#line 1860 "configure"
#include "confdefs.h"
#include <malloc.h>

======================================================================

(That's the entire test file as reported in the log.)


Any thoughts?  Do I have an old Cygwin (B20.1) or an old Mingw32?  Am
I just being stupid somewhere?

(If you send a reply to the list, please don't cc a copy to me.  Thanks!)
Phil


--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: odd 'configure' problems

[Earnie Boyd]

--- Mumit Khan <khan@xraylith.wisc.EDU> wrote:
> One solution is to create a "real" cross-compiler from Cygwin to Mingw
> and then use that instead. The same instructions that I've posted on
> creating x-compilers will apply there as well. Disk space is much much
> cheaper than time and headache.
> 
> Considering the number of messages I've responded to over the past year
> or so (lots sent directly to me), I'm beginning to consider -mno-cygwin
> evil ...

I use two separate environments, one for cygwin and one for mingw32.  The cross
polution doesn't happen that way.  I have two different DOS bat files whose
first line reads `sh -c "bin/umount / && bin/mount c:/newroot /"` where newroot
is replaced with the top directory of either mingw32 or cygwin dependent upon
which file it's in.  I then created short cuts to those bat files on my
desktop.  If I want to use cygwin I click on the cygwin icon.  If I want to use
mingw32 I click on the mingw32 icon.

NOTE: You can't use both at the same time this way, so don't try.
===
YAWIA,
Earnie Boyd < mailto:earnie_boyd@yahoo.com >

Newbies, please visit
< http://www.freeyellow.com/members5/gw32/index.html >
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com


--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: odd 'configure' problems

[cygwin]

On Tue, Jun 15, 1999 at 06:25:47PM -0400, Phil Edwards wrote:
>I thought that this was going to become the default, so that the
>cygwin1.dll wouldn't be required?

Nope.  There are no plans to make -mno-cygwin the default.  It would
require massive (and pointless) rewriting of either a lot of configure
scripts or a lot of utilities.

cgf

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: odd 'configure' problems

[Phil Edwards]

> A good way to think of this is in terms of cross-compiling 

Interesting.  I hadn't thought there was that much of a difference (after
all, it's the same hardware, same software, same OS, etc).  I'll keep
this in mind.


> There *is* no caddr_t in neither ANSI nor POSIX. It's something that 
> lots of the Unix headers define, but it doesn't have to be there. 

Oh.  Figures.  "Core addresses" doesn't sound like POSIX would like it.


> Hey, just be happy that you're getting the right result in this case, 
> even if for the wrong reasons ;-) 
[snip]
> Here's your problem right there! Cygwin hsa sys/mman.h, but Mingw doesn't.

Oh.  Mingw32 doesn't have mmap()?  Yuck.

So, is it easier to "undo" the Mingw32 overwrites, or is it easier to
just uninstall everything and reinstall Cygwin cleanly?


> I use a cross compiler on Unix to build Mingw binaries

Must be nice.  :-)

I have to be able to hand instructions to a group of people that don't
know or care about compilers, saying, "Install these programs, such as
Cygwin full.exe and the Mingw32 package, and our utilities will then
configure/build out-of-box for us."

So while the tweaking and cross-compiling is fine for my own use (and
is in fact a lot more interesting to me than my real job), I can't
apply it as a final solution.  Nor can I even try it, since I don't
have any other machines to /easily/ test on besides my own.


> Considering the number of messages I've responded to over the past year
> or so (lots sent directly to me), I'm beginning to consider -mno-cygwin
> evil ...

I thought that this was going to become the default, so that the
cygwin1.dll wouldn't be required?

Phil


--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: odd 'configure' problems

[Earnie Boyd]

--- Phil Edwards <pedwards@jaj.com> wrote:
> 
> I am trying to get a 'configure' script to give me valid answers under
> a variety of systems.  The last one on the list is Cygwin (because VC++
> is just useless).  The configure runs fine, but two of its answers look
> to be questionable.
> 
> First, it stores that mmap() is unavailable, even though the Cygwin web
> site claims it is.  The conftest is failing, not because mmap() isn't
> there, but because using the Mingw32 setup seems to have broken something.
> This is the section out of the config.log (more stuff below):
> 
-8<-
> 
> 
> Any thoughts?  Do I have an old Cygwin (B20.1) or an old Mingw32?  Am
> I just being stupid somewhere?
> 

So are you building under Mingw32 or under Cygwin?  Paste or attach a plain
text file of the output of `cygcheck -s -v -r'.

===
YAWIA,
Earnie Boyd < mailto:earnie_boyd@yahoo.com >

Newbies, please visit
< http://www.freeyellow.com/members5/gw32/index.html >
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com


--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: odd 'configure' problems

[Mumit Khan]

Phil Edwards <pedwards@jaj.com> writes:
> 
> I am trying to get a 'configure' script to give me valid answers under
> a variety of systems.  The last one on the list is Cygwin (because VC++
> is just useless).  The configure runs fine, but two of its answers look
> to be questionable.
> 
> First, it stores that mmap() is unavailable, even though the Cygwin web
> site claims it is.  The conftest is failing, not because mmap() isn't
> there, but because using the Mingw32 setup seems to have broken something.
> This is the section out of the config.log (more stuff below):

Phil,

You say Cygwin, but I also see things pointing to Mingw includes. I'm
a bit confused.

A typical problem when using Cygwin gcc to produce Mingw code (ie.,
the now-famous -mno-cygwin mode) happens when your testcase includes
a file that DOES NOT exist in the Mingw includes, but DOES exist in
the Cygwin includes. What happens is that you get wrong, or at best
confused, results. See my -mno-cygwin-howto for more info
( http://www.xraylith.wisc.edu/~khan/software/gnu-win32/ ).

Either way, test for mmap should do the right thing. Can you please
send me the autoconf test script that checks for mmap? Autoconf is
not infallible of course. Feel free to email it to me directly.

> The second problem is looking for malloc.h.  This file is present but 
> is incorrectly reported as missing, because one of its sub-includes is
> not being found:

This is a bug in the mingw32 headers distributed with Cygwin b20.1. You
can replace those headers with the one I distribute with egcs-1.1.2 for
mingw32. See:
  
  ftp://ftp.xraylith.wisc.edu/pub/khan/gnu-win32/mingw32/runtime/

Here's a patch for the malloc.h problem:

--- //C/Cygnus/cygwin-b20/H-i586-cygwin32/i586-cygwin32/include/mingw32/malloc.h	Tue Dec 01 12:42:46 1998
+++ //C/egcs-1.1.2/i386-mingw32/include/malloc.h	Mon Mar 15 17:52:30 1999
@@ -32,13 +32,31 @@
 #ifndef _MALLOC_H_
 #define _MALLOC_H_
 
-#include <alloc.h>
+#include <stdlib.h>
 
 #ifndef RC_INVOKED
 
+/*
+ * The structure used to walk through the heap with _heapwalk.
+ * TODO: This is a guess at the internals of this structure.
+ */
+typedef	struct _heapinfo
+{
+	void*		ptr;
+	unsigned int	size;
+	int		in_use;
+} _HEAPINFO;
+
+
 #ifdef	__cplusplus
 extern "C" {
 #endif
+
+int	_heapwalk (_HEAPINFO* pHeapinfo);
+
+#ifndef	_NO_OLDNAMES
+int	heapwalk (_HEAPINFO* pHeapinfo);
+#endif	/* Not _NO_OLDNAMES */
 
 int	_heapchk ();	/* Verify heap integrety. */
 int	_heapmin ();	/* Return unused heap to the OS. */


Regards,
Mumit

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: odd 'configure' problems

[Geoffrey Noer]

On Tue, Jun 15, 1999, Mumit Khan wrote:
[...]
> btw, I was perhaps a bit too harsh on -mno-cygwin, and possibly because
> I don't have a clean solution to the "picking up wrong header and lib"
> problem. One way of course is to use a combination of -nostdinc and
> -idirafter <...> when -mno-cygwin is specified in the specs file, and
> that might just work very well.

Yep, there are pitfalls currently.  We would like volunteers to help
make the mingw support better, including submitting patches that make
the source tree build libstdc++ without Cygwin as well as with.  Some
rewriting of the specs file may help this mode as well.

Until this happens, people will run into problems unless they're
careful.

-- 
Geoffrey Noer		Email: noer@cygnus.com
Cygnus Solutions

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: odd 'configure' problems

[Mumit Khan]

Phil Edwards <pedwards@jaj.com> writes:
> 
> > A good way to think of this is in terms of cross-compiling 
> 
> Interesting.  I hadn't thought there was that much of a difference (after
> all, it's the same hardware, same software, same OS, etc).  I'll keep
> this in mind.

Actually, it's the OS that's quite different. Think of Cygwin as a
different OS, and it all makes sense.

> So, is it easier to "undo" the Mingw32 overwrites, or is it easier to
> just uninstall everything and reinstall Cygwin cleanly?

I don't know how and what you installed, so it's impossible to answer.
Normally, users simply install the full.exe, which installs the Cygwin
compilers and runtime environment. The runtime includes Mingw headers
and libraries and so on. Most developers update the compilers, but
that doesn't change the Mingw headers. Unless of course you installed
the Mingw runtime that I distribute with Mingw32 binaries (and those
have bug fixes that are not in the Cygwin release).

> I have to be able to hand instructions to a group of people that don't
> know or care about compilers, saying, "Install these programs, such as
> Cygwin full.exe and the Mingw32 package, and our utilities will then
> configure/build out-of-box for us."
> 
> So while the tweaking and cross-compiling is fine for my own use (and
> is in fact a lot more interesting to me than my real job), I can't
> apply it as a final solution.  Nor can I even try it, since I don't
> have any other machines to /easily/ test on besides my own.

I understand. However, as long as you understand the limitations of
Cygwin -mno-cygwin mode, it's a very reasonable option.

> > Considering the number of messages I've responded to over the past year
> > or so (lots sent directly to me), I'm beginning to consider -mno-cygwin
> > evil ...
> 
> I thought that this was going to become the default, so that the
> cygwin1.dll wouldn't be required?
> 

I'm not privy to what Cygnus' plans are regarding this, so I can't comment.

btw, I was perhaps a bit too harsh on -mno-cygwin, and possibly because
I don't have a clean solution to the "picking up wrong header and lib"
problem. One way of course is to use a combination of -nostdinc and
-idirafter <...> when -mno-cygwin is specified in the specs file, and
that might just work very well.

Regards,
Mumit


--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: odd 'configure' problems

[Chris Faylor]

On Wed, Jun 16, 1999 at 11:35:38AM -0400, Phil Edwards wrote:
>
>
>> On Tue, Jun 15, 1999 at 06:25:47PM -0400, Phil Edwards wrote:
>> >I thought that this was going to become the default, so that the
>> >cygwin1.dll wouldn't be required?
>>
>> Nope.  There are no plans to make -mno-cygwin the default.  It would
>> require massive (and pointless) rewriting of either a lot of configure
>> scripts or a lot of utilities.
>
>You may wish to rewrite the Mingw32 paragraph of /cygwin/links.html
>on sourceware to remove this possibility, then.  That's where I got 
>the idea from, and I assumed it was canonical.

Done.  Thanks for letting me know about this.

cgf

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: odd 'configure' problems

[Geoffrey Noer]

On Tue, Jun 15, 1999, Mumit Khan wrote:
[...]
> btw, I was perhaps a bit too harsh on -mno-cygwin, and possibly because
> I don't have a clean solution to the "picking up wrong header and lib"
> problem. One way of course is to use a combination of -nostdinc and
> -idirafter <...> when -mno-cygwin is specified in the specs file, and
> that might just work very well.

Yep, there are pitfalls currently.  We would like volunteers to help
make the mingw support better, including submitting patches that make
the source tree build libstdc++ without Cygwin as well as with.  Some
rewriting of the specs file may help this mode as well.

Until this happens, people will run into problems unless they're
careful.

-- 
Geoffrey Noer		Email: noer@cygnus.com
Cygnus Solutions

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: odd 'configure' problems

[Chris Faylor]

On Wed, Jun 16, 1999 at 11:35:38AM -0400, Phil Edwards wrote:
>
>
>> On Tue, Jun 15, 1999 at 06:25:47PM -0400, Phil Edwards wrote:
>> >I thought that this was going to become the default, so that the
>> >cygwin1.dll wouldn't be required?
>>
>> Nope.  There are no plans to make -mno-cygwin the default.  It would
>> require massive (and pointless) rewriting of either a lot of configure
>> scripts or a lot of utilities.
>
>You may wish to rewrite the Mingw32 paragraph of /cygwin/links.html
>on sourceware to remove this possibility, then.  That's where I got 
>the idea from, and I assumed it was canonical.

Done.  Thanks for letting me know about this.

cgf

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: odd 'configure' problems

[Phil Edwards]

> On Tue, Jun 15, 1999 at 06:25:47PM -0400, Phil Edwards wrote:
> >I thought that this was going to become the default, so that the
> >cygwin1.dll wouldn't be required?
>
> Nope.  There are no plans to make -mno-cygwin the default.  It would
> require massive (and pointless) rewriting of either a lot of configure
> scripts or a lot of utilities.


You may wish to rewrite the Mingw32 paragraph of /cygwin/links.html
on sourceware to remove this possibility, then.  That's where I got 
the idea from, and I assumed it was canonical.

Phil


--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: odd 'configure' problems

[Earnie Boyd]

--- Mumit Khan <khan@xraylith.wisc.EDU> wrote:
> One solution is to create a "real" cross-compiler from Cygwin to Mingw
> and then use that instead. The same instructions that I've posted on
> creating x-compilers will apply there as well. Disk space is much much
> cheaper than time and headache.
> 
> Considering the number of messages I've responded to over the past year
> or so (lots sent directly to me), I'm beginning to consider -mno-cygwin
> evil ...

I use two separate environments, one for cygwin and one for mingw32.  The cross
polution doesn't happen that way.  I have two different DOS bat files whose
first line reads `sh -c "bin/umount / && bin/mount c:/newroot /"` where newroot
is replaced with the top directory of either mingw32 or cygwin dependent upon
which file it's in.  I then created short cuts to those bat files on my
desktop.  If I want to use cygwin I click on the cygwin icon.  If I want to use
mingw32 I click on the mingw32 icon.

NOTE: You can't use both at the same time this way, so don't try.
===
YAWIA,
Earnie Boyd < mailto:earnie_boyd@yahoo.com >

Newbies, please visit
< http://www.freeyellow.com/members5/gw32/index.html >
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com


--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: odd 'configure' problems

[cygwin]

On Tue, Jun 15, 1999 at 06:25:47PM -0400, Phil Edwards wrote:
>I thought that this was going to become the default, so that the
>cygwin1.dll wouldn't be required?

Nope.  There are no plans to make -mno-cygwin the default.  It would
require massive (and pointless) rewriting of either a lot of configure
scripts or a lot of utilities.

cgf

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: odd 'configure' problems

[Mumit Khan]

Phil Edwards <pedwards@jaj.com> writes:
> 
> > A good way to think of this is in terms of cross-compiling 
> 
> Interesting.  I hadn't thought there was that much of a difference (after
> all, it's the same hardware, same software, same OS, etc).  I'll keep
> this in mind.

Actually, it's the OS that's quite different. Think of Cygwin as a
different OS, and it all makes sense.

> So, is it easier to "undo" the Mingw32 overwrites, or is it easier to
> just uninstall everything and reinstall Cygwin cleanly?

I don't know how and what you installed, so it's impossible to answer.
Normally, users simply install the full.exe, which installs the Cygwin
compilers and runtime environment. The runtime includes Mingw headers
and libraries and so on. Most developers update the compilers, but
that doesn't change the Mingw headers. Unless of course you installed
the Mingw runtime that I distribute with Mingw32 binaries (and those
have bug fixes that are not in the Cygwin release).

> I have to be able to hand instructions to a group of people that don't
> know or care about compilers, saying, "Install these programs, such as
> Cygwin full.exe and the Mingw32 package, and our utilities will then
> configure/build out-of-box for us."
> 
> So while the tweaking and cross-compiling is fine for my own use (and
> is in fact a lot more interesting to me than my real job), I can't
> apply it as a final solution.  Nor can I even try it, since I don't
> have any other machines to /easily/ test on besides my own.

I understand. However, as long as you understand the limitations of
Cygwin -mno-cygwin mode, it's a very reasonable option.

> > Considering the number of messages I've responded to over the past year
> > or so (lots sent directly to me), I'm beginning to consider -mno-cygwin
> > evil ...
> 
> I thought that this was going to become the default, so that the
> cygwin1.dll wouldn't be required?
> 

I'm not privy to what Cygnus' plans are regarding this, so I can't comment.

btw, I was perhaps a bit too harsh on -mno-cygwin, and possibly because
I don't have a clean solution to the "picking up wrong header and lib"
problem. One way of course is to use a combination of -nostdinc and
-idirafter <...> when -mno-cygwin is specified in the specs file, and
that might just work very well.

Regards,
Mumit


--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: odd 'configure' problems

[Phil Edwards]

> A good way to think of this is in terms of cross-compiling 

Interesting.  I hadn't thought there was that much of a difference (after
all, it's the same hardware, same software, same OS, etc).  I'll keep
this in mind.


> There *is* no caddr_t in neither ANSI nor POSIX. It's something that 
> lots of the Unix headers define, but it doesn't have to be there. 

Oh.  Figures.  "Core addresses" doesn't sound like POSIX would like it.


> Hey, just be happy that you're getting the right result in this case, 
> even if for the wrong reasons ;-) 
[snip]
> Here's your problem right there! Cygwin hsa sys/mman.h, but Mingw doesn't.

Oh.  Mingw32 doesn't have mmap()?  Yuck.

So, is it easier to "undo" the Mingw32 overwrites, or is it easier to
just uninstall everything and reinstall Cygwin cleanly?


> I use a cross compiler on Unix to build Mingw binaries

Must be nice.  :-)

I have to be able to hand instructions to a group of people that don't
know or care about compilers, saying, "Install these programs, such as
Cygwin full.exe and the Mingw32 package, and our utilities will then
configure/build out-of-box for us."

So while the tweaking and cross-compiling is fine for my own use (and
is in fact a lot more interesting to me than my real job), I can't
apply it as a final solution.  Nor can I even try it, since I don't
have any other machines to /easily/ test on besides my own.


> Considering the number of messages I've responded to over the past year
> or so (lots sent directly to me), I'm beginning to consider -mno-cygwin
> evil ...

I thought that this was going to become the default, so that the
cygwin1.dll wouldn't be required?

Phil


--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: odd 'configure' problems

[Mumit Khan]

Phil Edwards <pedwards@jaj.com> writes:
> 
> I am trying to get a 'configure' script to give me valid answers under
> a variety of systems.  The last one on the list is Cygwin (because VC++
> is just useless).  The configure runs fine, but two of its answers look
> to be questionable.
> 
> First, it stores that mmap() is unavailable, even though the Cygwin web
> site claims it is.  The conftest is failing, not because mmap() isn't
> there, but because using the Mingw32 setup seems to have broken something.
> This is the section out of the config.log (more stuff below):

Phil,

You say Cygwin, but I also see things pointing to Mingw includes. I'm
a bit confused.

A typical problem when using Cygwin gcc to produce Mingw code (ie.,
the now-famous -mno-cygwin mode) happens when your testcase includes
a file that DOES NOT exist in the Mingw includes, but DOES exist in
the Cygwin includes. What happens is that you get wrong, or at best
confused, results. See my -mno-cygwin-howto for more info
( http://www.xraylith.wisc.edu/~khan/software/gnu-win32/ ).

Either way, test for mmap should do the right thing. Can you please
send me the autoconf test script that checks for mmap? Autoconf is
not infallible of course. Feel free to email it to me directly.

> The second problem is looking for malloc.h.  This file is present but 
> is incorrectly reported as missing, because one of its sub-includes is
> not being found:

This is a bug in the mingw32 headers distributed with Cygwin b20.1. You
can replace those headers with the one I distribute with egcs-1.1.2 for
mingw32. See:
  
  ftp://ftp.xraylith.wisc.edu/pub/khan/gnu-win32/mingw32/runtime/

Here's a patch for the malloc.h problem:

--- //C/Cygnus/cygwin-b20/H-i586-cygwin32/i586-cygwin32/include/mingw32/malloc.h	Tue Dec 01 12:42:46 1998
+++ //C/egcs-1.1.2/i386-mingw32/include/malloc.h	Mon Mar 15 17:52:30 1999
@@ -32,13 +32,31 @@
 #ifndef _MALLOC_H_
 #define _MALLOC_H_
 
-#include <alloc.h>
+#include <stdlib.h>
 
 #ifndef RC_INVOKED
 
+/*
+ * The structure used to walk through the heap with _heapwalk.
+ * TODO: This is a guess at the internals of this structure.
+ */
+typedef	struct _heapinfo
+{
+	void*		ptr;
+	unsigned int	size;
+	int		in_use;
+} _HEAPINFO;
+
+
 #ifdef	__cplusplus
 extern "C" {
 #endif
+
+int	_heapwalk (_HEAPINFO* pHeapinfo);
+
+#ifndef	_NO_OLDNAMES
+int	heapwalk (_HEAPINFO* pHeapinfo);
+#endif	/* Not _NO_OLDNAMES */
 
 int	_heapchk ();	/* Verify heap integrety. */
 int	_heapmin ();	/* Return unused heap to the OS. */


Regards,
Mumit

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: odd 'configure' problems

[Earnie Boyd]

--- Phil Edwards <pedwards@jaj.com> wrote:
> 
> I am trying to get a 'configure' script to give me valid answers under
> a variety of systems.  The last one on the list is Cygwin (because VC++
> is just useless).  The configure runs fine, but two of its answers look
> to be questionable.
> 
> First, it stores that mmap() is unavailable, even though the Cygwin web
> site claims it is.  The conftest is failing, not because mmap() isn't
> there, but because using the Mingw32 setup seems to have broken something.
> This is the section out of the config.log (more stuff below):
> 
-8<-
> 
> 
> Any thoughts?  Do I have an old Cygwin (B20.1) or an old Mingw32?  Am
> I just being stupid somewhere?
> 

So are you building under Mingw32 or under Cygwin?  Paste or attach a plain
text file of the output of `cygcheck -s -v -r'.

===
YAWIA,
Earnie Boyd < mailto:earnie_boyd@yahoo.com >

Newbies, please visit
< http://www.freeyellow.com/members5/gw32/index.html >
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com


--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

odd 'configure' problems

[Phil Edwards]

I am trying to get a 'configure' script to give me valid answers under
a variety of systems.  The last one on the list is Cygwin (because VC++
is just useless).  The configure runs fine, but two of its answers look
to be questionable.

First, it stores that mmap() is unavailable, even though the Cygwin web
site claims it is.  The conftest is failing, not because mmap() isn't
there, but because using the Mingw32 setup seems to have broken something.
This is the section out of the config.log (more stuff below):

======================================================================
configure:1337: checking for working mmap
configure:1485: gcc -o conftest -g -O2   conftest.c  1>&5
In file included from configure:1370:
D:/cygnus/cygwin-b20/H-i586-cygwin32/bin/../lib/gcc-lib/i586-cygwin32/egcs-2.91.66/../../../../i586-cygwin32/include/sys/mman.h:31: parse error before `mmap'
D:/cygnus/cygwin-b20/H-i586-cygwin32/bin/../lib/gcc-lib/i586-cygwin32/egcs-2.91.66/../../../../i586-cygwin32/include/sys/mman.h:31: parse error before `__addr'
D:/cygnus/cygwin-b20/H-i586-cygwin32/bin/../lib/gcc-lib/i586-cygwin32/egcs-2.91.66/../../../../i586-cygwin32/include/sys/mman.h:31: warning: data definition has no type or storage class
D:/cygnus/cygwin-b20/H-i586-cygwin32/bin/../lib/gcc-lib/i586-cygwin32/egcs-2.91.66/../../../../i586-cygwin32/include/sys/mman.h:32: parse error before `__addr'
D:/cygnus/cygwin-b20/H-i586-cygwin32/bin/../lib/gcc-lib/i586-cygwin32/egcs-2.91.66/../../../../i586-cygwin32/include/sys/mman.h:33: parse error before `__addr'
D:/cygnus/cygwin-b20/H-i586-cygwin32/bin/../lib/gcc-lib/i586-cygwin32/egcs-2.91.66/../../../../i586-cygwin32/include/sys/mman.h:34: parse error before `__addr'
configure: In function `main':
configure:1457: warning: comparison between pointer and integer
configure: failed program was:
#line 1345 "configure"
#include "confdefs.h"

/* Thanks to Mike Haertel and Jim Avera for this test.
   Here is a matrix of mmap possibilities:
	mmap private not fixed
	mmap private fixed at somewhere currently unmapped
	mmap private fixed at somewhere already mapped
	mmap shared not fixed
	mmap shared fixed at somewhere currently unmapped
	mmap shared fixed at somewhere already mapped
   For private mappings, we should verify that changes cannot be read()
   back from the file, nor mmap's back from the file at a different
   address.  (There have been systems where private was not correctly
   implemented like the infamous i386 svr4.0, and systems where the
   VM page cache was not coherent with the filesystem buffer cache
   like early versions of FreeBSD and possibly contemporary NetBSD.)
   For shared mappings, we should conversely verify that changes get
   propogated back to all the places they're supposed to be.

   Grep wants private fixed already mapped.
   The main things grep needs to know about mmap are:
   * does it exist and is it safe to write into the mmap'd area
   * how to use it (BSD variants)  */
#include <sys/types.h>
#include <fcntl.h>
#include <sys/mman.h>

/* This mess was copied from the GNU getpagesize.h.  */
#ifndef HAVE_GETPAGESIZE
# ifdef HAVE_UNISTD_H
#  include <unistd.h>
# endif

/* Assume that all systems that can run configure have sys/param.h.  */
# ifndef HAVE_SYS_PARAM_H
#  define HAVE_SYS_PARAM_H 1
# endif
======================================================================

The rest of that code is irrelevent and has been snipped.  For what it's
worth, the word that gcc is complaining about on sys/mman.h:31 is the
"caddr_t" type, which doesn't seem to have been declared even though
sys/types.h is #included earlier in sys/mman.h.

The second problem is looking for malloc.h.  This file is present but 
is incorrectly reported as missing, because one of its sub-includes is
not being found:

======================================================================
configure:1855: checking for malloc.h
configure:1865: gcc -E  conftest.c >/dev/null 2>conftest.out
In file included from configure:1861:
D:/cygnus/cygwin-b20/H-i586-cygwin32/bin/../lib/gcc-lib/i586-cygwin32/egcs-2.91.66/../../../../i586-cygwin32/include/mingw32/malloc.h:35: alloc.h: No such file or directory
configure: failed program was:
#line 1860 "configure"
#include "confdefs.h"
#include <malloc.h>

======================================================================

(That's the entire test file as reported in the log.)


Any thoughts?  Do I have an old Cygwin (B20.1) or an old Mingw32?  Am
I just being stupid somewhere?

(If you send a reply to the list, please don't cc a copy to me.  Thanks!)
Phil


--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com