RE: Error: CC not set to working compiler

RE: Error: CC not set to working compiler

[Michael Sokolov]

RakeshN <rakeshn@kpit.com> wrote:

> Should i also set the CC variable ?

No.

> But =
> configure is already finding  the correct gcc [...]

Good!

> [...] then why should i set it =
> explicitly?

You shouldn't. The problem is elsewhere. Your Cygwin-targeted gcc runs file, it
just can't find the rest of the toolchain, the assembler in particular.

Here's the question no one has addressed yet in this thread. You say you
configure by running "srcdir/configure". That's absolutely correct. But what's
in srcdir? If it's just GCC, that's the root of your problem. You need the full
Cygnus toolchain in there, the minimum required modules being libiberty, bfd,
opcodes, binutils, gas, ld, gcc, newlib, libgloss, and winsup (plus all the
support glue). All those FAQs that say that you need to build this compiler
first, then that compiler, etc. are actually wrong. Not just the compiler, but
the whole toolchain, the full Cygnus tree.

This is exactly the uphill battle I'm fighting. A lof of people see the world
from the GNU perspective, with separate GCC, Binutils, GDB, etc. While this
world view may work for native GNU systems (I abstain from further comment here
as I distance myself from those), it is totally wrong for embedded development.
For embedded development, forget about GNU and learn to see the world from the
Cygnus perspective instead, with one single toolchain tree. See my article on
this subject in /pub/embedded/cygnus-tree-intro on ivan.Harhan.ORG.

--
Michael Sokolov		Harhan Engineering Laboratory
Public Service Agent	International Free Computing Task Force
			International Engineering and Science Task Force
			615 N GOOD LATIMER EXPY STE #4
			DALLAS TX 75204-5852 USA

Phone: +1-214-824-7693 (Harhan Eng Lab office)
E-mail: msokolov@ivan.Harhan.ORG (ARPA TCP/SMTP) (UUCP coming soon)

------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sourceware.cygnus.com

Re: Error: CC not set to working compiler

[Doug Evans]

Kai Ruottu writes:
 >  But people should also know that there are standards (recommendations) for
 > the installation. The defaults for GCC are using one recommendation (/usr/local).

I don't think it's that big a deal.  If there are standards, who cares
whether the CrossGCC FAQ uses some particular standard installation
dir in an example.  [yes, I'm sure some care [though I wonder why].  I don't.]

 >  I assume the sysadmins doing the compiler builds and installs. But when the
 > sysadmin leaves, a 'creative' person may leave behind quite a mess. If the
 > GCC builder just installs the stuff into his/hers own computer, there aren't
 > so much need for any 'default' places... Installing for others and remembering
 > that someone else may need to maintain the system afterwards, includes some
 > responsibility...

Or maybe /usr/local is only writable by root and the user wants to do
the installation himself into some other place.  That is an example of
what I was refering to.

 >  Another cause for a mess is when all GCCs come prebuilt and from different
 > vendors. I could imagine someone trying to install the Symbian EPOC SDK, the
 > Motorola's M.CORE, the Algoritmics MIPS-SDE and some other prebuilt GCC for
 > one's PC and then finding them all using different prefix'es (the vendors
 > had all quite a lot creativity...). For these cases one only wish that there
 > WOULD be a standard for the GCC installations... Normally the GCC-builders
 > are somehow blind and don't remember that there could be a need for other
 > GCCs from other vendors (so they choose some unstandard prefix for their
 > tools).

But any choice is arguably wrong.  Suppose Symbian, Motorola, and Algorithmics
_did_ use /usr/local, _and_ each version of gcc was different [which
no doubt they are].  Now suppose this difference is sufficient that
blindly installing them all on top of each other caused something
to stop working.  The target specific parts can't collide, but the
non-target specific parts CAN.  Whichever the user installed last
is what the user would get, and it won't be what the previously
installed toolchains expected.  Imagine Symbian trying to debug
a user's problem with, I dunno, gcov (*1), and the Algorithmics
toolchain was installed last and something changed in gcov between them.

(*1): If gcov doesn't suit you, pick another.

 >  The 'creative' people probably would want to move the '/bin', 'lib' and 
 > '/usr/lib' stuff to some more nicer places, but some 'evil persons'
 > unfortunately have made it too hard...

