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] |
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] |