This is the mail archive of the crossgcc@sources.redhat.com mailing list for the crossgcc project.
See the CrossGCC FAQ for lots more information.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
bgat@open-widgets.com wrote: > Kai: > > >> I have never understood why using the 'cp' command to copy and the 'find' > >> command to search things is so hard that the desperate choice of using the > >> newlib-headers for the bootstrap-compiler has been recommended in some FAQs... > > >> My advice is to use the real headers stuff from glibc... > > Because glibc is complicated enough as it is, and using newlib helps > remove the doubt that comes with a broken build cobbled together from > hand-placed headers. And please use 95-octane gasoline in a car needing the 99-octane... They are both just gasoline, so what's the problem? Or use Fairy in your disk washer, not the special one needed for it, it doesn't matter when they both are just for the same purpose... Very weird suggestions indeed... Now I don't wonder where people get their ideas of using newlib everywhere, using newlib or glibc for the Solaris2 target while its proprietary headers and libs are available freely from Sun... The GCC manual clearly says that a cross-compiler needs "suitable headers and libraries" for the target in question. So the 'powerpc-aix*' targets need AIX headers and libraries, 'i386-sco*' targets need the SCO headers and libs, 'sparc-solaris2*' targets need the Sparc/Solaris2 headers and libs and so on. Only in some special cases any unsuitable headers and libraries can be used. And then the builder must know what this will cause to the result and that then there are pure garbage as result... Building the 'libgcc_s.so' for Linux targets in gcc-3.0 tries to scan the 'libc.so.6' and building glibc needs a working 'libgcc.a'... So I don't see any easier route to a working GCC & glibc than using the right target stuff, not any cheap replacement... The best result and the least amount of iterations will be achieved when all the stuff is 'suitable for the target' in the beginning... Perhaps there already is/should be a 'make preinstall' choice in the glibc sources, to install the glibc-headers into their proper places before building GCC. Then the right stuff could be used while building GCC. Anyway I haven't seen any possibility existing to automatize this, and if it does exist, someone else could have found it. Meanwhile the : cp -p -r newlib/libc/include $prefix/$target with the newlib headers works easily... > Yes, it burns a ton of (possibly needless) CPU cycles, but when something > breaks, you don't have to worry so much about if it is something you > screwed up with your 'cp' and 'find' procedure. Copying just the same version glibc-headers from some other glibc-installation and then doing the .../bits/*.h' --> $prefix/$target/include/bits and the .../sys/*.h --> $prefix/$target/include/sys copies from the target-specific subdirs in the glibc-sources sounds trivial enough for me. Anyway a 'make preinstall' possibility for preinstalling all the glibc headers for the target would be preferred, the 'some other glibc- installation' perhaps is not available, at least for the same glibc-version.... Or there should be those '#ifdef __mips__' , '#ifdef __arm__' etc. in the glibc-headers to enable them being 'generic' for all the supported Linux targets (supported in the specific glibc-version). Why the glibc-headers for 'arm-linux' differ from those for 'i686-linux' and these differ from those for 'powerpc-linux' sounds really stupid... I really don't mean that the glibc-headers should be just like those for Windoze, including all the Win9x/NT/2k/CE opsys-support and all the SH/MIPS/Alpha/PowerPC/ARM architecture-support into the same headers... Only the '.../bits' and '.../sys' stuff, now separate, could easily be combined into common headers, the kernel's '.../asm'-stuff may remain separate as it doesn't belong to glibc... > I'm starting on updates to CrossGCC FAQ next week, now that I've > almost caught up from being away from the office for two weeks. I'm > hoping to answer some of the questions like this that keep coming up > over and over again. The problem with the current CrossGCC FAQ has been just this idea about newlib being a 'medicine for all-purposes' or a CRC-spray which fixes everything and lets people go on.... So people have started with it in every possible case, whether the target is Solaris2, SCO, AIX, HPUX, SGI Irix, Linux or anything else. Or alternatively thought that glibc can be used instead of the proprietary headers and libs for the target... Ok, I sometimes ported glibc-1.09 for SCO3.2 and newlib too and they both could be used to write simple (non-network, non-X11) apps for the Unix SVR3.2/SCO world, for the iBCS2-mode of Linux (to port SCO apps like the Oracle ones to Linux), so it is possible to use either newlib or glibc for those 'system' targets. But this needs the necessary 'porting' first.... So the most important thing in the CrossGCC FAQ should be to get people understand that C-headers and libraries are specific for the target. No 'generic headers and libs' do exist, the native headers cannot be used for any other targets and so on... (Of course there are exceptions, that who knows what he/she is doing, is free to do anything....). Just as is wrong to use the cheaper 95-octane gasoline for a car needing the 99-octane one, using newlib for Linux is basically wrong. Anyone who is going to build tools for Linux, MUST know that Linux uses glibc as its C-library, not newlib... Anyone who is going to build tools for Solaris2, MUST know that Solaris2 uses its proprietary stuff from Sun, not newlib or glibc... And so on. Where on earth all the knowledge about these things has disappeared? And of course the first thing in the FAQ should be the: "If you haven't yet got the GCC manual, please get it now. And if you have got the manual, please immediately read the "Installation / Cross-Compiler" from it !". Or alternatively the FAQ must teach all those basic things about how a C-compiler works, what are the C-headers, what are the C-libs, what are startups and so on.... Quite a lot people asking something here haven't any kind of clue when the famous "C compiler cannot create executables" comes, they have never used the '-v' option for GCC (to see the 'cpp', 'cc1', 'as' and 'ld' phases during the compile and to see the options given to the 'phases'), have never used the GCC's '--help'-option, or used the '-print-search-dirs' to see the GCC search paths, and so on. All these options are assumed every newbie to already know. Ok, the GCC-manual is not the best "C for the Dummies"-book, but some of those commercial C-compiler manuals are really good in telling the basic things, so downloading the PDF-manuals for Hitachi, Mitsubishi, Motorola etc. chip-makers own C/C++ tools may be a good start. The basic ideas about linker scripts, startups etc. are tried to explain in them. For the GCC/embed work the RedHat's 'embed.pdf' in the GNUPro-manuals-collection is a must (www.redhat.com/support/manuals). 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] |