As worded, I don't understand this.  Can you elaborate?

 >  The host name in the prefix will be nice when installing 'somewhere in the net',
 > but a home-user doesn't have much use for it. The Cygwin etc. binaries have had
 > it because of the build environment in Cygnus -- the executables perhaps aren't
 > in the right host at all.

As worded, I don't understand the last sentence.  Can you elaborate?

 >  I have seen the "Options for Debugging Your Program or GCC", like the
 > '-print-search-dirs' being totally unknown for quite a lot GCC-owners.
 > Probably even the '--help' will too be unknown (it appeared with egcs and so
 > wasn't available with gcc-2.7.2, which some older Linux'es may still have).
 > 
 >  Teaching these two options in the beginning of any FAQ handling GCC should be
 > obligatory.

I'm sure the CrossGCC FAQ maintainer will accept submissions of this kind ...

 >  And of course reading the "Installation/Cross-Compiler" from the GCC manual
 > should be a prerequisite before opening the embedded oriented Cross-GCC FAQ.
 > When I see a guy trying to use the Cygnus newlib in his Solaris2- or Linux-
 > targeted cross-compiler and not using the target libs and headers, because
 > "the Cross-GCC FAQ said that one must use newlib", I always think there being
 > something wrong with the FAQ...

Oh?  The CrossGCC FAQ has this to say on newlib vs glibc.
[bad formatting due to cut-n-pasting problems]

6.3 Why would I choose glibc over newlib (or vice versa)? 

There are currently two sources for a C library: Glibc and
Newlib. Both have their pluses and minuses. 

Intent

Glibc is the GNU libc maintained by the FSF. It is intended to be a
complete replacement library for native systems. It includes the
routines required by C Standards as well as Posix and other routines. 

Newlib is a collection of software from several sources, and was put
together by Cygnus for embedded systems. It contains the routines
required by the C Standard
as well as a math library and misc. other routines. It is not intended
to be a complete replacement library for Unix systems (however, newlib
is the native library for
go32 and cygwin32 systems). 

Licensing

Glibc is covered by the LGPL (the GNU Library General Public
License). Newlib is a collection of software from several sources,
each with their own copyrights,
but basically it's a Berkeley style copyright. 

Resource Utilization

Glibc, being intended for native Unix environments, does not need to
worry about memory usage as much. It is designed to work most
efficiently in
demand-page-loaded shared library situations. Newlib, being intended
for embedded systems, does worry about memory usage (and is more
memory-efficient than
glibc). 

[N.B. As always, I'm sure the FAQ maintainer would gladly accept
enhancements to this or error corrections ...]

------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sourceware.cygnus.com

Re: Error: CC not set to working compiler

[Greg Shubin]

Kai,

I wonder if you can help.

I've been having a lot of trouble building GCC 2.95.2, in order to use it for ECOS. I have two
Mandrake 7.1 systems, and two FreeBSD 4.0 systems, It seems like it does something different each
time I build it. I first had it working on one FreeBSD system, but not the other three. They all
got the infamous "Too many input files" error from cpp. The FAQ says that is because I moved the
main directory from the place where it was built (I did not).

I have noticed that it builds two versions of cpp, one it places in H-xxx-yyy/bin, and the other
in H-xxx-yyy/lib/gcc-lib/arm-elf/2.95.2. When it works, the main program arm-elf-gcc invokes the
second cpp with a full pathname. When it doesn't work it just invokes 'cpp', which resolves to the
first one. I've tried copying the good one to the bin directory, or symlinking to it, but then it
can't find the include directories.

I can't determine how it decides which one to build. I have started with a fresh download and it
builds a bad version. Then I clear everything off and do it again with the exact same configure
and make commands, and it builds one that works.

Any ideas? Maybe a later version? If so, which one is a good one?

Thanks for any help,
Greg Shubin

P.S. I tried your "--enable-targets=arm-aout' suggestion and it worked.


------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sourceware.cygnus.com

Re: Error: CC not set to working compiler

[Kai Ruottu]

Doug Evans wrote:
> 
> Kai Ruottu writes:
>  >  Why the Cross-GCC FAQ puts newbies to try all these weird options?  Many K.I.S.S.es for
>  > the Cross-GCC-FAQ, please...
> 
> Weird options?  Let's keep a little perspective please.

 They are 'weird' after seeing what the RMS manual hints one to use:

-------------- from the gcc-2.96 manual ----------------------------
Configuring a Cross-Compiler

