Mail Archives: cygwin/2002/09/22/22:10:40
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/
- Raw text -