Subject: RE: include path
From: "Suhaib Siddiqi" <[email-masked]>
To: "Mumit Khan" <[email-masked]>, "Mike MacDonald" <[email-masked]>
Cc: <[email-masked]>
Date: Wed, 10 Nov 1999 14:25:47 -0500

Mike I suggest you use the default Cygwin installation. i.e.
/cygnus/cygwin-b20.  For X it works just fine.  The *.cf files are
pre-configured to find the needed executables.

I only make a cpp.exe executables symlink in
/cygnus/cygwin-b20/H-i586-cygwin32/bin.  Alternatively you can
hardcode the cpp.exe path in
cygwin.cf as /cygnus/cygwin-b20/H-i586-cygwin32/bin/cpp

Suhaib

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Mumit Khan
> Sent: Wednesday, November 10, 1999 2:16 PM
> To: Mike MacDonald
> Cc: [email-masked]'
> Subject: Re: include path
>
>
> Mike MacDonald <[email-masked]> writes:
> > Ok, I can see where the path is all hosed up - I don't
> know why..  I'm
> > looking at it too, any help you can give is great though..
>
> Before I even start, let me summarize the way GCC finds
> its includes,
> libraries and subprograms. I'm going to assume that you
> have no GCC
> specific environment variables defined (GCC_EXEC_PREFIX,
> LIBRARY_PATH,
> COMPILER_PATH, ..., see GCC docs) that alter the search path.
>
> 1. Find bin directory: If you've used complete pathname,
> simple; if not,
>    look up gcc.exe in PATH and return the path. This
> could be /xyz for
>    example if gcc.exe lives in /xyz and /xyz is in your PATH.
>
>    /xyz
>
>    *** Everything from here on will be relative to /xyz/../lib, so
>    that must exist. ***
>
> 3. Construct list of directories to search for includes.
> This you can
>    view when you compile a file with -v option. For C
> code, it'll be
>
>    /xyz/../lib/gcc-lib/i586-cygwin32/2.95.2/../../../../../include
>
> /xyz/../lib/gcc-lib/i586-cygwin32/2.95.2/../../../../i586-
> cygwin32/include
>    /xyz/../lib/gcc-lib/i586-cygwin32/2.95.2/include
>
>    C++ also searches the following before the others:
>
> /xyz/../lib/gcc-lib/i586-cygwin32/2.95.2/../../../../../in
> clude/g++-v3
>
> 3. Construct list of directories to search for programs
> such as cpp.exe,
>    ld.exe, etc that GCC calls.
>
>    You can run `gcc -print-search-dirs' and see that for yourself.
>
>    $ gcc -pring-prog-name=ld
>
>    for example will look for ld and report the full path
> if found by
>    this search.
>
> 4. Construct list of directories to search for libraries
> such libgcc.a,
>    libstdc++.a, etc that GCC uses during linking.
>
>    You can run `gcc -print-search-dirs' and see that for yourself.
>
> So, as you can see, the existence /bin/../lib is of
> critical importance
> when GCC is trying to find itself, and this implies that
> the mount table
> must be consistent.
>
> I don't have the time to go through it in detail, but
> hopefully I can
> point out a few things.
>
> > Cygnus Win95/NT Configuration Diagnostics
> > Current System Time: Wed Nov 10 12:34:05 1999
> >
> > WinNT Ver 4.0 build 1381 Service Pack 4
> >
> > Path:	/usr/lib/gcc-lib/i586-cygwin32/2.95.2
>         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> 	This should never be in PATH. Ever.
> > 	/bin
> > 	/usr/X11R6.4/bin
> > 	/usr/local/bin
> > 	/usr/bin
> > 	/c/winnt/system32
> > 	/c/winnt
> > 	./
>
> I'm going to jump to the output of `gcc
> -print-search-dirs', and that
> may provide the clue to your particular problem. BTW,
> please undo all
> cpp.exe etc changes you've made before you try out these
> things. Moving
> GCC internal tools (ie., ones buried under the
> i586-cygwin32 directories)
> around is always a no-no.
>
> > Output of gcc -print-search-dirs
> > install:
> >
> /Cygnus/cygwin-b20/H-i586-cygwin32/lib/gcc-lib/i586-cygwin
> 32/2.95.2/
> > programs:
> >
> /bin/../lib/gcc-lib/i586-cygwin32/2.95.2/:/bin/../lib/gcc-
> lib/:/Cygnus/cygwi
> >
> n-b20/H-i586-cygwin32/lib/gcc-lib/i586-cygwin32/2.95.2/:/C
> ygnus/cygwin-b20/H
> >
> -i586-cygwin32/lib/gcc-lib/i586-cygwin32/:/usr/lib/gcc/i58
> 6-cygwin32/2.95.2/
> >
> :/usr/lib/gcc/i586-cygwin32/:/bin/../lib/gcc-lib/i586-cygw
> in32/2.95.2/../../
> >
> ../../i586-cygwin32/bin/i586-cygwin32/2.95.2/:/bin/../lib/
> gcc-lib/i586-cygwi
> >
> n32/2.95.2/../../../../i586-cygwin32/bin/:/Cygnus/cygwin-b
> 20/H-i586-cygwin32
> >
> /lib/gcc-lib/i586-cygwin32/2.95.2/../../../../i586-cygwin3
2/bin/i586-cygwin3
> >
> 2/2.95.2/:/Cygnus/cygwin-b20/H-i586-cygwin32/lib/gcc-lib/i
> 586-cygwin32/2.95.
> > 2/../../../../i586-cygwin32/bin/
>
> Now here you see the GCC is looking
> /bin/../lib/gcc-lib/[...] for various
> subprograms/specs file. On your machine, can you do the following:
>
>   $ cd /bin/../lib/gcc-lib/i586-cygwin32/2.95.2/
>   $ ls -l specs
>
> If not, your mount table is inconsistent at best.
>
> I build GCC to look at /Cygnus/cygwin-b20/... when all
> else fails. You
> should be able to do the following and make it work:
>
>   $ mount -b d:/Cygnus /Cygnus
>
> but this should be the last ditched effort (ie., after
> you've tried all
> the possibilities I mention in this note).
>
> I think I see the problem in your mount table:
>
> > d:\cygnus\cygwin-b20\H-i586-cygwin32\i586-cygwin32\lib
> /lib     user
> > binmode
> > d:\cygnus\cygwin-b20\H-i586-cygwin32\bin  /bin     user
>    binmode
> > d:\cygnus\cygwin-b20\H-i586-cygwin32\lib  /usr/lib
> user    binmode
>
> The /bin and /lib are not consistent with each other.
> This is a problem
> IMO with the Cygnus has arranged the tree, and causes no
> end to confusion.
>
> You also have /root mounted as /, and so on, and I'm now
> thoroughly
> confused. I'm a great believer of simple mount strategy.
>
> Now try the following so that mount table inconsistencies
> are ignored:
>
>   $ export PATH=//D/Cygnus/cygwin-b20/H-i586-cygwin32/bin:$PATH
>   $ gcc -v
>
> Does it still say `Using builtin specs file'? Look at the
> output of
> `gcc -print-search-dirs'.
>
> Hopefully this helps a bit; the best I can do at the moment.
>
> Regards,
> Mumit
>
>
> --
> Want to unsubscribe from this list?
> Send a message to [email-masked]
>

--
Want to unsubscribe from this list?
Send a message to [email-masked]