To build GNU CC as a cross-compiler, you start out by running configure.
Use the --target=target to specify the target type.  If configure was unable
to correctly identify the system you are running on, also specify the
--build=build option.  For example, here is how to configure for a
cross-compiler that produces code for an HP 68030 system running BSD on a
system that configure can correctly identify:

./configure --target=m68k-hp-bsd4.3
---------------------------------------------------------------------

 All the extra ones are just 'weird' (perhaps not speaking english as my
native language, I have understood the meaning wrong, perhaps 'odd' or
'not normally used' would be nearer what I meant) and make the thing more
complicated...  At least for the newbies for whom even the basic options
for GCC and the default install directories for it are totally unknown.
How on earth they can decide that the defaults are not suitable, when not
even knowing what the defaults are?

>  >  In Cygnus people may be obliged to use the host-name in the prefix, but the normal Unix
>  > and Linux users are free to follow the standards...  If the Cross-GCC FAQ says that people
>  > should use these kind of name-monsters, I will strongly disagree...
> 
> "should use"?!  The path names are just examples.  People choose whatever
> pathname they wish to.  An argument can be made _against_ _any_ path name
> specified in the FAQ.

 But people should also know that there are standards (recommendations) for
the installation. The defaults for GCC are using one recommendation (/usr/local).

>  >  The standard install dir for local executables, '/usr/local/bin' should already be in
>  > the user's path on every installed Linux system. The 'root' may miss it but the ordinary
>  > users should have it. So following the standards and defaults has its point...
> 
> Some argue they don't want standards dictated to them.
> Let people install things where they wish to.
> Besides, /usr/local/bin as a standard for local executables is hardly
> that much of a standard.  As I'm sure you know, on some systems users
> don't have write access to it whereas they do have write access to
> some other place (as specified by the local sysadmin).

 I assume the sysadmins doing the compiler builds and installs. But when the
sysadmin leaves, a 'creative' person may leave behind quite a mess. If the
GCC builder just installs the stuff into his/hers own computer, there aren't
so much need for any 'default' places... Installing for others and remembering
that someone else may need to maintain the system afterwards, includes some
responsibility...

 Another cause for a mess is when all GCCs come prebuilt and from different
vendors. I could imagine someone trying to install the Symbian EPOC SDK, the
Motorola's M.CORE, the Algoritmics MIPS-SDE and some other prebuilt GCC for
one's PC and then finding them all using different prefix'es (the vendors
had all quite a lot creativity...). For these cases one only wish that there
WOULD be a standard for the GCC installations... Normally the GCC-builders
are somehow blind and don't remember that there could be a need for other
GCCs from other vendors (so they choose some unstandard prefix for their
tools).

 The 'creative' people probably would want to move the '/bin', 'lib' and 
'/usr/lib' stuff to some more nicer places, but some 'evil persons'
unfortunately have made it too hard...

 The host name in the prefix will be nice when installing 'somewhere in the net',
but a home-user doesn't have much use for it. The Cygwin etc. binaries have had
it because of the build environment in Cygnus -- the executables perhaps aren't
in the right host at all.

 I have seen the "Options for Debugging Your Program or GCC", like the
'-print-search-dirs' being totally unknown for quite a lot GCC-owners.
Probably even the '--help' will too be unknown (it appeared with egcs and so
wasn't available with gcc-2.7.2, which some older Linux'es may still have).

 Teaching these two options in the beginning of any FAQ handling GCC should be
obligatory. After knowing the simple things, there weren't those "Why it cannot
find 'as'" messages, or the very famous question about not finding the target
headers from '$prefix/$target/include' (E.g. gcc-2.95.2 has the bug that it
cannot find the target headers, although they are where they should be, but
after using the '-print-search-dirs' one at least sees why GCC (cpp) cannot
find them --- if one understands the shown 'programs' and 'libraries' search
paths having some analogy with the 'headers' search paths. Ok, this is one bug
more when the search paths for the headers will not be seen).

 And of course reading the "Installation/Cross-Compiler" from the GCC manual
should be a prerequisite before opening the embedded oriented Cross-GCC FAQ.
When I see a guy trying to use the Cygnus newlib in his Solaris2- or Linux-
targeted cross-compiler and not using the target libs and headers, because
"the Cross-GCC FAQ said that one must use newlib", I always think there being
something wrong with the FAQ...

 After one knows the basic things, one is free to use any 'weird' options for
