Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Content-Type: text/plain;
  charset="iso-8859-15"
From: Tim Prince <tprince AT computer DOT org>
Reply-To: tprince AT computer DOT org
To: Cygwin Discussion <cygwin AT cygwin DOT com>, Superbiskit AT cox DOT net
Subject: Re: Surprises running gcc 3.2 configure on Cygwin
Date: Sun, 22 Sep 2002 19:08:21 -0700
References: <3D8E5E4C DOT 7070905 AT cox DOT net>
In-Reply-To: <3D8E5E4C.7070905@cox.net>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Message-Id: <20020923020823.500B82CC43@inet1.ywave.com>

On Sunday 22 September 2002 17:20, you wrote:
> IN THE VERY FIRST COMPILER TEST, I get these:
>
> ignoring nonexistent directory "../../include/w32api"
> ^^^^^^^^^^^^^^^^^^^^^^^
> GNU CPP version 3.2 20020912 (prerelease) (cpplib) (80386, BSD syntax)
> GNU C version 3.2 20020912 (prerelease) (i686-pc-cygwin)
>     compiled by GNU C version 3.2 20020912 (prerelease).
> ignoring nonexistent directory "/usr/local/gcc-3_2/i686-pc-cygwin/include"
> ^^^^^^^^^^^^^^^^^^^^^^^^^^
> ignoring nonexistent directory "/usr/local/gcc-3_2/i686-pc-cygwin/include"
> ignoring duplicate directory
> "/usr/local/gcc-3_2/lib/gcc-lib/i686-pc-cygwin/3.2/include"
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> #include "..." search starts here:
> #include <...> search starts here:
>  /usr/include/w32api
>
> QUESTION: Are the duplicate / nonexistent directories anything I should
> care about?
I don't get any such messages in the gcc-3.3 configure/, as I've already 
copied /usr/include to /usr/local/include, and I haven't tried to be fancy 
with specifying installation directories.  If you were using gcc-2.95 to 
bootstrap gcc-3.2, letting fixincludes modify the original /include could 
break your gcc-2.95 installation.
> ==========================================================================

> checking for basename... no
> ===================^^^^^^^^^
> but
> g:\HOME\Superbiskit>which basename
> which basename
> /usr/bin/basename
I assume the configure test of basename is failing.  Did you find out what 
the test is, and try it yourself?  Is it looking for a C library function, 
rather than a shell function?
>
> g:\HOME\Superbiskit>
> ==========================================================================
> checking for insque... no
> . . . .
> checking for mkstemps... no
>
> DOES IT MATTER?  Would they be fairly simple?
Evidently, gcc is prepared to build without them.
> ==========================================================================
> checking for vfork.h... no
> checking for working vfork... yes
>
> SEEMS STRANGE to have one and not the other.  DOES IT MATTER?
Since vfork is not a standard C function, no one says there need be such a 
header.  There are bigger isssues with vfork on Windows, see the list archive.
> ==========================================================================
> checking for working mmap... no
>
> I THOUGHT WE HAD THAT.  Or does it come with a working cygdaemon?
I guess it doesn't pass whatever test is presented, so we're better off 
without it.
> ==========================================================================
> checking if /usr/local/gcc-3_2/bin//gcc.exe supports -c -o file.o... no
> RATHER A SURPRISE?
>
> checking if we can lock with hard links... yes
>
> checking if libtool supports shared libraries... yes
> checking if package supports dlls... no
> checking whether to build shared libraries... no
>
> QUESTION: Does this mean that the gcc package currently isn't set up to
> use DLL's?  WHAT'S THE IMPACT?  I know the Cygwin environment is able to
> build DLL's.
I'm following David Billinghurst's old recommendation to configure 
--disable-shared.   Configure doesn't try these tests for me.  I would think 
these might be indications that --enable-shared isn't going to do all that's 
expected.

> ==========================================================================
> checking whether basename is declared... yes
> =========================================^^^^ But see above 'checking
> for basename'
Mine says no.
>
> checking whether getopt is declared... no
> =======================================^^^^ We do have one, don't we?
Do you mean a C callable function, or a scripting program?
>


-- 
Tim Prince

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/