Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com Content-Type: text/plain; charset="iso-8859-15" From: Tim Prince Reply-To: tprince AT computer DOT org To: Cygwin Discussion , 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/