tailoring the install paths, to use the '--with-headers=...' (or to pre-create
the '$prefix/lib/gcc-lib/$target/2.95.2' directory) to work-around the gcc-2.95.2
bug.  Or to do anything else the Cross-GCC FAQ hints... But knowing what one is
doing is the prerequisite...

 After using the '--prefix=...' and '--exec-prefix=...' at the same time when
configuring, and at the same time not knowing the '-print-search-dirs' option
for debugging the GCC installation, is a little odd...

Cheers, Kai



------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sourceware.cygnus.com

Re: Error: CC not set to working compiler

[Doug Evans]

Kai Ruottu writes:
 >  Why the Cross-GCC FAQ puts newbies to try all these weird options?  Many K.I.S.S.es for
 > the Cross-GCC-FAQ, please...

Weird options?  Let's keep a little perspective please.

 >  In Cygnus people may be obliged to use the host-name in the prefix, but the normal Unix
 > and Linux users are free to follow the standards...  If the Cross-GCC FAQ says that people
 > should use these kind of name-monsters, I will strongly disagree...

"should use"?!  The path names are just examples.  People choose whatever
pathname they wish to.  An argument can be made _against_ _any_ path name
specified in the FAQ.

 >  The standard install dir for local executables, '/usr/local/bin' should already be in
 > the user's path on every installed Linux system. The 'root' may miss it but the ordinary
 > users should have it. So following the standards and defaults has its point...

Some argue they don't want standards dictated to them.
Let people install things where they wish to.
Besides, /usr/local/bin as a standard for local executables is hardly
that much of a standard.  As I'm sure you know, on some systems users
don't have write access to it whereas they do have write access to
some other place (as specified by the local sysadmin).

------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sourceware.cygnus.com

Re: Error: CC not set to working compiler

[Kai Ruottu]

RakeshN wrote:
> 
> When i run
> srcdir/configure --build=i586-linux-gnu --host=i586-cygwin32 --target=h8300-hms
> --prefix=wininstalldir --exec-prefix=wininstalldir/H-i586-cygwin32
>
> I get the error that
>
> i586-cygwin32-gcc -o conftest conftest.c failed  .....
> CC must be set to working compiler.

 How did you test your installed Cygwin-targeted cross-compiler before trying this ?
Compiling a 'Hello World' with it and checking that the produced executable runs ok
under Win32 ?  If not in any way, you must be a real optimist...

 Although the compiler would nicely produce excutables under Linux, they still may
not work under Win32, if you didn't use the right working binutils (990818) for the
compiler...

> mkdir linux-x-cygwin32 
> cd linux-x-cygwin32 
> srcdir/configure --target=i586-cygwin32 --prefix=installdir
> --exec-prefix=installdir/H-i586-linux 

 After building a thousand or so cross-compilers, I have never used the '--exec-prefix=...',
so I cannot say whether  the resulted GCC searches subprograms from the 'installdir/bin',
and 'installdir/i586-cygwin32/bin', or from 'installdir/H-i586-linux/bin' and
'installdir/H-i586-linux/i586-cygwin32/bin'.

 Why the Cross-GCC FAQ puts newbies to try all these weird options?  Many K.I.S.S.es for
the Cross-GCC-FAQ, please...

 What was the real value for this 'installdir'?  The '/linux-x-cygwin32/gcc/installdir'
as the following shows or what?

>   *** The command '/linux-x-cygwin32/gcc/installdir/H-i586-linux/bin/i586-cygwin32-gcc -o
>   conftest -g -O2 conftest.c' failed.
>   *** You must set the environment variable CC to a working compiler.

 It seems that your Cygwin-target compiler cannot produce anything...

 IMHO, when the default '--prefix' value is '/usr/local', the used value,
'/linux-x-cygwin32/gcc/installdir/H-i586-linux' is against all Unix-principles about
using short names and using standard install prefixes like '/usr/local' and '/opt/gnu'...

 In Cygnus people may be obliged to use the host-name in the prefix, but the normal Unix
and Linux users are free to follow the standards...  If the Cross-GCC FAQ says that people
should use these kind of name-monsters, I will strongly disagree...

> I have set the PATH to the correct path for i586-cygwin32-gcc. I have exported the path
> also correctly.

 The standard install dir for local executables, '/usr/local/bin' should already be in
