This is the mail archive of the
mailing list for the Cygwin project.
RE: EGCS 1.0.2: weird include paths with gcc -b, specs, etc
- To: gnu-win32 at cygnus dot com
- Subject: RE: EGCS 1.0.2: weird include paths with gcc -b, specs, etc
- From: "Fieldhouse, Dirk" <Fieldhouse at logica dot com>
- Date: Fri, 21 Aug 1998 22:04:01 +0100
On 21 August 1998 20:56, Mumit Khan[SMTP:email@example.com] wrote:
> On Mon, 17 Aug 1998, Fieldhouse, Dirk wrote:
> > ref: Earnie Boyd's http://www.cygnus.com/ml/gnu-win32/1998-Apr/0028.html
> > I'm trying to set up a dual cygwin32/mingw32 environment with the egcs
> > cygwin32 binaries and being defeated by some strange behaviour with
> > paths.
Thanks, Mumit, for your answer.
So, for clarification, I want to be able to use the CYGWIN32 binaries to
build CYGWIN32 or MINGW32 objects according to the environment settings -
ideally without having to do gcc -b i386-mingw32 ...
> > The binary distribution of egcs-1.0.2 for cygwin32 seems to have some
> > hard-wired directories built into it, specifically
> > ../../../../../include
> > and
> > ../../../../i386-cygwin32/include
> Yeah, this is what I call the "Cygnus unlibsubdir" patch that is standard
> with Cygnus built distributions. Basically, unlibsubdir patch relocates
> the entire GCC package with only one env variable -- GCC_EXEC_PREFIX --
> and everything is accessed relative to that. This change affects the
> language drivers, cpp and proto tools only.
This seems like a good default but shouldn't explicit C_INCLUDE_PATH etc
variables override it?
> I need to weigh my time against other factors, and unless someone provides
> a different mechanism, while keeping the "relocatability" feature, I'm
> afraid this feature (or bug, depending on who you are) is here to stay.
> What I *am* willing to do however is to build the drivers (gcc.exe, etc)
> without this patch and put it in a separate archive so you can use those
> instead. The only programs affected are the language drivers, cpp,
> protoize and unprotoize.
That sounds great.
> BTW, the --exec-prefix and --prefix settings are different for cygwin32
> (which use different values for these) and mingw32 (uses the same value
> for both), so what you see is consistent.
What I don't understand is that my explicit C_INCLUDE_PATH (&c) are not
being used by the egcs tools _even as an addition_ to the built-in search
path. This becomes clear on studying the transcripts I posted before ().
I'm wondering if this is some CYGWIN strangeness with W95 (failure to
inherit environment, perhaps?) since the string "C_INCLUDE_PATH" is
apparently known to cpp.exe. It's not the mingw32 problem in
http://www.cygnus.com/ml/gnu-win32/1998-Apr/0032.html because I'm using the
cygwin32 build. And I'm sure it worked once!
And again my 2nd question: does egcs gcc use anything apart from the
built-in default, GCC_EXEC_PREFIX and the -b and --specs options to find the
specs file? - eg LIBRARY_PATH ?
Dirk Fieldhouse Logica UK Limited
firstname.lastname@example.org 75 Hampstead Road
c=gb;a=attmail;p=logica; London NW1 2PL
+44 (171) 637 9111
For help on using this list (especially unsubscribing), send a message to
"email@example.com" with one line of text: "help".