This is the mail archive of the crossgcc@sources.redhat.com mailing list for the crossgcc project.

See the CrossGCC FAQ for lots more infromation.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Error: CC not set to working compiler


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]