the user's path on every installed Linux system. The 'root' may miss it but the ordinary
users should have it. So following the standards and defaults has its point...
 
> But still the error is the same. Should i also set the CC variable ? But configure
> is already finding  the correct gcc then why should i set it explicitly?
>
>         /tmp/ccWGFnM0.s: Assembler messages:
>         /tmp/ccWGFnM0.s:27: Error: Unknown pseudo-op:  `.def'
>         /tmp/ccWGFnM0.s:27: Error: Unknown pseudo-op:  `.scl'

 Your Cygwin-targeted compiler cannot find the right assembler. What does the

  /linux-x-cygwin32/gcc/installdir/H-i586-linux/bin/i586-cygwin32-gcc -print-search-dirs

say about the search paths ?  Do you have the Win32-target assembler in the 'programs'
search path ?  Again, has this installed Cygwin-targeted compiler ever really worked ?

 Please do a single step at a time, and check that everything is ok after that, and continue
only then. Otherwise everything will be just a continuing mess, but you cannot sue entropy
about that ;-)

Cheers, Kai


------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sourceware.cygnus.com

RE: Error: CC not set to working compiler

[RakeshN]

-----Original Message-----
From:	Doug Evans [SMTP:dje@transmeta.com]
Sent:	Friday, September 08, 2000 12:02 AM
To:	RakeshN
Cc:	'gcc-help@gcc.gnu.org'; 'crossgcc@sources.redhat.com'; 'gnuh8@pcserv.demon.co.uk'
Subject:	Error: CC not set to working compiler

RakeshN writes:
 > Hi all,
 > 
 > I am doing a canadian cross build. The specs are as follows
 > 
 > build = i586-linux-gnu
 > 
 > host=i586-cygwin32
 > 
 > target=h8300-hms 
 > 
 > When i run 
 > 
 > srcdir/configure --build=i586-linux-gnu --host=i586-cygwin32 --target=h8300-hms --prefix=wininstalldir --exec-prefix=wininstalldir/H-i586-cygwin32 
 > 
 > I get the error that
 > 
 > i586-cygwin32-gcc -o conftest conftest.c failed  .....
 > 
 > CC must be set to working compiler.
 > 
 > I searched for i586-cygwin32-gcc and found out the path for this gcc. 
 > 
 > I then set CC to that gcc and exported it.
 > 
 > But still the error is same....

Have you read the FAQ on building a Canadian Cross?

http://www.objsw.com/CrossGCC/

The shell script there for building a DOS hosted toolchain
without using DOS is equally applicable to building a cygwin
hosted toolchain without using cygwin.

[rakeshn]  Yes i have read the faq. 

The steps followed by me are as follows......

	mkdir linux-x-cygwin32 
	cd linux-x-cygwin32 
	srcdir/configure --target =i586-cygwin32 --prefix=installdir  --exec-prefix=installdir/H-i586-linux 
	make 
	make install 
	cd .. 
	mkdir linux-x-h8300-hms-coff 
	cd linux-x-h8300-hms-coff 
	srcdir/configure --target= h8300-hms --prefix=installdir  --exec-prefix=installdir/H-i586-linux 
	make 
	make install 
	cd .. 
	mkdir cygwin32-x-h8300-hms-coff 
	cd cygwin32-x-h8300-hms-coff 
	srcdir/configure --build=i586-linux-gnu --host=i586-cygwin32  --target=h8300-hms --prefix=wininstalldir --exec-		prefix=wininstalldir/H-i586-cygwin32 
	make 
	make install
  [rakeshn]  The first two configures were successfull. But the last configure attempt gave me these errors...

	*** This configuration is not supported in the following subdirectories:
     send-pr texinfo target-libstdc++ target-libio target-libgloss
    (Any other directories should still work fine.)
	/tmp/ccWGFnM0.s: Assembler messages:
	/tmp/ccWGFnM0.s:27: Error: Unknown pseudo-op:  `.def'
	/tmp/ccWGFnM0.s:27: Error: Unknown pseudo-op:  `.scl'
	/tmp/ccWGFnM0.s:27: Error: ignoring unrecognized symbol type ""
	/tmp/ccWGFnM0.s:27: Error: Rest of line ignored. First ignored character is `3'.
	/tmp/ccWGFnM0.s:27: Error: Unknown pseudo-op:  `.endef'
	/tmp/ccWGFnM0.s:31: Error: Unknown pseudo-op:  `.def'
	/tmp/ccWGFnM0.s:31: Error: Unknown pseudo-op:  `.scl'
	/tmp/ccWGFnM0.s:31: Error: ignoring unrecognized symbol type ""
	/tmp/ccWGFnM0.s:31: Error: Rest of line ignored. First ignored character is `3'.
	/tmp/ccWGFnM0.s:31: Error: Unknown pseudo-op:  `.endef'
	*** The command '/linux-x-cygwin32/gcc/installdir/H-i586-linux/bin/i586-cygwin32-gcc -o 	conftest -g -O2   conftest.c' failed.
	*** You must set the environment variable CC to a working compiler.

	I have set the PATH to the correct path for i586-cygwin32-gcc . I have exported the path also correctly.

But still the error is the same. Should i also set the CC variable ? But configure is already finding  the correct gcc then why should i set it explicitly?

Any help will be appreciated ...

Thanks

	




------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sourceware.cygnus.com

Error: CC not set to working compiler

[Doug Evans]

RakeshN writes:
 > Hi all,
 > 
 > I am doing a canadian cross build. The specs are as follows
 > 
 > build = i586-linux-gnu
 > 
 > host=i586-cygwin32
 > 
 > target=h8300-hms 
 > 
 > When i run 
 > 
 > srcdir/configure --build=i586-linux-gnu --host=i586-cygwin32 --target=h8300-hms --prefix=wininstalldir --exec-prefix=wininstalldir/H-i586-cygwin32 
 > 
 > I get the error that
 > 
 > i586-cygwin32-gcc -o conftest conftest.c failed  .....
 > 
 > CC must be set to working compiler.
 > 
 > I searched for i586-cygwin32-gcc and found out the path for this gcc. 
 > 
 > I then set CC to that gcc and exported it.
 > 
 > But still the error is same....

Have you read the FAQ on building a Canadian Cross?

http://www.objsw.com/CrossGCC/

The shell script there for building a DOS hosted toolchain
without using DOS is equally applicable to building a cygwin
hosted toolchain without using cygwin.

------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sourceware.cygnus.com

Re: Error: CC not set to working compiler

[Michael Sokolov]

RakeshN <rakeshn@kpit.com> wrote:

> CC must be set to working compiler.

In the Canadian cross scenario, before you build your host x target toolchain,
you must first build and install a build x host and a build x target toolchain.

> I searched for i586-cygwin32-gcc and found out the path for this gcc.=20
>
> I then set CC to that gcc and exported it.

No, this is the wrong way to do it. (It is the right way for GNU packages, but
not for the Cygnus tree.) Your i586-cygwin32-gcc must be in your PATH. The
Cygnus configure will set CC, CC_FOR_TARGET, and CC_FOR_BUILD correctly for
each module given correct --build, --host, and --target options. Don't try to
set them manually, in the Cygnus tree it's way too complicated!

--
Michael Sokolov		Harhan Engineering Laboratory
Public Service Agent	International Free Computing Task Force
			International Engineering and Science Task Force
			615 N GOOD LATIMER EXPY STE #4
			DALLAS TX 75204-5852 USA

Phone: +1-214-824-7693 (Harhan Eng Lab office)
E-mail: msokolov@ivan.Harhan.ORG (ARPA TCP/SMTP) (UUCP coming soon)

P.S. See /pub/embedded/cygnus-tree-intro on ivan.Harhan.ORG for more
information on the Cygnus tree.

------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sourceware.cygnus.com

Error: CC not set to working compiler

[RakeshN]

Hi all,

I am doing a canadian cross build. The specs are as follows

build = i586-linux-gnu

host=i586-cygwin32

target=h8300-hms 

When i run 

srcdir/configure --build=i586-linux-gnu --host=i586-cygwin32 --target=h8300-hms --prefix=wininstalldir --exec-prefix=wininstalldir/H-i586-cygwin32 

I get the error that

i586-cygwin32-gcc -o conftest conftest.c failed  .....

CC must be set to working compiler.

I searched for i586-cygwin32-gcc and found out the path for this gcc. 

I then set CC to that gcc and exported it.

But still the error is same....

Can someone please help.....

Thanks in advance...










------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sourceware.cygnus.com